AssemblyFileVersion not updated with new packages
JacobAnderson opened this issue · comments
I recently attempted to upgrade to use the latest nuget package. The file version of the dll's were never changed which causes issues for wix installers. They look at the file version to see if they should replace the dll on an upgrade.
So in this case the installer didn't replace the dll and now the app crashes on startup using the wrong dll.
I see that the AssemblyVersion has been updated with each release in AssemblySharedInfo.cs but not the AssemblyFileVersion.
I don't know if there is a reason to not increment the AssemblyFileVersion as well but It'd be appreciated if it was.
Yes, SystemWrapper assemblies are released with AssemblyVersion which matches the release and build number. All releases were made with file version attribute set to 1.0.0.0 - af8bfb
Latest release has these attributes:
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyVersion("0.23.0.168")]
We never had issue with installing this library and replacing existing files with new versions.
File version is just historically always set to 1.0.0.0, I think it can be the same as assembly version.
We never had issue with installing this library and replacing existing files with new versions.
Yeah I'd only expect this to be an issue in applications that use wix installers since they rely on the microsoft standard a little more heavily.
File version is just historically always set to 1.0.0.0, I think it can be the same as assembly version.
Normally I would agree that the versions should be the same but at this point if it was changed to the current AssemblyVersion ( 0.23.0.168 ) installers would detect it as an older version (since 0.23 is less than 1.0) and still not upgrade.
It's a bit of a pickle. Options that would still be valid versioning would be:
- to rev them separately and have them be out of sync forever. Maybe just making the AssemblyFileVersion be AssemblyVersion + 1 in the Major revision would make it easier
- keep them in sync but rev the AssemblyVersion's Major. This would put out a false Major update in that it implies breaking changes where there are none. And maybe implies that the functionality is fully covering the namespace, but that's maybe more of a perception thing. Ultimately it's just a version number.
I'd suggest the second one just for ease of updating moving forward. Deal with the one time update weirdness and then moving forward it's less confusing.
Yeah I'd only expect this to be an issue in applications that use wix installers since they rely on the microsoft standard a little more heavily.
We use WiX installers and they replace files correctly.
Yeah I just got an update from someone on my team that said it's because we are using Windows Installer and the way we do upgrades due to the file versioning rules that causes the issue. (Sorry to cause confusion, I'm not the expert in this area)