We have several projects where we use a common set of libraries, (email, data, io.utilities, etc). After running into some issues with some apps being on older versions, I though about installing these items into the GAC) all using managed code only. I created an installer for each of the libraries and installed them onto the development and prod boxes (psuedo prod, as it really hasn't gone live yet).
Here is a breif overview of the library dependency.
LibUtilities
LibData uses LibUtilities
LibEmail uses LibData
Applications use LibData and sometimes LibUtilities
Everything appeared to work fine until we found a bug in one of the LibData. I fixed the bug, recompiled, updated the installer version, and rolled it out to the prod box. The problem is that theLibEmail and another applicationbegan complaining about not having the right version of the dll. the original version was 1.0.0.1, the new version 1.0.0.2. For the end application, recompiling the app against the new version and deploying it (which is just the executable copy, not an actual installer), it worked.
My understanding, which is looking to be very wrong at this point, is that if you make a change to an underlying .Net DLL you shouldn't have to recompile the application that references that DLL. I know that if I create an installer for each lib, and include the dependencies, that it will copy the specific version of a DLL to the GAC (ending up with multiple versions of the same file). The problem with this approach is that when we need to update the underlying DLL, we would have to redeploy every application that uses the affected DLL. To put the nail in the coffin on this one for me is that once we install it into the GAC using the installer, any application that uses it's own copy of the DLL (included in its local directory) uses the GAC one instead.
Things we do for the installer package. We always increment the library version numbers (using one of the .Net plugins) and we also increment the installer version number each time we build the installer packages. We have RemovePreviousVersion=True in the installer package. The product code is also changed each time an installer build it made (otherwise it won't allow us to install over an existing product code).
Now, with all that said, I'm sure that I'm just misunderstanding something with how the installer works.
With the brief description, can anyone point me in the best directon for library management in this scenario?
Any advice would be greatly appreciated. | | Gary Wayne Smith | You should not change the assembly version for bug fixes. Only the assembly file version. When you do create a new assembly version, you should *not* uninstall the old version. That will break any assemblies that have a dependency on the old version. The point of the GAC is that it can store more than one version of an assembly.
Hans Passant.- Marked As Answer bynobugzMVP, ModeratorSaturday, September 12, 2009 8:50 PM
-
| | nobugz | You should not change the assembly version for bug fixes. Only the assembly file version. When you do create a new assembly version, you should *not* uninstall the old version. That will break any assemblies that have a dependency on the old version. The point of the GAC is that it can store more than one version of an assembly.
Hans Passant.- Marked As Answer bynobugzMVP, ModeratorSaturday, September 12, 2009 8:50 PM
-
| | nobugz | Since we have multiple people developing various different applications, presumably using the same version of the component, does it make sense to use the approach that we have taken or just to include the components inline with each project.
OR, should I simply change the file version for bug fixes and if so, will this problem go away then? i.e. file version only change, update installer, install new files, dependenies satisfied or we will still see some type of breakage?
The originally didn't come up until we started using precompiled applications, at which time version comes into play.
| | Gary Wayne Smith | Not sure what you are asking, it ought to be clear what went wrong. Yes, as I said, you don't want to change the assembly version for a bug fix. That will ensure that dependencies are satisfied and all apps will benefit from the bug fix. That's no guarantee that you won't break something, you could have screwed up the bug fix.
Hans Passant. | | nobugz | I'm pretty sure I understand now. Thanks. | | Gary Wayne Smith | I think I almost have this down. Only one little problem encoutered. Here is what I did.
1)I set the AssemblyVersion to 1.0.0.0 in one of the libraries.
2)I set the AssemblyFileVersion to 1.0.100.1 in that same library
3) Compiled this library and installed it with the installer. Installer is set to replace older version
4) Compiled my app against this instaled version.
5) Installed the library through the installer on the target, validated version and file version with the file in the GAC.
6) Copied my compiked app to the target machine, ran app, all is well.
7) Made small internal change to library (no method add/del, just internal logic changes)
8) I set the AssemblyFileVersion to 1.0.100.2 in that same library, leaving AssemblyVersion as 1.0.0.0
9) Updated the version for the installer from 1.0.0 to 1.0.1 as to ensure that it will not run into the "You've already installed this application" warning on the target
10) Installed the library through the installer on the target.
AssemblyFileVersion on the target in the GAC still shows the original 1.0.100.1. It appears that even though the installer has the never version of the library installed, it's not replacing the original one.
I uninstalled the 1.0.100.1 and then ran the installer for the 1.0.100.2 and it then showed up in the GAC as expected and the application worked fine (as it's the same AssemblyVersion -- which is what we wanted).
Now, I guess the quesiton is, how do we get the installer to overwrite the GAC for duplicate AssemblyVersions?
I would like to be able to update this assembly just by running the installer, not having to go through a multistep process.
Current installer properties.
DetectNeverVersionInstalled = true
RemovePreviousVersion = true
When we change the installer version, it changes the product code. This seems to be a must if you want the installer to be able to install the application over itself.
| | Gary Wayne Smith | Visual Studio Setup projects don't add the file version to the MsiAssemblyName table in the generated MSI file, which is what is required for in-place update of the assembly in the GAC. http://msdn.microsoft.com/en-us/library/aa370062(VS.85).aspxhttp://msdn.microsoft.com/en-us/library/aa372360(VS.85).aspxand the comments about in-place updates. The default is as you've seen - the assemblyversion is identical so it won't get updated. VS Setups just don't have the full MSI feature set capability, and they don't have IDE support for this particular feature. If you don't need the GAC perhaps each app can just have its own private copy of each assembly instead. It depends whether installing into the GAC is because of a sense that it's a "waste" to install multiple copies when one in the GAC will do it, or whether there is some functional requirement (or maintenance issue) for a single copy that's shared between all the apps.
Phil Wilson | | PhilWilson | That's what I was afraid of. The GAC isn't critical. I thought it would be the best way to update some of these components. For my case, apparently it isn't. We will probably just use the installer for installing the development libraries onto the development boxes, and just lose the GAC implementation all together.
Maybe in the future when I get a better understanding of the bigger picture of installers, and such, I will look at this again.
| | Gary Wayne Smith |
|
index > Common Language Runtime > .Net DLL install/version issue