CODEWITHSUNDEEP
c#visual-studio-2019.net-core-3.1
user3215105
user3215105

Reputation: 73

Could not load dll from GAC in .NetCore Application

My sample console application (say App1) developed using .Net Core 3.1 and it calls another .NetCore dll (Say Dll1). I have added as reference dll with "Copy Local = Yes". I am using Visual Studio 2019 as Dev environment.

It works fine in direct scenario. Means, when I set "Copy Local = Yes" in App1.

I have registered that .Net Core dll (Dll1) in GAC and set "Copy Local = No" in App1.

Now I could not load .Net Core (Dll1) and it throws below exception.

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=66f432805192946d'. The system cannot find the file specified. File name: 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=66f432805192946d' at xxxxx.Program.Main(String[] args)

My doubts:

Whether .Net Core supports calling dll from GAC?

Kindly help me to resolve this issue.

Regards,

Hari

Upvotes: 4

Views: 2138

Answers (1)

Michael Schönbauer
Michael Schönbauer

Reputation: 1001

Your Question

Does .Net Core load assemblies from the Global Assembly Cache (GAC)?

The Short Answer:

Nope

The Long Answer:

When you use an assembly, with CopyLocal = false set, it means that the Assembly (.dll file) will not be placed into the output directory of whatever you just built.

Here, .Net Core acts differently than .Net Framework:

In .Net Framework

As soon as the missing assembly is used somewhere in your executing code, the runtime environment will try to search for it, find and load it. For .Net Framework, this happens in a very specific way, which includes loading it from the GAC (Global Assembly Cache) when available.

And this is how dotnetcore does:

Those dotnetcore apps are designed to be standalones and easy to handle, and do not want to rely on their environment. You deliver all they need to know along with them. So, those apps won't go searching around for missing dlls, and they will not look into the GAC. This is the normal deployment method, and this is called "self contained deployment"

There is, however, something called the runtime package store, that can help optimizing your deployment, by defining that your .Net Core Application is not "self containing", but is deployed against a defined "framework (= where a set of libraries are defined to be present). This is called "framework dependent deployment"

If you need more Information of Framework-Dependent Deployment of .Net Core Apps

Have a look at this Is there any GAC equivalent for .NET Core?

Upvotes: 8

Related Questions