10

I have installed a 3rd party program on my computer. I opened up one of the .dll's that comes with this program in ildasm.exe and inspected the manifest:

.assembly extern mscorlib
{
   .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )              // .z\V.4..
   .ver 2:0:0:0
}

So the program uses either .net 2.0, 3.0 or 3.5.

I searched for mscorlib.dll on my computer and found 61 files.

How do I find which of these .dll's the program is actually using?

I also notice that a bunch of these are in directories named: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\ProfileXXX\mscorlib.dll, where XXX is a 1-3 digit number.

What is going on here? I could understand that each .net version (2.0, 3.0, 3.5 ...) would have a different file but that should not add up to 61 files. What is the difference between each of these profiles?

Is this what the .net solution of the .dll hell problem looks like? A whole lot of versions of the same file + public keys to safely indentify the .dll.

Who deletes the .dll's that are no longer used? It seems that potentially every program has its own version of .net. Must fill up the disk eventually?

Andy
  • 3,251
  • 4
  • 32
  • 53
  • 1
    Have you already tried [Fusion Log viewer](http://msdn.microsoft.com/en-us/library/e74a18c4%28VS.80%29.aspx)? I haven't looked at If this can be used to check mscorlib.dll though. http://stackoverflow.com/a/3952202/255562 – Ashish Gupta May 22 '15 at 13:48
  • 1
    Looks like a duplicate, though these answers are several years old and may be out of date. http://stackoverflow.com/questions/227886/how-do-i-determine-the-dependencies-of-a-net-application – Almo May 22 '15 at 13:50
  • Thanks Ashish! According to this tool the program uses C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll. A different name than mscorlib.dll which is a bit strange but ok. Also it says that it found the assembly by looking in GAC. – Andy May 22 '15 at 13:59
  • 1
    The .NET Client Profiles are subsets of the .NET Framework, which was provided with .NET Framework 4 and earlier versions. Check MSDN [here](https://msdn.microsoft.com/es-es/library/cc656912(v=vs.110).aspx) and [here](https://msdn.microsoft.com/library/cc656912(v=vs.100).aspx). – Blas Soriano May 22 '15 at 14:03
  • Thanks Almo! I will try the answers. – Andy May 22 '15 at 14:03
  • @Blas: Thanks! But I do not understand what is this profile thing? Just another word for sub-version? Could they not have put the .dll's in directories named v4.0.0.0, v4.0.0.1, v4.0.0.2 etc? – Andy May 22 '15 at 14:12
  • 1
    @Andy No, it is not a subversion, but a subset (just some parts of the whole framework), in order to achieve smaller apps. – Blas Soriano May 22 '15 at 14:18
  • @Blas: I understand that client as opposed to server would be a subset, but how is profile123 a different subset than profile321? Why so many subsets? – Andy May 22 '15 at 14:20
  • 1
    @Andy I'm not very much sure about this, but I think these profiles I have on my hard disk were created by Visual Studio, one profile each app I made. If I remove any of my old projects from Visual Studio, and later delete the associated files using the file explorer, later I need to manually delete the associated .net profile. – Blas Soriano May 22 '15 at 14:37

1 Answers1

13

You just discovered a simple fact, .NET has been very popular and after 13 years there are a lot of versions of it. Most programmers know about version 1.0, 1.1, 2.0 and 4.0 for the desktop version. And it is always pre-jitted by NGEN so multiply by 2. Most don't know that mscorlib.dll contains unmanaged code so there are two distinct versions of it, one for 32-bit and one for 64-bit code, multiply by 2 again.

That's just for the desktop. Then you have the versions that target different runtime environments. There's Silverlight, 5 distinct versions. Windows Phone, 4 versions. Windows Store, 2 versions. And XBox. They matter because you can build programs that run on these targets.

Then there's Portable Class Libraries, they allow you to select the set of targets you want to support. Each permutation of choices has its own distinct reference assembly so you can't accidentally use a type that won't be available on one of the targets.

So the real surprise here is that you found so few of them.

Do keep in mind that the vast majority you found are only reference assemblies. They just contain metadata, no code, present in the c:\Program Files (x86)\Reference Assemblies directory. You only use them when you build your program. At runtime the "real one" gets used, it is very different from the one you built with. It is Microsoft's burden to ensure that they match and you won't have a problem, they are very good at it.

There is otherwise nothing special about the one you listed. It asks for the v2.0 version, the one used in .NET Framework version 2.0 through 3.5. Even if you don't have one of those versions installed on your desktop, you can still run it if you have 4.0, 4.5 or 4.6. The desktop CLR automatically translates requests for 2.0.0.0 to the 4.0.0.0 version, it is very compatible.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536