 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / October 2006Multiple Assembly Version Maintenance
My environment is such that I have multiple assembly versions in the GAC on multiple servers. Different applications use different versions of the assemblies which is no problem with the GAC. I use VSS to track my source code so I can roll back changes if I need to edit the source code behind an older DLL version and redeploy it as necessary. The challenge I have run into is that sometimes I need to make the same changes to a method across multiple DLL versions. A good example is when I find a bug or needed algorithm improvement that came about a couple of versions back. Now I have to fix my code, roll back, fix my code, roll back, fix my code, and so on, then redeploy all of the DLL's. Another good example is when I add a new method to the newest assembly, but want to make that method available to an application that is using an older version of the assembly. What would be great, is if I could have methods with the same signature, but specify an attribute that would tell the compiler what assembly version to use. Then, multiple versions of the DLL would be created and I could just drop them all in the GAC. Does anyone have any ideas of how to accomplish this best? Do I need to use a special compiler or some tools? Can VS.NET accomplish this? I was thinking that maybe I could define some identifiers and then use the post-build events to create multiple assemblies or something? Can that be accomplished? Thank you in advance for any help. Hello, jnoody@gmail.com! IMO you're breaking the sole purpose of versioning. If something has changed in the assembly then the indication of that change will be incremented version, right? Did you consider what will happen if you will release DLL with same method set, but changed methods behavior? Since version number is not changed applications that are not aware of new behavior can stop working. j> My environment is such that I have multiple assembly versions in the j> GAC on multiple servers. Different applications use different j> versions j> of the assemblies which is no problem with the GAC. I use VSS to j> track j> my source code so I can roll back changes if I need to edit the j> source j> code behind an older DLL version and redeploy it as necessary. j> The challenge I have run into is that sometimes I need to make the j> same j> changes to a method across multiple DLL versions. A good example is j> when I find a bug or needed algorithm improvement that came about a j> couple of versions back. Now I have to fix my code, roll back, fix j> my j> code, roll back, fix my code, and so on, then redeploy all of the j> DLL's. Another good example is when I add a new method to the newest j> assembly, but want to make that method available to an application j> that j> is using an older version of the assembly. Without recompile/rebuild that application won't be able to access newly added method. You can add new method to DLL, increment its version and then rebuild the application that wants to use new method. [skipped] -- With best regards, Vadym Stetsyak. Blog: http://vadmyst.blogspot.com I am changing the version number, and thus creating a new assembly side-by-side each time. That's exactly the problem. Now when I fix a bug in this new assembly version, it doesn't fix the same bug in old assembly versions. Take the following example of assembly release sequences: Release Version 1.0.0.0 - Contains a bug that causes a bad performance hit that I am not currently aware of. One application uses this assembly. Release Version 1.1.0.0 - Change some method signatures. One new application uses this assembly, using the new method signatures. Release Version 2.0.0.0 - Fixes the newly found bug that increases performance by 500% The applications that are using the first two assemblies do not benefit from this bug fix. If I want to make the application using 1.1.0.0 use the bug fix, I now need to recompile it to use 2.0.0.0 and redeploy it. To make the application using 1.0.0.0 benefit from the fix, I need to roll back my source so that the method signatures are the same that the application is using, add the same code into my source, recompile, and redeploy, or rewrite the application that is using 1.0.0.0 to use 2.0.0.0, recompile, and redeploy. I've just done all the work I was trying to avoid by using shared assemblies! Right? Is this making sense? > Hello, jnoody@gmail.com! > [quoted text clipped - 39 lines] > With best regards, Vadym Stetsyak. > Blog: http://vadmyst.blogspot.com It seems that nobody is reading this thread anymore, but just in case someone finds this in a search down the road, I found the following article describes my dilemma in the Custom Version Policy section quite well. The next page in the tutorial seems to be blank, so you have to skip a page to find an explanation and then another page for examples. http://www.informit.com/guides/content.asp?g=dotnet&seqNum=363&rl=1 > I am changing the version number, and thus creating a new assembly > side-by-side each time. That's exactly the problem. Now when I fix a [quoted text clipped - 66 lines] > > With best regards, Vadym Stetsyak. > > Blog: http://vadmyst.blogspot.com
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.