On Fri, 20 Oct 2006, Mike Dimmick wrote: > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger > Sent: 20 October 2006 00:54 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Private Assemblies with Wix > > > I hope this email gets through (several earlier emails sent from my gmail > account resulted in "SMTP Error (state 9): 451-Could not complete sender > verify callout") > > I've been working on the Wix installer for a project at my company for the > past couple weeks, but the project manager has decided that we should > install all our private dll's and exe's as assemblies. These files aren't > actually compiled as assemblies but he thinks we may be able to do so > anyways by making them private assemblies since those don't require signing. > > I haven't been able to find much documentation about assemblies here or in > the tutorial on tramontana, but I've pieced together the following in the > primary feature in the main wxs file: > > <Component Id="CrDllComponent" Guid="MyGuid" Win64="$(var.IS64)"> > <File Id="CrDllFile" Name="cr.dll" KeyPath="yes" > src="..\..\repository\Build\$(var.PLATFORM)\Release\cr.dll" > Vital="yes" > DiskId="1" Assembly=".net"> > <AssemblyName Id="Name" Value="Assembly"/> > <AssemblyName Id="FileVersion" > Value="$(var.PRODUCT_VERSION)"/> > <AssemblyName Id="Culture" Value="neutral" /> > </File> > </Component> > > --8<--snip--8<-- > > I have a general rule I follow. It goes, 'if it hurts when you do this, > don't do that.' > > If you're talking about .NET, anything compiled to the CLR is automatically > an assembly. If an assembly is strong-named, the actual target version of > the assembly is compiled into the referencing assembly. At run-time, the > Framework will look for strong-named assemblies in the GAC first, then in > the local folder, then under the culture, a 'bin' folder, then > 'bin\<culture>', then fail. For a non-strong-named-assembly, the GAC is not > checked. Generally, I only sign an assembly if I actually intend it to be > shared, and install it to the GAC; if it's only intended for one > application, or not designed for compatibility between versions, I don't > sign it and install to the application directory. These can only be serviced > as part of an application. > > The Assembly=".net" attribute instructs Windows Installer to add the > assembly to the GAC. You cannot do this if it is not strongly-named - the > Framework will not let you (and as I said, it would be pointless to try > since the Framework won't look there for the assembly anyway). > > Tell your project manager that the technology does not support his > suggestion.
Yes, we're using .Net so I was told that all the files already have an internal manifest so I shouldn't need to worry about an external manifest file. We intend to make the public dll's shared at some point in the future, so I think the intent is to be consistent by treating all the dll's and exe's as assemblies, either shared or private. So would the above code be correct if it were a shared dll? (If I added a publicKeyToken value at least) What do i need to change in order to have cr.dll treated as a private assembly? I tried just changing ".net" to "win32", however for some reason that caused light.exe to start generating errors about other unrelated files in other features, saying "file.ext : error LGHT0124 : Not a valid manifest file; detail: Data at the root level is invalid. Line 1, position 1." And i'd still like to know if thee are actually any good tutorials on the subject since even if I end up having to give up on the private assemblies I'll need to figure out how to handle the shared assemblies later. Thanks! ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
