ThinkGeo.com    |     Documentation    |     Premium Support

Bumping Assembly Versions

#1

Is there a reason you aren't bumping the Assemby Version in your releases?


We have various installs of version 3.x referenced in various applications. The installs of our applications put the DesktopEdition.dll in the GAC. The GAC version gets overwritten on subsequent installs because the Assembly Version is the same even though the file version is different. This is causing problems for us. When older applications are installed, the older version of the dll is getting placed in the GAC. This causes the newer program to fail as it can't find the updated dll in the GAC.



Thanks,


Jason



#2

With our installer, the opposite is true.   I cannot get the old versions in the GAC replaced with the newer versions.   But in either case, not changing the version numbers is an issue for companies that use the GAC.

#3

Guys, 
  
   The assembly version denoted compatibility on the strong name and that is where we are a bit stuck.  Any change in the assembly version and the assembly is no longer compatible with the previous version.  This means outside of the Gac we could not drag and drop newer versions on top of older ones.  As long as we maintain compatibility by not removing or changing things we need to keep the assembly version the same.  The only alternative is to drop that ability or overwriting files or having everyone create policy files in the machine.config or on the .net tool for each version.  We cannot manipulate policy at run time as we cannot boot strap ourselves to even load before the manifest and assembly version check is done. 
  
   I would imagine for the gac it would have a way to update the dll for an assembly version that has not changed.  For example if we do a bugfix people would not expect an assembly version change and I can’t image the gac can’t handle that scenario.  We did allot research on the version question a year ago or so and all paths lead to keeping the assembly version if you were compatible and just changing the file version.  The file version as far as I have read has no bearing on anything and is only for humans to read.  I am not sure why it would cause grief in the Gac. 
  
 Heresy Opinion: I have no idea why they created the gac after coming from the MTS hell we had before.  The whole idea of side by side assemblies and alike should have made the gac unnecessary.  If people go with the notion that it saves memory etc them I say it is not worth the price you pay to have version nightmares when Ram is cheap and 64 bit machines are on Walmart shelves.  I have heard lots of stories of people getting versions trapped in the gac and once you get it screwed up it is hard to fix, why bother.  Ok this is kinda a flame and I deserve any level of thunder that comes down on me for saying the above. 
  
 In all seriousness I am VERY OPEN to any suggestions that can help version out, including gac users, but it need to satisfy non gac users and allow drag and drop comparability without users having to write or install policy files in their code. 
  
 David

#4

David… I understand the rant about the GAC.   And, in general I hate installation software, so I’m not at all capable of speaking to why our installer package cannot overwrite versions of a dll in the GAC with similar versions. 
  
 Actually, the File version is quite important.   That is what the installer packages use to determine overwrite or ignore.    We don’t bump assembly versions on our components, either, but we alway bump the file version… as you are doing. 
  
 Ok… the counter to the GAC arguement:   We have seven different applications built that we distribute.    Most use DevEx components.  Half use ThinkGeo.   And there are other common shared components.    The DevEx component install is about 9 mb.   Your ThinkGeo install is about 5 mb.   We update these applications frequently.   So, if I don’t install these “common and stable” components in the GAC, that is a 20mb download that I make my customers deal with every time I want to make a minor update.   With the GAC, I take a hit the first time the first app is installed, and then each update of any app is miniscule.     Maybe there is some other way around this, but I’m not capable of knowing it. 
  
 And… speaking of side-by-side installs, etc… you have  a ton of stuff that goes into the %SYS% folder.    It is possible for me to deliver an application on a CD that can be run w/o an install of those components into the %SYS% folder?   If not, then side-by-side is a moot point, anyway, right? 
  
 I really need to learn more about installations, but it just seems so counterproductive :(      I appreciate any experiences your team can share.

#5

 


Ted,
 
Thanks for your sharing knowledge on GAC stuff; I have to admit that our teams have a long way to go to be an expert in this field (at least myself:().
 
 
Thanks.
 
Yale

#6

David, 
  
 I think I understand the drag and drop compatibility assuming they aren’t breaking changes for the older versions. We have 3 applications (A,B, & C) that were developed using three different DesktopEdition.dll file versions of (3.0.199, 3.0.362, & 3.0.426) respectively. The assembly version remains at 3.0.0. for all 3 dll’s. When these 3 applications are installed on the client’s machine, the DesktopEdition.dll is dropped into the GAC. The last application installed will work and break the other 2. Since breaking changes have been made, why aren’t you bumping the assembly version so the GAC can contain multiple copies of DesktopEdition.dll? This is causing us a lot of headache as if one application needs a new fixed dll, then the other 2 will need to be tested and promoted as well. 
  
 Thanks, 
 Jason

#7

Jason, 
  
   The short answer is that since the Desktop is pre-release there is no compatibility standard out there.  The plan is to go with the 3.0.0 when we are fully released and from then on we will not be able to break compatibility.  I think the issues you are experiencing are because you have many version of the beta and our process was not designed to support production level support for the beta before the APIs are fixed.  If for any reason we had to break compatibility in the future we would most certainly bump the version number.  The beta is our chance to not have to worry about compatibility and focus on feature feedback etc.  I really appreciate the input and to let you know that the full release is coming int he middle of next month, after that no more breaking changes. 
  
 David