runtime: Assembly.LoadFrom throws 'already loaded' even if the assembly is not in memory
I am using 2.0.0-preview1-005977. I have a Self Contained Deployment folder with all the needed dependencies to run my code. The hosting part (exe) is in C++, so I load the CLR, create the AppDomain, load a first Assembly and everything works fine.
Later on, when C++ requests for it, I execute some .net code that execute an Assembly.LoadFrom(fullpathassemblyname.dll).
This causes the following exception:
System.IO.FileLoadException: 'Assembly with same name is already loaded'
But the assembly is not in memory. I can’t see it either in VS Modules while debugging or even in process explorer.
The code I use to load the assembly is:
var assembly = Assembly.LoadFrom(fullname);
or
var assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(fullname);
For testing purposes only I also tried the following:
var assembly = Assembly.LoadFile(fullname);
and it works but it is not suitable as it loads just the given assembly and not the entire graph (if any).
So I have two questions:
- why Assembly.LoadFrom throws even if the given assembly is not in memory?
- if I remember well, the Assembly.LoadFrom of the .NET Framework does not throw even if the assembly was already loaded. Why did the behavior change?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 30 (16 by maintainers)
@dagood This discussion is about gitlink support for C/C++ code. I believe that gitlink works for C/C++ fine, with classic non-portable PDBs. The portable PDBs should not be tied to this - there are no portable PDBs for C/C++.
I haven’t debugged CoreCLR myself, but building your own CoreCLR does sound like the most straightforward way to get PDBs pointing at your sources.
I believe MyGet repoints PDBs for their symbol package sources support, meaning it’s possible, but I’m not familiar with tooling to do that.
@raffaeler that’s because it’s a private repository.
@dagood, can you help with @jkotas question?
Yes, the symbols should be published.
I would run the process under C++ debugger (either attach as “native” in visual studio; or use windbg), stop on C++ exception and get the stacktrace where the C++ exception is thrown. The C++ part of the runtime is using C++ exceptions for error handling, so stopping on C++ exceptions tends to be a good way to find out where things went wrong.