 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / December 2004assembly version compatibility
Greetings. I have a few questions concerning the version compatiblity of assemblies. Let me first depict the scenario: I am a component designer, my customers are mainly people who design and sell end-user applications. I am using design-time licenses and my components are strongly named. Now I made a update to my component which doesn't break backwards compatibility and send this version to my customers. Since my new version is fixing a number of unwanted features, my customers want to send this update to their customers, but without recompiling their application, so just the component. How can this be done? 1. Using a publisher profile file with my component is of no use: according to the documentation such a file (policy. ... .dll) must be installed in the GAC of the client PC. Hardly a feasible solution: I don't see their end-users performing this. 2. Ask my customers to send an (updated) Application Configuration File with my component, which tells their application to load the newer version of the component? This would work for them, but for the IT shops that are using my component (amongst other components from other vendors) this may be a nightmare, because they have to update the configuration files from all applications they have made with this component, merging my redirections with that from other vendors. Is there no easy, straightforward way to do this? Am I missing something? Were we not told that everything would installable with a simple copy? Please advice. Roland > Greetings. > I have a few questions concerning the version compatiblity of assemblies. [quoted text clipped - 8 lines] > application, so just the component. > How can this be done? In this case the AssemblyVersion should _not_ be changed. If you want compatability, don't change the AssemblyVersion. Use the AssemblyFileVersion to track your builds and versions, but only increment the AssemblyVersion when you are breaking compatiblilty and want to force a recompile and allow side-by-side execution. I usually increment the only the major and minor versions for the AssemblyVersion. So start with: AssemblyVersion 1.0.0.0 AssemblyFileVersion 1.0.0.0 Fix a bug, and this becomes: AssemblyVersion 1.0.0.0 AssemblyFileVersion 1.0.0.1 After substantial, but non-breaking changes: AssemblyVersion 1.0.0.0 AssemblyFileVersion 1.0.1.0 And after a new version with new types and changed interfaces or backwards-compatibility challenges: AssemblyVersion 1.1.0.0 AssemblyFileVersion 1.1.0.0 David Thanks for your reply David, but unfortunately this scheme does not work: apparently Microsoft changed its approach when going from beta2 to the final version. In contrast with what happened then, an assembly now has to have the exact number (major.minor.release.build) as when the application was compiled or it cannot be loaded anymore, except when a publisher policy exists or a redirection is put in the application's configuration file. Before (I didn't test this, so I take it for granted), only the first two numbers where taken into account, and sadly, most of the people are still assuming this is the case.... Greetings, Roland > > Greetings. > > I have a few questions concerning the version compatiblity of assemblies. [quoted text clipped - 40 lines] > > David > Thanks for your reply David, but unfortunately this scheme does not work: > apparently Microsoft changed its approach when going from beta2 to the [quoted text clipped - 6 lines] > numbers where taken into account, and sadly, most of the people are still > assuming this is the case.... I think you misread my suggestion. You are correct that the AssemblyVersion must match exactly, which is why I suggested incrementing the AssemblyVersion only rarely. If you always leave release and build equal to 0 on the AssemblyVersion and increment them instead on AssemblyFileVersion, then you will be able to bind. David David, you are quite right, my apologies. Actually, I didn't even know that this attribute existed. Since the AssemblyFileVersion attribute is not automatically updated, I twisted my current version increment add-in a bit and now AssemblyFileVersion is treated the same way as my AssemblyVersion Attribute before. Thanks a lot for your input. Regards, Roland > > Thanks for your reply David, but unfortunately this scheme does not work: > > apparently Microsoft changed its approach when going from beta2 to the [quoted text clipped - 17 lines] > > David Note that this is exactly what we do when we release a service-pack for the Net framework. Just keep in mind that your customer may have a difference concept of "breaking change" than you do. Also, in certain scenarios (when your assembly is loaded using shadow-copy, i.e. in ASP.Net) your customers may need to flush their "download-cache" using "gacutil /cdl" in order to pick up the new assembly. Rick  SignatureThis posting is provided "AS IS" with no warranties, and confers no rights. -------------------- > From: "roland" <roland.demeester@skynet.be> > [quoted text clipped - 33 lines] > > > > David Thanks for your advice Rick. Sorry for reacting so late, I didn't follow this thread anymore... I am wondering if you guys didn't go too far in caching, or not far enough: shouldn't the system which take care of caching not "ask" whether or not there isn't a newer version available at the server at the start of running an assembly? Roland > Note that this is exactly what we do when we release a service-pack for the > Net framework. Just keep in mind that your customer may have a difference [quoted text clipped - 48 lines] > > > > > > David Hi Roland, Note that this is only an issue when using the download cache (typically due to web deployment, but it is also used when shadow copy enabled). Also note that "non-breaking servicing releases" are generally quite expensive - maintaining 100% backwards compatability is a very high bar, and historically hasn't been done extremely well even when huge companies throw a lot of money and testing resources into validating compatability. The .NET versioning system is really optimized for the more common case where you can't gaurentee 100% backwards compatability. In general, versioning is a very hard problem, and Microsoft continues to spend a lot of time and money investigating approaches for improving the situation. I agree that it is difficult to deal with the specific scenario you describe (servicing releases for 3rd party components that may be web-deployed). I've wondered myself about the caching policy. I'm not 100% sure why it was designed to behave that way, but I suspect it's a matter of startup performance. Imagine you've got a large web-deployed application. Having to make an If-Modified-Since HTTP request for EVERY assembly whenever the app is loaded is probably an adoption-blocking performance penalty (especially since you probably can't pipeline these requests). To be efficient, you really have to centralize the information somewhere about what needs to be redownloaded and what doesn't. Requiring referencing applications to be rebuilt against the new version of the component seems to me to be the lesser of two evils in this scenario. I'll talk to the fusion team and let you know if they have any more specific insights into this problem. Rick SignatureThis posting is provided "AS IS" with no warranties, and confers no rights. -------------------- > Thanks for your advice Rick. Sorry for reacting so late, I didn't follow > this thread anymore... [quoted text clipped - 64 lines] > > > > > > > > David Thanks Rick, I appreciate your input. Roland > Hi Roland, > Note that this is only an issue when using the download cache (typically [quoted text clipped - 104 lines] > > > > > > > > > > David As an alternative to what David wrote, you can use publisher policies to redirect versions of assemblies. You can do this with a .config file or with an appropriately named assembly installed into the GAC (necessary even for private assemblies). Read http://msdn.microsoft.com/library/en-us/cpguide/html/cpconassemblyversionredirec tion.asp for more information. SignatureHeath Stewart Software Design Engineer Developer Division Sustained Engineering Microsoft Corporation Sorry for answering so late, but I didn't check this thread anymore. I am not that keen on publisher policies, because they have to be installed on the end-user's PC. This is probably feasible for local ICT groups (although we are deviating light-years from the copy paradigm for installing applications!), but imagine someone who is using your component for developing applications that are sold to individual users? This is hardly SOHO compatible! Roland > As an alternative to what David wrote, you can use publisher policies to > redirect versions of assemblies. You can do this with a .config file or > with an appropriately named assembly installed into the GAC (necessary > even for private assemblies). Read http://msdn.microsoft.com/library/en-us/cpguide/html/cpconassemblyversionredirec tion.asp > for more information. 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.