Reputation: 9776
I have compiled one and the same assembly targeting different Frameworks (4.0 and 4.5).
You can see them in the dotPeek
I have expected that they should reference different Framework libraries (mscorlib, System.Core, etc), but I was wrong. Both of them reference the same "version=4.0.0.0".
Does it mean that .NET CLR loading application in memory will ignore those version numbers (4.0.0.0) but will "push the latest available version"? D
Also does the CLR (I assume that loader is a part of it) ignore the target framework information ? I mean if CLR loader interpetate versions it does not need to use target information...
Or there is something wrong with my compilation process and msbuild configure?
Upvotes: 0
Views: 264
Reputation: 63203
It is more of a Microsoft convention to stick assembly version number (not file version number) to CLR version (.NET Framework 1.x/2.0/4.0), while sometimes Framework version (3.5). One advantage is that by reading that version number you can immediately know whether you add the correct reference.
Your expectation is not weird, but that's only related to file version number, which differs significantly (even hotfixes can change them) as you wished. Windows uses such to track the patch level.
Microsoft decides to keep assembly version number unchanged (as in-place upgrade), so we should also get used to that. CLR focuses on assembly version numbers, and ignore file version number in many cases.
Updated: You should notice that this convention starts to change a little bit since the introduction of .NET Core. Now assembly version number is used to indicate API surface explicitly, and can change rapidly.
Upvotes: 1