|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Multiple Assembly Version MaintenanceGAC 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, jno***@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] 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? Vadym Stetsyak wrote: Show quote > Hello, jno***@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 Hello, jno***@gmail.com!
j> I am changing the version number, and thus creating a new assembly j> side-by-side each time. That's exactly the problem. Now when I fix j> a j> bug in this new assembly version, it doesn't fix the same bug in old j> assembly versions. j> Take the following example of assembly release sequences: j> Release Version 1.0.0.0 - Contains a bug that causes a bad j> performance j> hit that I am not currently aware of. One application uses this j> assembly. j> Release Version 1.1.0.0 - Change some method signatures. One new j> application uses this assembly, using the new method signatures. j> Release Version 2.0.0.0 - Fixes the newly found bug that increases j> performance by 500% j> The applications that are using the first two assemblies do not j> benefit j> from this bug fix. If I want to make the application using 1.1.0.0 j> use j> the bug fix, I now need to recompile it to use 2.0.0.0 and redeploy j> it. yes, that's what you can do j> To make the application using 1.0.0.0 benefit from the fix, I need j> to j> roll back my source so that the method signatures are the same j> that j> the j> application is using, add the same code into my source, j> recompile, j> and j> redeploy, that is not correct, since it breaks versioning purpose. With changes versions can only increment. If you're changing something in 1.0.0.0 that means that it is no longer 1.0.0.0 but smth like 1.0.0.1. j> or rewrite the application that is using j> 1.0.0.0 to use j> 2.0.0.0, recompile, and redeploy. That is correct. j> I've just done all j> the work I was j> trying to avoid by using shared assemblies! Right? j> Is j> this making sense? ing sense? Why do you use GAC? If there's one consumer of your DLL, you can simply put that dll in the app directory. If Dll's signatures aren't changed you can do the bugfixes without any pain. Just replace old version with new one and that' it. 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 jno***@gmail.com wrote: Show quote > 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? > > > Vadym Stetsyak wrote: > > Hello, jno***@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  |
|||||||||||||||||||||||
Other interesting topics