How are dotnet core assemblies resolved in an asp.net core app hosted in IIS

Question

We have an asp.net core application running on kestrel hosted in IIS on windows server 2008.

This application uses several base components and we are used to just install these components in the GAC and use assembly redirects to point all applications on the same server to the latest version of these components.

Everything runs fine when we deploy the application including all the necessary assemblies.

However, when we apply a redirect on a dotnet core assembly (we apply the redirect in the [app].exe.config, not the web.config) to a version that is installed in the GAC, we get a type exception ...

Application startup exception: System.TypeLoadException: Could not load type 'my.company.namespace.coolest.component.helpers'

Curiously enough, the redirects for the plain old dotnet4 assemblies work when specified in the [app].exe.config, only the redirect for the dotnet core assembly fails.

So, I'm now wondering. How are dotnet core assemblies resolved? Which locations are searched for ?

(And ultimately, is it possible at all to redirect to a dotnet core assembly in the GAC)

[EDIT 23/OCT/2017: Doh... turns out the latest dotnet core assembly from our team was bad.. so to answer my own question.. yes, assembly redirects (when specified in [app].exe.config) for dotnet core assemblies targeting full .net framework do work and ARE also searched from the GAC]

Answer 1

ASP.NET Core emphasizes a lot of Self-Contained Deployments, so if any assemblies (including ASP.NET Core runtime itself) of your web apps need to be updated, you should rebuild a deployment package and redeploy.

Framework-Dependent Deployments is just introduced to eliminate some disadvantages of SCD, but it still requires your own assemblies to be repackaged and redeployed if you make certain updates.

So forget about the GAC tricks and assembly redirection your team previously used (many other teams also use similar tricks), and follow Microsoft's new approaches. Maybe one day Microsoft would bring GAC to .NET Core, but that should look completely different from what it is today.

Reference: https://docs.microsoft.com/en-us/dotnet/core/deploying/

Answer 2

As Martin Ulrich indicated, it depends on the targetFramework..

For a .net core application targeting the full dotnet framework, assemblies are loaded just as we are used to. (all assemblies, including the dotnet core ones)

• In my case the assembly manager was loaded from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
  
• For binding redirects, it checks application configuration file / host configuration files / machine configuration file
  
• For retrieving assemblies, it looks in the GAC, then the current directory

Noteworthy, for a .net core application targeting the dotnet core 2.0, a "Runtime Package Store" was recently introduced.

• Here the assemblies in the application directory are searched first, then the Runtime Package Store

(See also SO 35538093, Microsoft documentation and Runtime Package Store discussion on github)