I have a manifest file for an application which looks something like this:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity name="xxx.exe" version="1.1.0.0" type="win32" processorArchitecture="x86" />
<file name="xxxxxxxx.ocx" hashalg="SHA1">
<comClass clsid="{4xxxxxxx76-D693-4156-93BA-B938A56F15D3}" description="" threadingModel="apartment" />
<typelib tlbid="{8xxxxxx-3A75-4708-993D-6E0CD9564072}" version="1.0" helpdir="" flags="control,hasdiskimage" />
</file>
<dependency>
<dependentAssembly>
<assemblyIdentity name="Assembly numero uno" version="1.1.0.0" type="win32" publicKeyToken="7XXXXXXXXXXXD" />
</dependentAssembly>
</dependency>
</assembly>
I want to add a new <dependency> section right after the </dependency> tag. The new <dependency> should look like this:
<dependency>
<dependentAssembly>
<assemblyIdentity name="Assembly number two" version="1.1.0.0" type="win32" publicKeyToken="7XXXXXXXXXXXD" />
</dependentAssembly>
</dependency>
How can I achieve this with Wix?
First of all, consider modifying the manifest at build time. If that's possible, it is much more preferable - always choose build-time complexity over install-time complexity.
It might make sense to leave this for install time only in case <dependency> element contents depends on the user input or the target system state. In this case you should use one of the WiX options to modify XML, either XmlFile #OleksandrPshenychnyy mentioned, or XmlConfig. I used the latter one more often, as it seems to be more flexible.
If you decide to go for modifying the manifest at install-time, you can still make your life a bit easier. Add the XML pattern to the manifest at build-time, and only modify the parts dependent on the user input or system state at install time. Let's say it is assemblyIdentity/version attribute. Then the WiX snippet might look like this:
<util:XmlConfig Id="VersionChange" ElementPath="assembly/dependency/dependentAssembly/assemblyIdentity[\[]#name='Assembly number two'[\]]" File="$(var.Manifest)" Name="version" Action="create" Node="value" On="install" PreserveModifiedDate="yes" Value="1.1.0.0" />
Note the square brackets escaping technique.
You can use WisUtilExtention library with XmlFile Element to perform some manipulations with XML file. For more details visit this link
Related
I have a non-.NET-based project that I'm trying to hammer nuget into for managing the dependencies. Because of that, I have to use packages.config to define the dependencies for a project.
Right now, I've got it packing and pushing exactly as I want it, but when I restore the packages, it only restores the dependencies in the packages.config I list, none of the dependencies of that package. So, for instance, if I have an application, MyApp, with a dependency on Foo, which then has a dependency on Bar, calling nuget restore on MyApp will not put Bar into the packages folder.
According to the CLI documentation, the -Recursive flag does not work for projects using packages.config - which is a problem for me, as I need to use packages.config, as far as I can tell. Or at least, I don't really want to spend another 3 hours converting all 12 of my packages to use a different format if I can help it.
For reference, here's an example of what my files look like, currently:
MyApp's package.config
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Foo" version="1.0.0.0" allowedVersions="[1.0]" />
</packages>
Foo.nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- Required elements-->
<id>Foo</id>
<version>1.0</version>
<description>Foo</description>
<authors>Tesset</authors>
<dependencies>
<dependency id="Bar" version="[1.0]" />
</dependencies>
</metadata>
<files>
<file src=".\lib\Foo\**" target="lib\Foo" />
</files>
</package>
Bar.nuspec
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<!-- Required elements-->
<id>Bar</id>
<version>1.0</version>
<description>Bar</description>
<authors>Tesset</authors>
</metadata>
<files>
<file src=".\lib\Bar\**" target="lib\Bar" />
</files>
</package>
And, for completeness, I'm calling nuget restore like:
nuget restore ".\MyApp\packages.config" -PackageSaveMode nuspec -OutputDirectory ".\MyApp\packages" -recursive
(Having or not having the -recursive flag makes no difference to whether Bar ends up in the packages folder)
So, is there a way in nuget to make sure Bar gets restored while leaving MyApp (and Foo) using a packages.config file? If not, then is there a way to restore the dependencies listed in the nuspec file, so I can do that recursion manually on the files nuget restore puts into .\MyApp\packages?
I'm writting application in C which calls functions from a DCOM object.
The DCOM is stored in DLL written in 1C language.
My application is working fine when DCOM is registred in a system.
Is there is a way to call functions from the *.dll using Reg-Free (I mean: without registration the .dll in a system)?
I've tried many times to do so but I've failed.
I used mt (from Visual Studio) to embed a manifest xml to the dll but it doesn't work .
The .dll manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="Win32" name="DrvFR" version="1.0.0.0"/>
<file name="DrvFR.dll">
<comClass clsid="{E187099F-8C5C-4723-8866-D8DBB6353ADE}" threadingModel="Apartment"/>
</file>
</assembly>
My application manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="Win32" name="AutomaticCommPortDetector" version="1.0.0.0"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="Win32" name="DrvFR" version="1.0.0.0"/>
</dependentAssembly>
</dependency>
</assembly>
NuGet obtains packages from our own gallery server. A script then creates a CMAKE script with global variables for each package location. I want to add package specific variables like BOOST_INCLUDEDIR or BOOST_LIBRARYPATH with package relative pathes into the .nuspec file of the package. However, all variables shall be usable in CMAKE later.
The .nuspec xsd schema does not allow additional properties. Is there another solution ?
Here is an example of what I need:
<?xml version="1.0"?>
<package>
<metadata>
<id>boost_x86_src</id>
<version>1.55.0</version>
<authors>Fabian Stern</authors>
<owners>Fabian Stern</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Test Package</description>
<dependencies />
<frameworkAssemblies />
<references>
<reference file="signature.sig" />
</references>
<properties>
<add key="BOOST_INCLUDEDIR" value="include/win32" />
<add key="BOOST_LIBRARYPATH" value="libs/win32" />
</properties>
</metadata>
</package>
Every time when I'm trying to load the .dll in my application, I'm getting an error.
I don't get any errors when I'm building it.
Here is a extracted manifest from my .dll, I don't see anything problematic here, except for the string version
Is this string version normal, if not how can I fix it?
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.6195" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugMFC" version="8.0.." processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
version="8.0.."
No, that's not normal and most certainly will cause your program to fail to start. This string comes from vc\atlmfc\include\mfcassem.h, it probably got damaged. Do not edit the file to repair the damage, copy it from another machine. That way updates will still work properly.
I'm trying to figure out how to omit the [type] part in an Ivy retrieve pattern for artifacts that don't have type declared. I use the following ant statement:
<ivy:retrieve pattern="${lib.dir}/[artifact](-[type]).[ext]" conf="compile" />
Despite the parentheses, Ivy produces files like
junit-jar.jar
junit-javadoc.jar
junit-source.jar
The latter two ones are as expected but the first one should be "junit.jar" instead.
The result is the same as when I omit the parentheses.
Edit:
What I'm doing up to now to work around the problem: I have multiple retrieve statements in the build.xml:
<ivy:retrieve pattern="${lib.dir}/[artifact]-[type].[ext]" type="source" />
<ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" type="jar" />
(The "conf" attribute in the original post is not related to this topic.)
But that looks rather silly when there's the feature of optional tokens.
The type defaults to jar, it can't be ommited. See Documentation
So this (-[type]) does not have an affect.
Perhaps you could do something like this in the build.xml (if you control the ivy.xml).
<ivy:retrieve pattern="${lib.dir}/[artifact].[ext]" conf="compile" />
<ivy:retrieve pattern="${lib.dir}/[artifact](-[type]).[ext]" conf="extras" />
You'd have to publish the jar in the compile config and the other jars in the extra config.
Or just name the other ones junit-javadoc and junit-source in the ivy.xml:
<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="2.0">
<info organisation="junit"
module="jnuit"
revision="4.8.2"
status="release"
publication="20110531150115"
default="true"
/>
<configurations>
<conf name="default" visibility="public"/>
</configurations>
<publications>
<artifact name="junit" type="jar" />
<artifact name="junit-sources" type="jar" />
<artifact name="junit-javadoc" type="jar" />
</publications>
</ivy-module>