.net assemblies to GAC

[selwynreynolds]

Hi,
I am writing my first InstallScript MSI project (all others were InstallScript). I have some 3rd party .NET dll's that need to go in the GAC because the project installs applications that use different versions of the same dll's. I have 3 dll's, 2 versions of each (ex dll1 ver 1.2, dll2 ver 1.2, dll3 ver 1.2, dll1 ver 3.5, dll2 ver 3.5, dll3 ver3.5). I put each one in it's own component and made it the key file. The properties I modifed are as follows: .NET Scan at Build: Properties Only, .NET Precompile Assembly: No, Destination: [Global Assembly Cache]. I kept the default on the other properties but can tell you how those are set if needed.

This project will install and run successfully on one machine (Windows XP SP2). On 3 other machines (all Windows XP SP2 also) the following is installed in the GAC:
dll1 ver 1.2
dll2 ver 1.2
dll3 ver 3.5

So, the installed applications do not run on those machines.

I'll admit I do not really understand how InstallShield installs to the GAC, nor do I really understand the CA's. The only reason I switched to use InstallShield MSI is to have access to the SQL Express Prerequisite.

Am I missing something obvious? I've looked at other threads about the GAC and NGEN but haven't found one that addresses my problem of the same dll but different version.

Thank you.

[LaserVision]

Mmm, just to verify that you wrote it wrong to the forum: The spaces in [Global Assembly Cache] are there by intention? The drop drown box in the destination property shows the entry without them...

Another thing to try is to find the help entry "Adding .NET Assemblies to Installation Projects". Each assembly should go in a component and be marked as key file. It also says that you should Set the .NET Scan at Build component property to Dependencies and Properties which you seem to have set to Properties Only.

[yamakamyar]

make sure you have .NET framework 1.1 installed on your client machine... IS2009 is behind in technology of GAC and NGen... They use .NET 1.1 ususally located in %windir%

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322

It contains gacutil.exe and ngen.exe...

The NGen.exe in version 1.1 allowed multiple assembly to get GAC; however, in 2.0 and greater .NET you are only allowed to to GAC a single assembly at a time.

In order for your GAC and NGen to work make sure your client installs .NET 1.1. In your installer go to the Search folder and look for ngen and let it search for version 1.1 not 2.0.

Let me know how far you get with this.

Yama

[yamakamyar]

The harder way would be to perform the GAC programmatically in using C# and writing your own uninstall and install for GAC and NGen.

In C# there is a way to GAC your assembly:

using System.EnterpriseServices.Internal;

public class Helper
{
public Helper (){}

//-- do this after all files have installed with NOT REMOVE = "ALL" condition
public void GACInstallAssembly(string installDirectory, string assemblyName)
{
Publish publish = new Publish();
publish.GacInstall(installDirectory + assemblyName);
}
//-- do this after ValidateInstall with REMOVE = "ALL" condition
public void GACRemoveAssembly(string installDirectory, string assemblyName)
{
Publish publish = new Publish();
publish.RemoveGAC(installDirectory + assemblyName);
}

}

For NGening using NGen 2.0 use Process to run the command line:

/C C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install "C:\assemblyName.dll" /ExeConfig:"C:\myExePath.exe"

look at: http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

Have fun 😄

Yama

[LaserVision]

@yamakamyar: Your solution sounds OTT if IS2009 provides the possibilities already for you. I used this feature for our .NET 1.1 dlls and I haven't seen any problems with that. Creating these kind of workarounds is always problematic because you have to think also for the case when it should be removed. Ok, you mentioned it, but that is just the simple case. What if you have the dll in a feature that can be installed/deinstalled at any time? Handling these scenarios could be unmanageable...