Nov 17, 2017 08:11 AM|zxj|LINK
Thanks and that clarified a lot of things for me . Can u also help me understand my another concern - why v2.0 - System.Web.dll is registered in GAC instead of the higher version v4.0 System.Web.Dll since both versions are installed in my system and I use both
VS 2008 & VS 2015.
Starting with the .NET Framework 4, the default location for the global assembly cache is
In earlier versions of the .NET Framework, the default location is C:\Windows\assembly.
You could take a look at on Understanding The CLR Binder.
Understanding The CLR Binder
In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each CLR.
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. There was no need in the previous two framework releases to split GAC. The problem of breaking older applications in Net Framework 4.0.
To avoid issues between CLR 2.0 and CLR 4.0 , the GAC is now split into private GAC’s for each runtime.The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC.
For example, if both .NET 1.1 and .NET 2.0 shared the same GAC, then a .NET 1.1 application, loading an assembly from this shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1 application
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. As a result of this, there was no need in the previous two framework releases to split the GAC. The problem of breaking older (in this case, .NET 2.0) applications
resurfaces in Net Framework 4.0 at which point CLR 4.0 released. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime.
Because there was a CLR change in .NET 4.0 but not in 2.0 to 3.5.
The GAC has the ability to store different versions of assemblies as long as they are from the same CLR. They do not want to break old applications.