@VictorioBerra commented on Sun May 06 2018
dotnet --version = 2.1.105
If I have a netcoreapp2 project (console) that references another netcoreapp2 project (library), which references a netstandard2 .DLL somewhere locally on my machine, I get an error "Could not load file or assembly" for that DLL.
But it works just fine if I move that dll reference to the console app and invoke it there instead of the intermediate library.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj" />
</ItemGroup>
</Project>
using ClassLibrary1;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
new TestClass().CreateInstanceOfStandardLib();
}
}
}
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Reference Include="ClassLibraryToBeBuiltAndCopied">
<HintPath>..\ClassLibraryToBeBuiltAndCopied\bin\Debug\netstandard2.0\ClassLibraryToBeBuiltAndCopied.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
using ClassLibraryToBeBuiltAndCopied;
namespace ClassLibrary1
{
public class TestClass
{
public void CreateInstanceOfStandardLib()
{
new Class1();
}
}
}
Notice the reference in the class library up there, that is a simple netstandard2.0 project with a single empty class in it. I went ahead and ran dotnet build .\ClassLibraryToBeBuiltAn
dCopied.csproj
and then I pointed the Class Library at the resulting dll. When I start the console app, I get this:
System.IO.FileNotFoundException: 'Could not load file or assembly 'ClassLibraryToBeBuiltAndCopied, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'
This is completely resolved if I reference the standard library in my console app and use it directly instead of trying to use it through an intermediary library. What am I doing wrong? How can I fix this?
@uffebjorklund commented on Sun May 06 2018
@VictorioBerra Can confirm that I get the same result.
To get it working I had to load the external reference. The file is gettings copied into the correct place, but for some reason it cant be resolved
public class TestClass
{
public TestClass()
{
if (isDebug)
{
var ext = Path.Combine(Directory.GetCurrentDirectory(), "bin/Debug/netcoreapp2.0/", "Ext.dll");
System.Runtime.Loader.AssemblyLoadContext.Default.LoadFromAssemblyPath(ext);
}
else
{
var ext = Path.Combine(Directory.GetCurrentDirectory(), "Ext.dll");
System.Runtime.Loader.AssemblyLoadContext.Default.LoadFromAssemblyPath(ext);
}
}
public void CreateInstanceOfStandardLib()
{
new Ext.ClassA();
}
}
This is probably not what you want, but if you go this way you need this package in your csproj:
<ItemGroup>
<PackageReference Include="System.Runtime.Loader" Version="4.3.0" />
</ItemGroup>
Sample Repo: https://github.com/uffebjorklund/ExternalReferenceNetCore
@VictorioBerra commented on Sun May 06 2018
@uffebjorklund thank you for looking into this and replying. Yes that solution is something I would really like to avoid. I wonder if this is a bug that was introduced with the recent SDK/Runtime update?
@uffebjorklund commented on Sun May 06 2018
@VictorioBerra I am not sure how this is supposed to work, I have never used Ref with HinPath. Added a global.json to my sample repo and tested with the oldest sdk on my machine, same issue. However, that was 2.1.4 (not to old).
Saw some AspNet.Core config with that setup and I doubt that they load assemblies manually. Maybe I am missing something, or maybe it really is a bug.
@VictorioBerra commented on Sun May 06 2018
Well I was able to create the bug using visual studio without ever touching
the .csproj files. I right click the references and added the assembly
using browse. so I think something is not working right.
On Sun, May 6, 2018, 3:13 PM Uffe Björklund notifications@github.com
wrote:
@VictorioBerra https://github.com/VictorioBerra I am not sure how this
is supposed to work, I have never used Ref with HinPath. Added a
global.json to my sample repo and tested with the oldest sdk on my machine,
same issue. However, that was 2.1.4 (not to old).
Saw some AspNet.Core config with that setup and I doubt that they load
assemblies manually. Maybe I am missing something, or maybe it really is a
bug.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/issues/1501#issuecomment-386909789, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACzG620CeKXisfeqOPSzJ2Uh8DdEdfl3ks5tv1l8gaJpZM4T0Hb0
.
@VictorioBerra Can you try this with the latest .NET Core SDK (2.1.302). There have been a few fixes to raw file references since 2.1.105.
With me, in netcore 2.2.103 it is working fine.
It seems okay to me. During my testing at some points I bumped into the error again but I can not replicate it at this point.
Easy way to set up a test using Bash:
mkdir ISS-9659-4; cd ./ISS-9659-4
dotnet new console -n Console1
dotnet new classlib -n StdLib1
dotnet new classlib -n StdLibDll
dotnet new sln
dotnet sln add Console1/Console1.csproj
dotnet sln add StdLib1/StdLib1.csproj
dotnet build StdLibDll/
awk 'NR==6{print; print " <ItemGroup>\n <Reference Include=\"StdLibDll\">\n <HintPath>..\\StdLibDll\\bin\\Debug\\netstandard2.0\\StdLibDll.dll</HintPath>\n </Reference>\n </ItemGroup>"} NR!=0' ./StdLib1/StdLib1.csproj > temp1; mv temp1 ./StdLib1/StdLib1.csproj; # Since dotnet CLI does not have the ability to add a compiled DLL as a project reference this is a one-liner to slap that reference into the file.
awk 'NR==9{print; print "StdLib1.Class1 c = new StdLib1.Class1();"} NR!=0' ./Console1/Program.cs > temp1; mv temp1 ./Console1/Program.cs # Use stdlib from console
awk 'NR==1{print "using StdLibDll;"} NR!=0' ./StdLib1/Class1.cs > temp1; mv temp1 ./StdLib1/Class1.cs # Add using StdLibDll;
awk 'NR==8{print "StdLibDll.Class1 c = new StdLibDll.Class1();"} NR!=0' ./StdLib1/Class1.cs > temp1; mv temp1 ./StdLib1/Class1.cs # Use stdlib dll from stdlib
dotnet add Console1/Console1.csproj reference StdLib1/StdLib1.csproj
dotnet build Console1/Console1.csproj # BUILD SUCCESS
dotnet run --project Console1/Console1.csproj # RUNTIME SUCCESS
Then try this:
netcoreapp1.1
netstandard1.6
dotnet new globaljson --sdk-version 1.1.10
dotnet run --project Console1/Console1.csproj # RUNTIME ERROR
Error:
Hello World!
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
at StdLib1.Class1..ctor()
at Console1.Program.Main(String[] args) in C:\Users\tory.berra\Desktop\ISS-9659-4\Console1\Program.cs:line 10
Issue is very much open. I have
Azure function cannot load the Class Library at runtime and runs into:
Exception thrown: 'System.IO.FileNotFoundException' in System.Private.CoreLib.dll
Could not load file or assembly
Will be really helpful if someone has any pointers.
I think you might be right. I think this is still an issue.
ok
I have the same issue. How did it go?
I mean, my build is fine. But it occurs during runtime.
I have the same issue. How did it go?
I mean, my build is fine. But it occurs during runtime.
It did go off for me on recreation of whole project. Check your GAC and take other steps as outlined in the common dll hell approaches.
@pinaki1234 Thanks! Unfortunately, I'm running it on Mac - no GAC ðŸ˜
dotnet 3.1.301 has the same problem.
Tried to figure out how the assembly was loaded, but I get nothing useful from the trace file
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet#environment-variables
https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#how-do-i-debug-the-probing-properties-construction
set COREHOST_TRACE=1
set COREHOST_TRACE_VERBOSITY=4
set COREHOST_TRACEFILE=host_trace.txt
dotnet run
@nguerrera Did you have a plan to fix this?
@chucklu Sorry, I don't work on this project anymore.
cc @dsplaisted @marcpopMSFT
I'll raise it in triage to see if others have history here.
@chucklu Would it be possible for you to provide a repro for this? That would make it easier for us to investigate. IE a project on GitHub (or just zipped up) that we can use to see the failure.
There is one posted in one of the first comments.
My problem is :
Project A and Project B in same solution, and B depends on A.
We use dotnet pack and nuget push to release nuget library.
A is on version 1.0 and B is version 1.0, there is no problem.
And if we publish B with version 1.1, and did not publish A, then when we reference B, we will get the error, can not load A with version 1.1. Just because when we build B with version 1.1, it will share the version with A for build environment. It means the B 1.1 version will embed A 1.1 within it.
We just change our pipeline to publish 1.2 for both A and B, then problem was resolved.
@dsplaisted My issue was not related to this issue, it's not the same case as @Petermarcu mentioned. You might check the previous comments by @Petermarcu .
Hi @chucklu,
It sounds like you had a different issue, though the error message may have been the same. I think what you would need to do if you only wanted to update project B is to keep the version number for Project A at 1.0 while bumping project B to 1.1. If you want to discuss further, please open a separate issue (the best place for that would probably be https://github.com/nuget/home).
@VictorioBerra
I think it's likely the original issue has been fixed, so I was hoping for a packaged up repro to make it easier to check and reduce the possibility of human error. Are you still seeing the original issue? In your repro steps it looks like you were only seeing the error with the 1.1 SDK.
So this whole issue was a problem that could be fixed via versioning??
On Thu, Jul 30, 2020 at 2:04 PM Daniel Plaisted notifications@github.com
wrote:
Hi @chucklu https://github.com/chucklu,
It sounds like you had a different issue, though the error message may
have been the same. I think what you would need to do if you only wanted to
update project B is to keep the version number for Project A at 1.0 while
bumping project B to 1.1. If you want to discuss further, please open a
separate issue (the best place for that would probably be
https://github.com/nuget/home).@VictorioBerra https://github.com/VictorioBerra
I think it's likely the original issue has been fixed, so I was hoping for
a packaged up repro to make it easier to check and reduce the possibility
of human error. Are you still seeing the original issue? In your repro
steps https://github.com/dotnet/sdk/issues/9594#issuecomment-492730372
it looks like you were only seeing the error with the 1.1 SDK.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/sdk/issues/9594#issuecomment-666606247, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAWMN2335IOZG4RKORILP23R6G72FANCNFSM4OXWMQNQ
.
--
Victorio Berra
[email protected]
636-328-7110
So this whole issue was a problem that could be fixed via versioning??
No, the issue @chucklu hit was entirely different (though it resulted in the same error).
As for the original issue (with direct references to .NET Standard DLLs), I think it's likely been fixed.
Everything works when the dll is referenced with HintPath
, but when the dll is copied manually or from code in custom MSBuild target it still doesn't work. While HintPath
solution is good enough for me, I'd like to understand better why manually copied assemblies cannot be copied at runtime. Where can I learn more about it?
Everything works when the dll is referenced with
HintPath
, but when the dll is copied manually or from code in custom MSBuild target it still doesn't work. WhileHintPath
solution is good enough for me, I'd like to understand better why manually copied assemblies cannot be copied at runtime. Where can I learn more about it?
By default the DLL needs to be listed in the deps.json file. Here are some links with more information:
Hi all
dotnet --version
3.1.402
I think maybe I have a similar problem what is described in the ticket... I am SURE that I have the same error message :)
I have a netcoreapp3.1 class library originally created and built as the DataGenerator.dll file. And then I have a netcoreapp3.1 console app that tries to use the DLL file as a normal (non-nuget) DLL reference. Quoting from the CSPROJ of the console app:
cases A+B will FAIL with a run-time exception. case C will be OK.
Note: both the files DataGenerator.dll and ZH-DataGenerator.dll are the same files, both exist, they are the same DLL I received after building the class library beforehand. Building the console app WORKS in all three cases! If the DLL file itself is not found when building the console app, then build of the console app will fail with "CS0246 The type or namespace name 'DataGenerator' could not be found (are you missing a using directive or an assembly reference?)". SO during the build of the console app, the DLL itself must exist, but the filename does not matter (cases A+B+C, they all build successfully).
However, when executing the console app, then cases A+B will both fail, and only in case C, when I use the original filename DataGenerator.dll in the HintPath, then it will work. BUT if the name of the DLL file is NOT the same as the original name (cases A+B: I use the filename ZH-DataGenerator.dll in the HintPath), then the execution of the console app fails:
dotnet run
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'DataGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
File name: 'DataGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at ConsoleApp1.Program.Main(String[] args)
I have no idea how/why the filename of the DLL in the HintPath can affect the operation of the console app, and whether this is related with the original issue or not ... But if the filename of the DLL is not DataGenerator.dll (in cases A+B) then I have the "FileNotFoundException" run-time error...
Thank you for helping,
Yours,
Zsolt
I'm going to close this, as I believe the original issue is resolved.
@anoftc The file name has to match the assembly name. Renaming a DLL will break things. It sounds like in your case it builds successfully but fails to run. Perhaps we should detect this and fail to build. If you would like to propose that, can you open a new issue? Thanks.
Most helpful comment
I think you might be right. I think this is still an issue.