If Service Pack AssemblyFileVersion is greater then RTM AssemblyFileVersion, this should not have happened unless they were doing a force over-write ( what was that expression, forced-slapped? )
If two identically strong named assemblies should be identical, then there would be no reason to have spec'd both AssemblyVersion and AssemblyFileVersion. There are valid scenarios where you want to fix something without changing the contract. Yes, you can get in trouble but then again, this is Windows.... DLL hell is normal. <sarcasm/> Now the .NET framework might have changed their technique recently, but I know for a fact that in previous versions of the framework I've seen the technique of maintaining the BCL contract with a static AssemblyVersion, Culture, Token while upgrading the component with a higher version of AssemblyFileVersion. Regards, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Sat, 7/5/08, Immo Landwerth <[EMAIL PROTECTED]> wrote: > From: Immo Landwerth <[EMAIL PROTECTED]> > Subject: RE: [WiX-users] Assembly file versions in wixlibs > To: [EMAIL PROTECTED], "'General discussion for Windows Installer XML > toolset.'" <wix-users@lists.sourceforge.net> > Date: Saturday, July 5, 2008, 6:24 PM > Hi Christopher, > > well, I have seen this "perfectly valid and correct > scenario" with Microsoft > Project Server 2007. The server assemblies have the > assembly version > "12.0.0.0" in both retail and SP1. Only the file > versions are different. > > So what happens in real life? Some dev has accidentally > overwritten the SP1 > version of some shared assembly by the retail version. The > result was no > error message and no warning. A few hours later the dev > server stopped > working and no one knows why. The problem took us > additional two hours to > diagnose and fix. > > The problem with that approach is simply this: two > assemblies that have the > same strong name should be the same. That is what tools > expect and people > assume. If this is not true you are asking for trouble. > > You said it would not be possible to ship service packs > without the ability > to keep the assembly version stable. That is not correct. > You can ship > policy files as well (called "Publisher Policy" > or "Redirecting Assembly > Versions", see > http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx). > This > way you can replace the old assembly by a new one that has > a different > assembly version (e.g. "12.1.0.0") and specify > that all applications will > get that new version although they were compiled against > version "12.0.0.0". > > IIRC, that is exactly how the .NET Framework team does > handle service packs. > > Kind Regards, > Immo Landwerth > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Christopher > Painter > Sent: Sonntag, 6. Juli 2008 00:37 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Assembly file versions in wixlibs > > There are perfectly valid and correct scenarios where one > would need to > update the AssemblyFileVersion but not the AssemblyVersion. > It would be > pretty hard to deploy .NET framework service packs ( or any > other strong > named SDK runtime ) without this ability. > > Unfortunatly I've also seen developers abuse this story > during development > simply because they didn't want to have to rebuild > certain components. > Between that and trying to do multiple instance installs > with components in > the GAC, it would get ugly. So in short I'd reccomend > always changing > AssemblyVersion/AssemblyFileVerson during the development > cycle and only > change AssemblyFileVersion on a case by case basis. > > Christopher Painter, Author of Deployment Engineering Blog > Have a hot tip, know a secret or read a really good thread > that deserves > attention? E-Mail Me > > > --- On Sat, 7/5/08, Rob Mensching > <[EMAIL PROTECTED]> wrote: > > > From: Rob Mensching > <[EMAIL PROTECTED]> > > Subject: Re: [WiX-users] Assembly file versions in > wixlibs > > To: "General discussion for Windows Installer XML > toolset." > <wix-users@lists.sourceforge.net> > > Date: Saturday, July 5, 2008, 5:05 PM > > Using "-fv" is not the "correct > way" to > > install files into the GAC. The "correct > way" is > > to update the Assembly version not the assembly file > > version. One more legacies of Fusion and its, IMHO, > > under-informed design choices. > > > > You might try and see if a binary .wixlib (pass > > "-bf" switch) gets you what you want. > > > > If that doesn't work, you can author the > > MsiAssemblyName table using AssemblyName elements. > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > Behalf > > Of Neil Sleightholm > > Sent: Friday, July 04, 2008 11:19 > > To: General discussion for Windows Installer XML > toolset. > > Subject: [WiX-users] Assembly file versions in wixlibs > > > > I am creating a wixlib that contains some components > that > > go in the GAC, > > because the assembly version stays the same but the > file > > version changes > > I need to use the light option "-fv" to get > them > > to install. Is there > > any way to embed the assembly file versions in the > wixlib > > so that I > > don't have to rely on the consumer of the wixlib > > setting the "-fv" > > option? > > > > > > > > Neil > > > > > > > > P.S. Personally I think "-fv" should be on > by > > default, it is too > > confusing to explain to someone why an assembly > isn't > > being overritten > > in the GAC and I can't see any penalty for using > it. > > > > > > > > Neil Sleightholm > > X2 Systems Limited > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: > VOTE > > NOW! > > Studies have shown that voting for your favorite open > > source project, > > along with a healthy diet, reduces your potential for > > chronic lameness > > and boredom. Vote Now at > > http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: > VOTE > > NOW! > > Studies have shown that voting for your favorite open > > source project, > > along with a healthy diet, reduces your potential for > > chronic lameness > > and boredom. Vote Now at > > http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE > NOW! > Studies have shown that voting for your favorite open > source project, > along with a healthy diet, reduces your potential for > chronic lameness > and boredom. Vote Now at > http://www.sourceforge.net/community/cca08 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
