Yeah, the last link you provided was what I was operating based off of memory:
"Note The in-place type of update overwrites the copy of the assembly in the global cache, and can break other applications if the new version of the assembly is not completely backward compatible. The recommended method for updating an assembly is to change the strong name of the assembly in the MsiAssemblyName table." The KB article is new to me but it has a stipulation in it that I believe leads to the above recommendation (for the general case): "A better option in such *closed group* and volatile scenarios would be to fix he 'Assembly Version' and change only the 'Assembly File Version'." Emphasis mine. "Closed group" is the important part of that statement. Essentially, if you control the world (i.e. all the people that call your assemblies) and your world is in rapid development then assembly file version is more tenable than publisher policies. I know that this is your point from below. My point is that, I do not think it is correct to suggest that assembly file versions are the recommended as the general solution. The statement at the top is a more general and (often considered) a more maintainable long term solution (aka: side-by-side) than trying to constantly ensure backwards compatibility (as required by assembly file versioning). Personally, I'd like to see the two pieces of documentation married to provide something that works well during development and during servicing (like what you are doing). I'm still (slowly) working on that route. I just would rather not see this very important design decision to get right (versioning) reduced to "just use assembly file versioning it fixes everything". <smile/> -----Original Message----- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Tuesday, January 20, 2009 11:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting the version from the Assembly file I don't believe I am going against Microsoft recommendations: http://support.microsoft.com/kb/556041 http://msdn.microsoft.com/en-us/library/z5e12zb4.aspx http://msdn.microsoft.com/en-us/library/aa372360(VS.85).aspx I have just spent the last hour reading up on this and can't find a clear policy statement on this both options seem to be perfectly valid. The last reference talks about the pitfalls but doesn't say you mustn't to do it. In fact I use both, daily builds use file versions so that GAC is updated and developers don't need to recompile code to get the new version (we sometimes release patches like this as well). Each minor build (1.1 to 1.2 etc) uses a policy redirect (if appropriate) to move to the new assembly version. Neil -----Original Message----- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: 20 January 2009 17:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting the version from the Assembly file You're welcome to do what you want. All I ask is that you be careful about suggesting doing things against the recommendations. It's one thing to say, "Don't use that technology, it has all kinds of problems". It's another thing to say, "It's too hard to use that technology so use it in a way that isn't recommended." I'm not like Raymond, I personally think that applications that use platform technologies wrong should be actively broken. Why? Because I see so many platforms that are hamstrung because developers choose to do things the wrong way. IMHO, the Windows Installer is probably one of the most "trapped" technologies out there because developers have done so many horrible things in it. Also, IMHO, a fair bit of the blame falls on the Windows Installer team itself since there is a lot of the technology that is not easy to understand and not a lot of direction out there how to use it correctly. But, AFAICT, it's pretty clear that publisher policies are recommended over assemblyFileVersion. If you have issues with that (and I won't argue against them because I probably agree with you) then don't suggest that developers should ignore the recommendations. Work to get the recommendations changed. That's my outlook. -----Original Message----- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Tuesday, January 20, 2009 09:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting the version from the Assembly file Sorry but I couldn't leave it... 1. I have to disagree, I'm sure you have a better inside track than me but they do it because they want us to all have the same version, even Office updates work this way. Policy files just don't cut it especially if you do daily builds - you would need hundreds of them very quickly. Office uses policy file to upgrade us from v11 to v12 which makes sense. 2. My GAC doesn't contain anything done the "right way" so I would have to question why it is right. Neil -----Original Message----- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: 20 January 2009 15:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting the version from the Assembly file The "assemblyFileVersion" is only applicable when installing into the GAC. Otherwise, AFAIK, standard file versioning rules apply. The guidance is to use publisher policy instead of "assemblyFileVersion" when installing to the GAC. Also, as it has been related to me, those 90% of Microsoft assemblies fall into two buckets: 1. Core runtime stuff that can't be affected by publisher policy (something has to process it). 2. Microsoft teams doing the wrong thing. Using the argument, "But Microsoft does it" will not always make you right. <smile/> -----Original Message----- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Monday, January 19, 2009 23:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Getting the version from the Assembly file >> 2. My understanding of the .NET Framework documentation does not recommend setting the "fileVersion" in the assembly identity. They recommend SxS semantics by upgrading the assembly's "version" only. Apologies for going off topic but... I think this is true but rarely practical, in reality you often need to upgrade in place and policy redirects don't help - they are only really useful for redirection between major versions. If you take a look in the GAC I think you will find that 90% of what Microsoft ships has different file and assembly versions. Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------ ------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
