Has anyone had any issues with integrating the Merge Modules supplied with the API download .msi file and WiX? Or any other MSI/Installer tool?
When I add for various Features it will accept the Xerces 2.5.0.msm but including any other type of merge modules will fail with the following errors
30>light.exe(0,0): error LGHT0204: ICE27: 'SelfUnregModules' Action in InstallExecuteSequence table in wrong place. Current: Selection, Correct: Execution
30>light.exe(0,0): error LGHT0204: ICE27: Action: 'SelfUnregModules' in InstallExecuteSequence table must come after the 'InstallValidate' action.
30>light.exe(0,0): error LGHT0204: ICE27: Action: 'SelfUnregModules' in InstallExecuteSequence table must come after the 'InstallInitialize' action.
30>light.exe(0,0): error LGHT0204: ICE27: Action: 'InstallFiles' in InstallExecuteSequence table must come before the 'SelfRegModules' action. Current seq#: 4000. Dependent seq#: 2850.
The directory structure looks as so:
<Directory Id="INSTALLDIR" Name="Datacenter">
<Merge SourceFile="$(var.QuickbooksMergeModules)\Xerces2.5.0.msm" Language="$(var.LCID)" DiskId="1" Id="Xerces2.5.0.msm"></Merge>
<Merge SourceFile="$(var.QuickbooksMergeModules)\QBFC13_0.msm" Language="$(var.LCID)" DiskId="1" Id="QBFC13_0.msm"></Merge>
No matter what, cannot get it to work beyond that. I've found some information online regarding including the VC++ 7.0 runtime (I'm assuming I can use later?) but haven't attempted it yet.
Thoughts?
I would carefully read MSI Best Practice #43 and my somewhat counter argument In Defense of Merge Modules.
It's generally best to not use third party merge modules anymore. A standalone MSI brought in through a bootstrapper/chainer is better. If needed, build a stand alone MSI using the merge module and put that into your chainer. The point is, don't contaminate your MSI with problems that can be introduced through the merge module.
The fact that they have custom actions with the name SelfReg in it really makes me wonder about the quality of these modules. Self registration (any form of it) is usually a very bad thing.
Related
Im building a very custom CMS on top of Symfony CMF Components/Bundles. I read almost everything i could about the CMF Components/Bundles and i have the "architecture" kinda defined. Im experienced/familiarized with Symfony2 components.
The CMS should provide a way to manage multiple sites.
A Site contains Pages.
A Page, requires a title and may have content. A page can also have blocks associated(Those already provided by the Block Bundle, and others with custom functionality developed by me for the CMS).
For now i defined two Documents(Site and Page).
Based on the application requirements im using the CoreBundle, BlockBundle, RoutingBundle, DoctrinePHPCRBundle, and DoctrinePHPCRAdminBundle.
Based on this requirements the expected Repository Tree should be something like:
/sites
/site1 ( nodename of the Site Document )
/pages ( all pages of this site )
/page1 ( nodename of a Page Document )
/page2
/routes ( all routes of this site )
/site2
/pages
...
The configurations for CoreBundle:
cmf_core:
persistence:
phpcr:
basepath: /sites
enabled: true
Because i need nodes(/pages, /routes) for each site, how can i initialize them? My first idea was onPostPersist event of a Site document i initialize the required nodes.
use PHPCR\Util\NodeHelper;
...
public function initSiteNodes(ManagerRegistry $registry, Site $site)
{
$session = $registry->getConnection();
NodeHelper::createPath($session, $site->getId()./pages);
NodeHelper::createPath($session, $site->getId()./routes);
$session->save();
}
So my questions are:
Is this architecture feasible and is SonataAdminBundle prepared for such a structure?
Great to hear you are building a custom CMS on top of the CMF. This is one of the main intended use cases for it.
For your usecase, one important thing to note is that the route base paths can be an array of paths. If you know the sites that will exist, you can simply configure base paths for all of them.
If they can be dynamically created, you will need some more work. You could check if the expression language can help you, or write a symfony request listener that comes very early and sets the right base path on the cmf_routing.phpcr_candidates_prefix service.
The sonata phpcr-odm admin was not really optimized for multisite use cases. However, with the help of the permission system, you should be able to control who may see what.
You could also write to the symfony-cmf-users mailing list. A couple of people did multisite projects with the CMF and might have additional ideas or inputs. And feel free to open pull requests or issues on the corresponding CMF repositories if you see things that could be improved.
I use java and saxonee-9.5.1.6.jar included build path , when run, getting these errors at different times.
Error at xsl:import-schema on line 6 column 169 of stylesheet.xslt:
XTSE1650: net.sf.saxon.trans.LicenseException: Requested feature (xsl:import-schema)
requires Saxon-EE
Error on line 1 column 1
SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
I open .xslt file in hex editor and dont see any different character at the beginning AND
I use transformerfactory in a different project but any error I get.
Check what the implementation class of tFactory is. My guess is it is probably net.sf.saxon.TransformerFactoryImpl - which is basically the Saxon-HE version.
When you use JAXP like this, you're very exposed to configuration problems, because it loads whatever it finds sitting around on the classpath, or is affected by system property settings which could be set in parts of the application you know nothing about.
If your application depends on particular features, it's best to load a specific TransformerFactory, e.g. tFactory = new com.saxonica.config.EnterpriseTransformerFactory().
I don't know whether your stylesheet expects the source document to be validated against the schema, but it it does, note that this isn't automatic: you can set properties on the factory to make it happen.
I would recommend using Saxon's s9api interface rather than JAXP for this kind of thing. The JAXP interface was designed for XSLT 1.0, and it's a real stretch to use it for some of the new 2.0 features like schema-awareness: it can be done, but you keep running into limitations.
i use one Neos installation for multiple domains with different content.
duplicating the package TYPO3.NeosDemoTypo3Org, removing the node-identifier and doing some replacements brought me nearby everything i need.
But only the first Settings.yaml found in Packages/Sites/ seems to be parsed. All changes to the Settings.yaml found in other packages (Test1 and Test2 in the following example) are ignored.
Packages/Sites/TYPO3.NeosDemoTypo3Org/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://TYPO3.NeosDemoTypo3Org/Private/Form/'
Packages/Sites/UDF.Test1/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://UDF.Test1/Private/Form/'
Packages/Sites/UDF.Test2/Configuration/Settings.yaml
TYPO3:
Form:
yamlPersistenceManager:
savePath: 'resource://UDF.Test2/Private/Form/'
When i delete the first Settings.yaml (Packages/Sites/UDF.Test2/Configuration/Settings.yaml), the next Setting.yaml in alphabetical order (Packages/Sites/UDF.Test1/Configuration/Settings.yaml) is used for all 3 site packages. When i also delete this file, the Settings.yaml from UDF.Test2 is used and so on.
would be awesome if somebody can enlighten me. I am new to flow and neos and any help is welcome. RTFM, i know, but as described here i have to believe, that it should work like i did?
alternative way?
is it possible not to set the savePath in the site package configuration but in the common settings ./Packages/Application/TYPO3.Form/Configuration/Settings.yaml
I see a {#package} placeholder in
### BASE ELEMENTS ###
# NAMING: base class for everything is RENDERABLE
'TYPO3.Form:Base':
renderingOptions:
templatePathPattern: 'resource://{#package}/Private/Form/{#type}.html'
but this doesn't work here
TYPO3:
Form:
yamlPersistenceManager:
#savePath: '%FLOW_PATH_DATA%Forms/'
savePath: 'resource://{#package}/Private/Form/'
as you see i am not really experienced with this stuff but i am very motivated.
All Settings.yaml are used, but the settings are merged in order of the package loading.
The loading order of packages again is based on their dependencies.
All three packages probably have the same dependencies so they are loaded one after the other (would need to check with which ordering), so third Settings.yaml is loaded, then second Settings.yaml is loaded and overwrites the third, then the first is loaded and again overwrites the second. Every setting path can only be set once, that's why.
In any case what you are trying to archive probably won't work. This is one of the things we have to fix (site package dependent configuration).
A possible workaround is either using a common package with the form configuration and just set the savePath to this package or using diferent subcontexts (like Production/Domain1 Production/Domain2) and setting this setting different per subcontext, then you could define the subcontext by domain (as the sites are triggered by domain anyway).
I am trying to create a setup project for a Windows Service. I've followed the directions at http://support.microsoft.com/kb/816169 to create the setup project with no trouble.
I want to be able to get a value during the installation in order to update the app.config with the user's desired settings. I added a Textboxes (A) dialog to retrieve the values. I set the Edit1Property property to "TIMETORUN", and in my Primary Output action's CustomActionData property I put in the following: /TimeToRun="[TIMETORUN]\". So far so good. Running the setup I can retrieve the TimeToRun value from the Context.Parameters collection without issue.
In order to locate the app.config I need to also pass in the value of the TARGETDIR Windows Installer Property to my custom action. This is where things begin to fall apart. In order to achieve this, the above CustomActionData must be altered like so: /TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\". Now when I run the setup I get the following error message:
Error 1001. Exception occurred while initializing the installation.
System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Windows\SysWOW64\Files' or one of its dependencies. The system cannot
find the file specified.
If you google this problem you will inevitably find people having tremendous success by simply adding the trailing slash to the /TargetDir="[TARGETDIR]\" portion of the CustomActionData. This unfortunately does not solve my issue.
I tried so many different variations of the CustomActionData string and none of them worked. I tried logging to a file from my overridden Install method to determine where the breakage was, but no log file is created because it's not even getting that far. As the error indicates, the failure is during the Initialization step.
I have a hunch that it could be one of the dependencies that the setup project is trying to load. Perhaps somehow something is being appended to the CustomActionData string and isn't playing well with the TARGETDIR value (which contains spaces, i.e. "C:\Program Files\My Company\Project Name"). Again, this is another hunch that I cannot seem to confirm due to my inability to debug the setup process.
One further thing to mention, and yes it's another hunch, could this be an issue with Setup Projects on 64-bit version of Windows? I'm running Windows 7 Professional.
I'll provide names of the dependencies in case it helps:
Microsoft .NET Framework
Microsoft.SqlServer.DtsMsg.dll
Microsoft.SqlServer.DTSPipelineWrap.dll
Microsoft.SqlServer.DTSRuntimeWrap.dll
Microsoft.SQLServer.ManagedDTS.dll
Microsoft.SqlServer.msxml6_interop.dll
Microsoft.SqlServer.PipelineHost.dll
Microsoft.SqlServer.SqlTDiagM.dll
As you may glean from the dependencies, the Windows Service is scheduling a call to a DTSX package.
Sorry for the long rant. Thanks for any help you can provide.
The answer is so maddeningly simple. If the last argument in the CustomActionData is going to contain spaces and thus you have to surround it with quotes and a trailing slash, you must also have a space following the trailing slash, like this:
/TimeToRun="[TIMETORUN]\" /TargetDir="[TARGETDIR]\ "
The solution and explanation can be found here.
Had a similar issue. In my case, it was odd because my installer had ran successfully once, then I uninstalled my app via Add/Remove Programs successfully, did some coding (did NOT touch my CustomActionData string), and rebuilt my project and setup project. It was when I re-ran my MSI that I got this error.
The coding I had done was to bring in more values of more parameters I had been specifying in my CustomActionData string. That syntax for getting the parameter values (i.e. string filepath = Context.Paramenters["filepath"]), which was in my Installer class, was actually fine, but as I found out, the syntax of the later parameters I was now trying to get from my CustomActionData string had not been correct, from the very beginning. I had failed to add a second quote around one of those parameters, so nothing else could be obtained.
I was using the "Textboxes (A)" and "Textboxes (B)" windows in the User Interface section. A has 1 box, EDITA1, where I get the path to a file, and B has 2 boxes, EDITB1 and EDITB2, for some database parameters. My CustomActionData string looked like this:
/filepath="[EDITA1]" /host="[EDITB1] /port="[EDITB2]"
It should have been:
/filepath="[EDITA1]" /host="[EDITB1]" /port="[EDITB2]"
(closing quote on [EDITB1])
We have a requirement that every piece of code that makes it into production will be reviewed by a senior developer.
The way I have envisioned this working is by a naming convention for branches that regular developers cannot check code into.
Following the SVN recomended directory structure this translates into something like.
[project-name]/trunk/
[project-name]/branches/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
So in the authz file I would like to have something like the following
[/]
#developers = rw
[/*/branches/release-*]
#developers = r
#senior_developers = rw
However I can't find any evidence that SVN supports * (or any other wildcard character).
Is such a thing possible or do I need a pre-commit hook?
It is possible to do a directory structure of
[project-name]/trunk/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
[project-name]/releases/
and deny access to releases but that still leaves you having to do one denial listing per project and worse its not adhering to the SVN standard project structure.
It is not possible to have wildcards as you like to use them. For this purpose you should take a look at svnperm.py script (just google for it) it will match exactly this purpose.