Thanks for the advice about assemblies earlier. Since everyone seemed to think we were using assemblies in the wrong way we've once again scaled back our usage and are no longer trying to use the GAC.
We have some dlls that are used by several different products. Since different versions of those products might be installed (and possibly even different versions of the same same product) we'd like to use side-by-side shared assemblies to minimize conflicts. I decided to start out converting zlib1.dll as a test and followed the directions at http://msdn2.microsoft.com/en-gb/library/aa374228.aspx for creating a signed side-by-side assembly since it has to be signed to be put into WinSxS as far as I understand. This process seemed to mostly work[1] and resulted in a signed zlib1.dll.cat, zlib1.dll.manifest, and zlib1.dll itself. Checking windows/winSxS seems to agree that this is reasonable for side-by-side assemblies. I still can't find any directions on how to install any kind of assemblies using Wix, so I decided to try modifying the process that seemed to work for the GAC, but use "win32" instead of ".net" since the new assemblies are supposed to be win32. Since I wasn't sure how to handle the multiple files I started out with just the manifest. However i got the same error as I was getting before: error LGHT0124 : Not a valid manifest file; detail: Data at the root level is invalid. Line 1, position 1. c:\Projects\ViewETL\Build\Win32\Release\ViewETL.exe 1 The error is odd because it isn't even referring the the zlib1 file. I'd suspect formatting issues except if i remove the "Assembly='win32'" bit it compiles fine. The actual code is: <Component Id="ZlibDllComponent" Guid="71348269-2849-447C-ADF0-542F1C74A770" Win64="$(var.IS64)"> <File Id="ZlibDllFile" Name="zlib1.man" LongName="zlib1.dll.manifest" KeyPath="yes" src="..\..\zlib\Build\$(var.PLATFORM)\Release\zlib1.dll.manifest" Vital="yes" DiskId="1" Assembly="win32"> </File> </Component> I tried using zlib1.dll.cat and zlib1.dll instead but got the same error. The (automatically generated) manifest itself is: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity name="zlib1" processorArchitecture="x86" publicKeyToken="cd404fa0fde4ff0d" type="win32" version="1.0.0.0"> </assemblyIdentity> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"> </assemblyIdentity> </dependentAssembly> </dependency> </assembly> So is the problem with the manifest I've created or am I trying to install it using the wrong method? I've done a lot of searching for instructions or a tutorial on how to do this and have reread the tutorial at tramontana.co.hu several times but found nothing, so I appologize if I'm asking something really basic. I've found directions on how to install side-by-side assemblies through msi here: http://msdn2.microsoft.com/en-us/library/aa369532.aspx so I could theoretically just edit the msi files that wix generates but that seems very awkward and hard to automate. Thank you very much for any help! This has been driving me crazy! [1] The most significant problem I noted with the creation of the assembly is that the msdn page claims there should be a line like "<file name="myfile.dll"/>" which isn't in my manifest. I've tried changing some of the options dealing with files in project options under "Manifest Tool" but haven't had any luck that way. I tried adding the line in myself, with the appropriate file name of course, but that resulted in an mt error of: "manifest authoring error c1010006:The hash algorithm is not specified in the <file> element with name="zlib1.dll"." Which seems wrong given that I was using the "-hashupdate" option specifically to add the hash part. running signtool verify /a /v zlib1.dll.cat results in: "SignTool Error: The signing certificate is not valid for the requested usage. This error sometimes means that you are using the wrong verification policy. Consider using the /pa option." Using "/pa" fixes it however and since the signing is only really used for CRC in WinSxS and not really for identification I was hopping that wouldn't be an issue. And when I've done all this trying to use the three files directly in the projects directory instead of the old dll results in a R6034 error which I can fix by embedding the manifest in the dll with mt. I'm hoping this is because it expects to handle local files and files from WinSxS differently. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
