I want to know how to set the version number of an existing binary without having to rebuild its source code.
Asked
Active
Viewed 5,833 times
3
-
Are these managed (.NET) dlls? If they are managed - are they signed? – RQDQ Aug 14 '13 at 12:06
-
3Why would you want to change the version no of an existing binary? If you want to update the binary, just replace it with the new version. – Nolonar Aug 14 '13 at 12:06
-
8In a way, I hope this isn't possible. – Will Eddins Aug 14 '13 at 12:10
-
I'm not saying it's impossible, because it probably is with some kind of hack, but it's definitely not *supposed* to be allowed. – Kevin DiTraglia Aug 14 '13 at 12:15
-
You *might* be able to do it by editing the DLL in some kind of a binary editor, but as others have said - I can't see *any* good reason for doing so. – Moo-Juice Aug 14 '13 at 12:15
-
Out of curiosity, why do you want to do this? – JMK Aug 14 '13 at 12:16
-
2reshacker.exe does this for 'normal' binatries, not sure if it works for assemblies as well. – stijn Aug 14 '13 at 12:29
-
Would love to know what the requirement for this activity is. – Gusdor Aug 14 '13 at 13:32
-
In our case it is just to match the version number of the current release in a never-compiled generic launcher executable. No need to recompile it, it shall just match the current build number. – Grisgram Mar 15 '19 at 10:51
2 Answers
3
Firstly, I should like to say that I think that doing this could be a terrible idea... it could be construed as fraud.
Having said that, please refer to the How to update assembly version of a dll without compiling in c#? post on MSDN. According to Konrad, you can 'simply edit the File directly to change the version information' (although he advises against this).
Having just tried this, I can confirm that a dll file can be opened in a text editor and that the file version can be edited. The textual version information is found at the end of the file.
I can only assume that there are also binary file versions hidden away somewhere in the file, because after changing the text versions, the Windows Properties Window no longer shows the Product Version information on the Details tab. I'm assuming that this is because the text version no longer matches the hidden binary version (just a guess). Strangely, the dll still worked after the edit, but I'd still advise against doing this.
Sheridan
- 68,826
- 24
- 143
- 183
-
-
3@pwny, potentially because a particular version of a file/dll may have a license/contractual obligations and limitations tied to it. By changing the version number of the file, you could potentially be creating a disjoint between contract and binary (the contract applies to DLL V1, but DLL is being reported as V2, which has different obligations). I am not legalise but that's my take. – Moo-Juice Aug 14 '13 at 13:27
-
regarding your first paragraph: see the reason why I'm using it in my answer. Nothing wrong with it whatsoever, let alone it's a terrible idea. However of course we don't know what the OP is planning to do with it :P – stijn Aug 14 '13 at 13:31
2
Using reshacker.exe it is possible to completely replace the versioninfo resource in dlls. (I use this eg to set the version of dlls emitted by the matlab compiler toolbox, which is way easier than trying to figure out how to make mcc deal with it). I just tried the same principle for assemblies and it works just as good, and the version info properly shows up in explorer, and the application still works as well.
You can do it just via the gui, but here's how I use it from build scripts. First make sure you have a .res file emitted by rc.exe containing your full VERSIONINFO resource (see here for an example of how such an rc file should look like). Then create an ini file containing:
[FILENAMES]
Exe=path/to/dll
SaveAs=path/to/dll
log=res.log
[COMMANDS]
-delete versioninfo, 1,
-addoverwrite path/to/dll/version.res, versioninfo, 1,
and run
reshacker -script patho/to/script
and it will replace the version info in path/to/dll with the info from path/to/dll/version.res. Check res.log to see if somthing is wrong.
