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
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?
Related
We have an application built with .net 6.0 and released for users (say version 5.0). Recently we are coming up with a hotfix/patch for the existing 5.0 users (calling this version 5.1). However, due to some reasons, we will not be giving the entire build of 5.1, instead we will only provide the affected dlls to the users.
After copying the affected files from v5.1 into v5.0, the application will not launch with an error saying "System.IO.FileLoadException: Could not load file or assembly 'MyApplication.Tools, Version=1.21005.8444.21489, Culture=neutral, PublicKeyToken=null'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)"
Is there specific property that I can set for this kind of hotfix patch to work? I tried setting below but no luck. I couldn't find 'SpecificVersion' property as we have in .net framework.
<PropertyGroup>
<DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
</PropertyGroup>
Previously we were on .net framework 4.6.x and this hotfix patch method works flawlessly.
We're developing an UWP LOB app to be published via the Windows Store for Business (build target >= 1607). The UWP application references:
Stubble.Core via nuget (targets .NET Standard 1.3) which references
System.Reflection.TypeExtensions 4.3.0, which references
System.Private.Reflection.Extensibility.dll version 4.0.0.0.
The app will compile and run locally both in debug and release (compiled via .NET native) mode. When uploading the .appxupload to the Windows Store, the resulting app will throw an exception:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.Reflection.Extensibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Private.Reflection.Extensibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at Internal.Reflection.Extensions.NonPortable.PropertyPolicies.GetInheritedMemberInfo(PropertyInfo underlyingMemberInfo, Type reflectedType)
at Internal.Reflection.Extensions.NonPortable.MemberEnumerator.d__11.MoveNext()
at System.Collections.Generic.LowLevelList1.InsertRange(Int32 index, IEnumerable`1 collection)
at System.Reflection.TypeExtensions.GetMembers(Type type, Object nameFilterOrAnyName, BindingFlags bindingAttr)
at System.Reflection.TypeExtensions.GetMembers(Type type, BindingFlags bindingAttr)
at Stubble.Core.Settings.RendererSettingsDefaults.GetMemberLookup(Type objectType)
I can reproduce this issue when extracting the .appxbundle from the .appxupload and sideloading the package via PowerShell. Note, that the .appxbundle within the .appxupload features .NET assemblies and is therefore not compiled to .NET native.
I figure that the Windows Store is should perform this task, but it actually does not (as you can see from the stack trace above) - maybe due to the fact, that we're utilizing the Desktop Bridge feature for our UWP app.
When searching for the System.Private.Reflection.Extensibility.dll, it seems that this assembly relates to .NET Native and the build chain (as it comes with the .NET Native nuget package and MSBuild).
So my question is: Why does the app fail to load the assembly (but does not in debug/release mode)? Does System.Reflection.TypeExtensions expect the app to be compiled with .NET Native which actually works locally?
I tried:
Uploading the .appxbundle compiled with .NET Native (which is not accepted by the store)
Referencing different versions of the
Microsoft.NETCore.UniversalWindowsPlatform package (which includes the .NET Native packages)
Referencing the private library manually (which yields compiler errors because of duplicated assembly references)
Upgrading System.Reflection.TypeExtensions to 4.4
Created a .wapproj wrapper for deployment (issue remains the same)
Added a binding redirect, which causes the app to crash
So the problem seems to be caused by the Windows Store not re-compiling the AppX bundle with .NET Native.
If you build an UWP app locally, within ...
Debug mode, you will get an AppX bundle with .NET assemblies and a reference to the .NET Core CLR (which works)
Release mode, you will get an AppX bundle with a natively compiled application and a reference to the .NET Native runtime (which works as well)
When creating an app package to be submitted to the Windows Store, you will get an AppX bundle with .NET assemblies and a reference to the .NET Native version which should be used by the Windows Store to re-compile the application (determined by the version of the Microsoft.NETCore.UniversalWindowsPlatform nuget package you are using).
For apps with the runFullTrust capability enabled, the Store will not re-compile the application. Therefore, you will distribute an AppX bundle which contains .NET assemblies and relies on the .NET Native runtime (which actually runs remarkably well). As soon as the CLR attempts to load an assembly of the .NET Core implementation, you'll get the error mentioned above. Additionally, your app will be way slower compared to the .NET Native-compiled one.
I guess for a regular AppX bundle with runFullTrust enabled, the Store cannot decide whether to re-compile the app, as such a package could contain other application types (e.g. Windows Forms or WPF).
To overcome this issue, create a "Windows Application Packaging Project" and add the UWP application as a reference. Submit the AppX bundle generated from that project to the store. The Windows Store will then re-compile the .NET assemblies as expected.
For further reference, see Could not load file or assembly 'System.Private.CoreLib...'.
Goal:
From a .NET 4.7 console app, using reflection with Assembly.GetType(), I am trying extract the Type of a netstandard 2.0 class from Assembly X. Then I want to create an instance of this Type with Activator.CreateInstance().
What I am trying to do:
However, this assembly X has a dependency to netstandard 2.0. To be able to get the Type, netstandard dependency has to be loaded into the AppDomain. That's why when the AppDomain is requesting the netstandard assembly through the AssemblyResolve event, I simply load the dll like this :
var netStandardDllPath = #"C:\Users\xxx\.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll";
return Assembly.LoadFrom(netStandardDllPath);
Which throws:
System.BadImageFormatException: 'Could not load file or assembly
'file:///C:\Users\vincent.lerouvillois.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll'
or one of its dependencies. Reference assemblies should not be loaded
for execution. They can only be loaded in the Reflection-only loader
context. (Exception from HRESULT: 0x80131058)'
Inner Exception: BadImageFormatException: Cannot load a reference
assembly for execution.
What I know:
I know that they want us to load the DLL with Assembly.ReflectionOnlyLoadFrom. But doing that will prevent me from instanciate the type with Activator.CreateInstance(). See Microsoft official post
Also, I tried referencing the Nuget packages NETStandard.Library 2.0.0-preview1-25301-01 and NETStandard.Library.NETFramework 2.0.0-preview1-25305-02 in my console app so it would have the netstandard 2.0 libraries referenced, but it didn't change anything.
Question:
Does anyone would know if there is a proper way to load that dll without error, or maybe if this is a bug, or else? Or why this kind of dll is not able to load for execution?
The netstandard.dll you are trying to load is a reference assembly that which cannot be loaded for runtime on .NET Framework as pointed out by others. However if you need to resolve that dependency you will need to runtime version that maps to the framework you are trying to run on.
For .NET Standard support we are including them as part of the msbuild extensions that ship with VS so you will want to get the version of netstandard.dll from there. Depending on which version of VS2017 you have installed it should be somewhere like C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll or from the .NET Core 2.0 SDK you can find it C:\Program Files\dotnet\sdk\2.0.0\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll
Try using one of those versions in your scenario.
Wow. I just spent several hours tracking the cause of this "could not load ... netstandard" error down.
For me, the problem was that my .NET Framework project (which references both .NET Framework and .NET Standard libraries) was built with .NET Framework 4.7.2 and the system where I was deploying and running it did not have 4.7.2 installed.
Deploying a very small Console project with the same basic structure and references and executing that in a Command window finally revealed the correct error, in a pop-up, that .NET Framework 4.7.2 was missing.
If you're struggling with this particular error, make sure you have the necessary .NET Framework installed.
Set Copy Local to true in netstandard.dll properties.
Open Solution Explorer and right click on netstandard.dll.
Set Copy Local to true.
You can't load a reference assembly.
.NET Standard is a collection of APIs that must be provided by .NET Standard compatible implementations.
A reference assembly only contains contracts. This means that it contains no implementation. The assembly you are trying to load contains the .NET Standard 2.0 contracts.
A contract looks like this: https://github.com/dotnet/standard/blob/master/netstandard/ref/mscorlib.cs
EDIT: .NET Framework 4.7 implements .NET Standard 2.0, so you shouldn't need to load any assembly to use Activator.CreateInstance() to instantiate a .NET Standard type.
NETStandard 2.0.0-preview1 in not compatibility with net461 and net47.
but for realese .NET Core SDK 2.0 assemblies (as well as 2.0.0-preview2)
var netStandardDllPath = #"c:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0\netstandard.dll";
Console.WriteLine(Assembly.LoadFrom(netStandardDllPath).FullName);
all is ok.
But if you steel need to load preview1 libraries, maybe you should to use netstandard2.0 instead net471.
For me solved doing the following:
1 - Installed latest .Net Framework on server.
2 - Updated windows server and my local machine.
3 - Went to Manage Nuget Package and updated all references on the update tab.
Perhaps only doing step 3 can solve in your case
In case if IBM Message Queue references are used in the project solution, this exception indicates that the DLL used for refering MQ classes are incompatible with the host(server) .NET version installed.
In this scenario, either we need to update server with latest update and make sure .NET latest version is available or use lower version of IBM Message queue DLL as reference.
Old version DLL - amqmdnet.dll (no new features will be introduced by IBM as not in support)
Latest version DLL - amqmdnetstd.dll (to run IBM MQ classes for .NET Standard, you must install Microsoft .NET Core)
Install NetStandard.Library 2.0.0.0 from NuGet , It works for me. when I downgrade .net framework 4.6.1 to 4.6.0
If you are having this issue for a project that used to work, try deleting the bin and obj folders since caching can cause this, too.
I have a .NET Core console application and a .NET Core class library. Both are extremely simple, single class projects. Both are freshly built, with a fresh install of the latest .NET Core. Both target .NET Core 1.1.
This error occurs at runtime whenever I include a .NET Core class library in an application:
System.IO.FileNotFoundException: 'Could not load file or assembly
'NAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The
system cannot find the file specified.
Building either projects are fine, and Intellisense shows me the contents of the class library after including a using... statement. With the reference and code written there are no issues at compile time.
I've set the Copy Local to Yes for the referenced assembly in my console application. The referenced DLL exists in the bin folder of the console application during run time.
Here is the csproj reference:
<Reference Include="NAME">
<HintPath>path\bin\Debug\netcoreapp1.1\NAME.dll</HintPath>
<Private>true</Private>
<SpecificVersion>false</SpecificVersion>
</Reference>
This only happens with .NET Core DLLs, I have absolutely no issues with .NET Framework 4.5.* and up.
Could anybody shed some light on this issue? Any SO/MSDN pages I've found regarding this have been specific problems like targeted the incorrect version of a DLL, which doesn't help.
Referencing DLL files in a .NET Core application is not supported using the pre-2.0 tools.
The reason is that the dependency graph (deps.json file) generation does not include these files and most likely wouldn't work anyway since it cannot consolidate references / dependencies of the referenced DLL anyway.
For the upcoming 2.0 release, this scenario should work as long as you also reference all DLLs / packages that the original package is using. The syntax would be:
<Reference Include="path/to/my.dll" />
.NET Core 2.0 will also support referencing assemblies that have been built for .NET 4.6.1 this way, but it may fail at runtime if the DLL uses unsupported API calls.
After lots of digging, I found a solution for .NET Core 2.0 that works for me.
The core issue: I added the project references through Visual Studio 2017. In my web application, I referenced two .NET Core libraries; while everything compiles, at runtime, I get a FileNotFound exception pointing to one of the two DLLs.
The solution that worked for me:
Close Visual Studio
Open the .csproj with the references in it. Delete the references to the projects.
From a terminal, cd into the project folder and add the references by hand, using dotnet add reference ..\..\foo\bar.csproj
Start Visual Studio, build and run your (web) application
For me, this resolved the issue.
Not sure if this would count as a fix but it's a workaround at least.
Rather than referencing the DLL I've simply added the project for the class library to the console application, included a dependency reference to the class library project in the console application and clean/rebuilt. Working fine.
Obviously this isn't a fix for DLLs that are proprietary, but it may help.
I am upgrading an application and running into some issues with it.
Now the old application was version 1.0 and loading a depedency assembly A at version 2.1.1 The assembly is present in application local directory.
I am upgrading the new application to version 2.0 that will load assembly A version 1.0.1 which is present in its application local directory. I've checked application references using ISpy and confirmed the new application references A version 1.0.1
But when I start the new application (v 2.0), it is still trying to load assembly version 2.1.1 and failing. I checked the app.config, machine.config and GAC and there is no redirection for version of assembly A. I also checked fusion log files but don't see any redirection. All I see is the fusion log is that application prebinds A at version 2.1.1 and hence fails to set up the assembly present in its local directory.
Is there something I am missing here? What could be the possible reasons for application still referencing the older assembly at runtime?
Update: Using some tools, I realized the the older assembly is being referenced from a native DLL that is referenced by my application, but I don't know which third party DLL is that, and the application loads a ton of them. The fusion log confirms it by logging "Calling assembly : (Unknown)." for the missing assembly.
Now my next step is to find which dll is referencing the wrong assembly and fix that. Now the problem is that ILSpy tool doesn't show the native DLLs references, and DLLDepends tool does not show the assemblies references, so I am not able to link the two.
thanks
Since the library your trying to reference is supposed to be apart of the GAC; you may want to try:
Control Panel
Small Icons(Administrative Tools)
Event Viewer
Application
Windows itself should throw an exception with some particular details it's attempting to reference when it has an error. Especially if it's apart of the GAC. It was more helpful for me to hone in mscoree.dll and mscorelib.dll libraries fairly easy. Granted those clients that I used that for had corrupt framework; but Event Viewer told me the exact library that it had an issue with.
You may want to try that. Not sure which library; but keep in mind this is usually beneficial to libraries that are found within the %windir%/Assembly folder. Hope that helps.