-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't resolve some assemblies when targeting .NET Core 'Class Library' projects #7
Comments
@anurse Hi Andrew, I'm stuck on an issue related to .deps.json files and assembly loading (see above). I was wondering if you'd be up for taking a look or forwarding me to someone who might know. I've been pulling my hair out for most of today trying to work out what's going on. Thanks, Jamie. |
could you provide your project.json file? |
Do you have the ability to set an environment variable and capture the stdout/stderr of the process you're launching? If so, set the The deps file does look correct as far as I can tell. It would also help to provide a full listing of the content of the output directory (perhaps easiest done by doing to the root of your project and running |
The project.json is pretty unremarkable. Here is is:
I'll try COREHOST_TRACE=1 and see if that gives us any clues... |
@anurse Here is the log with COREHOST_TRACE=1. I don't know why the error lines are doubled up. Does anything spring to mind? Here is the gist: Does the following make sense to you?
Thanks, Jamie. |
I can see why the lines are doubled up. If you run the following:
...it will output:
It seems lines are being terminated with Where would be the best place to report this? |
That would go to the https://github.com/dotnet/cli repo |
It looks like The project.json you showed above looked like a library, not an application (since apps need a dependency on |
The way I'm calling it is a little unusual, but it works most of the time (with both core and 3rd party assemblies). The command line looks something like this:
ConsoleApplication.dll loads the ClassLibrary.dll assembly and runs one of its methods using reflection. It loads the assembly using this:
I found that calling Is there any way I can make this work consistently? I.e. invoke an arbitrary assembly from a console app. It currently works most of the time. 😉 |
Ah yeah, I see the problem there. The |
I looks like
...it outputs this:
The following works when inside a class library:
...giving me:
...but the trace example gives:
I don't understand what the difference is. From what I can see they're both inside the |
So to summarize, what you're trying to do is to run a Console App that you provide (aka Runner), using the This isn't really going to be feasible with the current model. Right now, the .NET Core SDK tools make a distinction between a Class Library and a Console Application and do not emit certain data necessary to execute the code unless the project is a Console App. This doesn't normally cause any problems because a Class Library will eventually be referenced by a Console App and the necessary data will be calculated, but in your case you are trying to dynamically launch a Console App using a specific Class Library output. If this scenario is important, I suggest filing a bug on dotnet/cli to help get it tracked for the future (basically just filing a bug with your current scenario and the expected behavior should help make things pretty clear for those folks to start examining the best way to move forward). In the short term, this is probably a place for a custom Something like the following pseudo-code public class MyCustomLoadContext : AssemblyLoadContext {
private string _baseDirectory;
public MyCustomLoadContext(string baseDirectory) { _baseDirectory = baseDirectory }
public Assembly Load(AssemblyName name) {
// Find [name].dll in the _baseDirectory
// Maybe search NuGet cache? You could, in theory, load the deps file here and do your own processing with it, but it's not quite going to have the data you want...
}
}
public static void Main(string[] args) {
var pathOfAssemblyToTest = /* ... */
var baseDirectory = Path.GetDirectoryName(pathOfAssemblyToTest);
var name = Path.GetFileNameWithoutExtension(pathOfAssemblyToTest)
var asm = new MyCustomLoadContext(baseDirectory).Load(name);
// party time with 'asm'
} This means you'll be on your own for NuGet package resolution as well unfortunately, since that's only done in the native .NET Core Host start-up code. I'm sorry it's not a nice easy solution. This isn't a scenario that's really been a priority for the .NET Core 1.0 release so it is a little lacking :(. |
@anurse Thanks for taking the time to explain this. I'm still attempting to wrap my head around it. all 😉 I've tried adding a workaround along the lines of your example. Unfortunately the process keeps quitting with an Here is a repro:
...this outputs the following (never getting to "Done!!!"):
Any idea what's going wrong? |
That's not the pattern I'm familiar with for working with Load Contexts. Generally, you create your custom context and implement Load (by using the other methods available on the base class), then you construct your custom context and call Load on it directly. I'm not sure if that's what's causing the issue but it wouldn't surprise me too much. The idea here is to load your target assembly and all it's dependencies using that load context, which is what the pattern I referenced above should do. |
@anurse I've been having a frustrating time trying to get AssemblyLoadContext to work. Where is the best place to find documentation for this part of the framework? I keep running into an issue where resolving an assembly causes the process to quit with a Here is a repro test/console app: |
This is a known issue in the .NET Core 1.0 release. Should be fixed in next version. See: Workaround is to pre-load and dependent assemblies. |
Glad you found an answer, sorry I hadn't gotten a chance to look in to this! |
@anurse No problem, I appreciated your earlier input! I see there's as issue for AssemblyLoadContext documentation here: Subscribed. 😄 |
I did hear they were getting some docs together, so hopefully progress will be made there soon :) |
Added a workaround that fixes this for |
This works fine for some assemblies. For example, you can reference the NUnit package and 'Run Test(s)' on the following:
However, if you reference 'System.Diagnostics.TraceSource' and try this:
...you get the following error:
My 'ClassLibrary1.dll.deps.json' file looks like this (expand to view).
The text was updated successfully, but these errors were encountered: