ThinkGeo.com    |     Documentation    |     Premium Support

Version numbers -- revisited

#1

Is there any way that we can get you to put a release out with a 3.1.x.x version number?    We've been installing the 3.0.0.0 versions for months now... and, unfortunately, we made a decision to install in the GAC.    The MSI installer will not refresh an assembly in the GAC when the assembly version numbers are the same.   So, whenver we put an update out, now, we have to send instructions to our customers on how to manually remove DesktopEdition and MapSuiteCore dll's from the GAC, so we get the new versions installed.


When this was discussed a couple of months ago, your position was that you were staying with 3.0.0.0 in the build because people needed to be able to drop in periodic released updates, w/o recompiling programs... even though you sometimes introduced breaking changes.    But I was expecting that when you moved to 3.1.x.x for the "official" release a couple of months ago, that you would update the assembly version.


So, for those of us in this situation, is there any way you can consider creating a build with an updated assembly number?   At least at major milestones?


Thanks.



#2

Ted, 
  
 I couldn’t recreate your problem. I first copied DesktopEdition.dll (3.1.299.0) to GAC, and create a simple installer using VS2008 adding DesktopEdition.dll (3.1.299.1) to GAC, after installed, I found the old dll (3.1.299.0) is successfully replaced by the new one (3.1.299.1). Both of the 2 dlls have the same assembly version (3.0.0.0). So seems the assemblies in GAC can be updated by MSI if the File Version (not just the Assembly Version) is different. So can you let me know in detail what your installer is (are you using VS to build it? Is there some settings you made?) or it will be great if you can provide us a simple sample to show the issue.  
  
 I think you are right that it was better if we updated the assembly version to 3.1.0.0 when we first public the official release a couple months ago. In that way we can force user to get rid of the beta components and rebuild their apps with the newer one. But now as we have officially released the product, I’m afraid we cannot change the assembly version because it is a breaking change to change it. If the assembly version is updated, that means user cannot just grab the latest dll and replace the old one, instead, he/she has to recompile the app to make it reference the new dll, this is a breaking change which is not allowed in an official released product.   
  
 Also, instead of sending instructions to your customers, you can check the version of the component in Runtime and throw exceptions if that doesn’t meet the requirements. For example, we can get the version of the desktop using following codes, if the version is less than 3.1.299, an exception is thrown reminding the user to install a newer version of the component. 
  
 
string version = WinformsMap.GetVersion(); // "MapSuiteCore:3.1.299;DesktopEdition:3.1.299"
 
  
 Thanks, 
  
 Ben 


#3

We are using Advanced Installer from Cayphon.   We have raised this specific issue with them several times, and it is their position that the GAC will not refresh with an updated dll unless the assembly versions are updated. 
  
 I will try some further experiments. 
  
 Can you provide your VS2008 installation example?   I have never built a deployment solution with VS.   At this point, I would consider using one for the installation of the Think Geo components if it would solve this issue for us. 
  
 Thank you for testing this. 


#4

I just want to let you know that InstallShield 2009 is doing the same; 
 it will not refresh GAC if the assembly version is not updated. 
  
 In other word, we need the assembly of version 3.1.299 to be signed as 3.1.299 and not as 3.0.0.0 as now. 
  
 Somewhere, this sounds as basic state of the art for me. 
  
 Regards, 
 Patrick.

#5

Thank you, Patrick. 
  
 Ben, I don’t suppose you could consider a build system that creates two dll’s… one that is conventionally versioned, and one that is “unversioned”?

#6

Hello, 
  
 Where are you with this version numbering issue. 
 I need to deploy my new version and I simply can not because of this number you did not change. 
  
 Patrick.

#7

Ted and Patrick, 


Here attached is a small sample showing how to make an msi installer to update a GAC assembly with same Assembly Version but different File Version.
 
There are 3 files attached, one Dll, one Msi and the source file for the Msi.
 
1, First, copy TestAssembly.dll to GAC. This dll has Assembly Version 1.0.0.0 and File Version 1.0.0.0
 
2, Install Project1.msi
 
3, check the GAC again, you will see the file version is becoming to 1.0.1.0.


4, if you want to remove the assembly in GAC, go to Control Panel->Add or Remove Programs->Uninstall the “MyGacTest” program.
 
Notes:
1, This sample uses Wix 3.0, you need to run the following installer to set up the environment.
sourceforge.net/projects/wix/files/
 
2, This is a very good article about the assembly upgrading, please have a look.
blogs.msdn.com/astebner/arch...47259.aspx
 
You can see the key point is adding the following line to the proj file.
<SetMsiAssemblyNameFileVersion>True</SetMsiAssemblyNameFileVersion>
 
3, As far as I know, Microsoft’s own Setup Project cannot do this. One strange thing is that if you right click a setup project and click “Install” (like following), the project does update the assembly in GAC even only the File Version is different. But if you double click the generated msi file, that’s another story. That’s why I thought Mirosoft’s Setup Project can also implement that by mistake.


Thanks,


Ben



1744-GacTest.zip (12.7 KB)