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)

Most upvoted comments

@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.