Hi,

I created my first installation setup with InstallAware and used the StrataFrameMergeModule.msm to install my application.

Now I have an update ready to be send to the customer, but the SF libraries has been updated several times but with the same version number. 

How do I make sure my update will replace the SF libraries in the Windows\Assembly folder at my customer with the latest release used to build the update?

Also, are the SF libraries build into the StrataFrameMergeModule.msm or just a reference to what I have in my developer computer?

Thanks!

Edhy Rijo

Welcome to the frustrating world of installations.  This is not a function of StrataFrame, but rather how you deploy your application.  InstallAware does a poor job of distributing .NET assemblies into the GAC.  They do a good job of getting them in there the first time, but after that you are on your own.  Also, using an MSM will just further complicate things within InstallAware since you need to first remove the assemblies before adding any new ones.

We created a .NET EXE to do everything for us that InstallAware wouldn't...which ended up being a lot   One of these is run at the beginning of our installation within our medical product.  StrataFrame does this in one of the install phases that you see (I believe it is the first one).

Before the installation even starts, we query the GAC for anything that starts with MicroFour using the gacutil tool (which can be distributed).  You can include your startup EXE and the gacutil program in the Support directory of your installation.  I redirect the output of the gacutil tool to an Output stream so the end-user doesn't see the gacutil window popup.  I them parse the list of all installed items in the GAC for assemblies that start with MicroFour.  I then create a collection of those assemblies full names and turn around and use the gacutil to remove them from the assembly before allowing the installation to install any files.  This way I know that my GAC is clean and the installation can install then without issue.  We also use the gacutil to install the assemblies as wel just to make things easier.  We copy the assemblies to a folder and then call the same program as before (with a different command line) to register the assemblies.

It isn't fun, but this is the GAC and installations.  We have spent a full year tweaking our installation for our medical product as it is VERY complicated and performs a vast number of automated tasks.  So I don't think you will have to spend this much time, but you will have to work through the distribution of your assemblies to the GAC.

Another option is to set your application up so that it does not use the GAC at all and your entry point assembly and all other referenced assemblies are in the same folder (or at least the executing path).  This approach will prevent having to do anything with the GAC at all.

Hi Trent,

Thanks for the inside, much appreciated. 

So I would not need to include your merge file in my IA setup and instead add the MicroFour*.dll assemblies to IA to be copied in the Application's root folder?  If this is correct, is there anything else I need to set in the application itself so it will find the assemblies in the new location? or it is by default that it will look in the root path before going to the GAC?

Edhy Rijo

Correct.

No, it will look in the GAC first then the root path.  So you will want to remove those entries from the GAC on the machines you have already installed your application.  But once they are removed, the assembly will look within the path to find any other assembly MicroFour or otherwise that will not be in the GAC.

Sorry to ask this, but what would be the proper way to remove those file from GAC?  I don't see any command in IA to do it.

Also, since the version number does not change with un-officlal updates from SF, I believe I would need to force a delete of those files, before installing/copying new ones with IA, because I got the feeling IA will just compare the file version and not the datetime stamp in those .dll files.

Edhy Rijo

This was what I was referring to in a previous post about writing a .NET program that is call through your IA install to do this for you by calling the gacutil EXE.  We use this approach to get around the shortcomings of IA including a full system check to make sure that the machine is up to specs before allowing the install to move forward etc.

In the EXE that we create we will set the exit code and then test on the IA side if the exit code was a legal value ( you can decide what is legal). 

In .NET, you can exit an application with an Exit Code which will allow any program that is calling that program to determine if the run was successful or not.

To exit with a code other than 0 call the Application.Exit(YourExitCodeValue).

They will, but should really never be a factor as your program should uninstall the previous version before loading the new version.  If you do not use the MSM, IA will remove the assemblies from disk when it is uninstalled....and you could call the program you create to remove any references from the GAC as well.