Answered by:
Reference to .NET Core Class Library project not working

Question
-
User-346337027 posted
Windows 10, Visual Studio 2015 Update 3
I have a .NET Core Class Library project, ClassLibrary1, set up to target both netstandard1.6 and net461. I have a second .NET 4.6.1 Console Application, ConsoleApplication1, from which I have created a project reference to ClassLibrary1. If I examine the properties of the ClassLibrary1 reference in the ColsoleApplication1 project I find the Path is as expected, i.e. pointing to ClassLibrary1.dll in the ClassLibrary1\bin\Debug\net461 folder. However, in ConsoleApplication1 code I cannot access anything from ClassLibrary1. It's as if I don't have a reference. If, on the other hand, I copy the ClassLibrary1.dll file from the location specified in Path to a temp location and then create a external reference directly to that file (instead of project reference) I suddenly have access to the contents of ClassLibrary1.
External (file) references are working but project references seem to be ignored.
Monday, July 4, 2016 4:29 AM
Answers
-
User1066278571 posted
It is not possible to reference a xproj from a csproj directly.
You have 2 possible solutions for this.
A) Deploy the xproj as a NuGet package and use the NuGet package in your csproj.
B) Convert your csproj to a xproj.
Note: the xproj must support your used .NET csproj. net451 etc.
Here's an example of a csproj referencing a xproj NuGet package
https://github.com/damienbod/ElasticsearchCRUD/tree/master/samples/ConsoleElasticsearchCrudExampleGreetings Damien
- Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
Saturday, July 16, 2016 8:30 AM
All replies
-
User1289604957 posted
Hi,
Would you please share your code somewhere that I could have a look?
Thanks.
Maher
Monday, July 4, 2016 4:57 AM -
User-346337027 posted
There really isn't any "code" to share, it's a simple two project solution with nothing but the boiler plate code but you can get it from my OneDrive share here:
Wednesday, July 6, 2016 5:33 PM -
User-346337027 posted
One more try. Anyone?Tuesday, July 12, 2016 7:05 PM -
User1289604957 posted
Hi Dane,
I really apologize for my late reply. Here is my answer : https://1drv.ms/u/s!AoEG4e-9c3Pop4ASyCwQRDpeR909OA
How do you think about it?
Best,
Maher
Tuesday, July 12, 2016 9:41 PM -
User-346337027 posted
Thanks for the reply but that solution doesn't appear to address the issue. Unless I'm missing something It looks like you've simply added a new .NET Core Console App and then added the reference for ClassLibrary1 to that. That will indeed work but the issue I ran into is in adding a reference to a .NET Core project in a .NET Framework (full framework) project. This "should" work if the correct framework target is added to the .NET Core project (which it is) and in fact works if you reference the compiled assembly from the Core project but does not work with a project reference. This appears to be some sort of defect in how VS is handling references for Core project.
Wednesday, July 13, 2016 5:43 PM -
User-346337027 posted
I was able to find a work around for this issue. If you check "allow unsafe code" in the console app the project reference to the .NET Core Library behaves as expected. There's still an issue though as that should not be required and is not required if you add a reference directly to the compiled assembly file instead of the project. I'll open an issue for this.
Thursday, July 14, 2016 6:00 PM -
User-346337027 posted
It turns my previously stated work around does not actually work. I'd thought it did but I cannot replicate it in any of three separate solutions now. I think I may have had a direct file reference with "allow unsafe code" instead of a project reference.
This remains an issue. Another user encountered the same issue and posted it on stackoverflow a couple days ago. No resolution there yet either.
http://stackoverflow.com/questions/38369279/how-to-reference-xproj-into-csproj
Saturday, July 16, 2016 3:10 AM -
User1066278571 posted
It is not possible to reference a xproj from a csproj directly.
You have 2 possible solutions for this.
A) Deploy the xproj as a NuGet package and use the NuGet package in your csproj.
B) Convert your csproj to a xproj.
Note: the xproj must support your used .NET csproj. net451 etc.
Here's an example of a csproj referencing a xproj NuGet package
https://github.com/damienbod/ElasticsearchCRUD/tree/master/samples/ConsoleElasticsearchCrudExampleGreetings Damien
- Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
Saturday, July 16, 2016 8:30 AM -
User-346337027 posted
Thanks for the reply. I've suspected for some time now that the issue is related to the reference of xproj in the csproj. However, I do think this is really a defect. It is possible to do this and, in fact, it's pretty close now. There's really only a couple purposes a project reference fulfills, i.e. understand dependencies to set project build orders and track locations of the compiled referenced assemblies independent of build configuration (Debug/Release). A reference to xproj in csproj does both of these now admirably. What I think is missing is the correct load of the compiled core assembly into the runtime's compiler environment.
I understand that both of your solutions could be employed to work around this issue. Also, direct file references and build macros would probably work but I see all of these as problematic.
Sunday, July 17, 2016 3:54 AM -
User1066278571 posted
true
I believe a lot could change here with the new project changes which are coming.
You could also create an issue on gitHub, and see if anything is planned to solve this.
Greetings Damien
Sunday, July 17, 2016 7:38 AM -
User-346337027 posted
Thanks again for the reply.
I asked members on gitter for dotnet/coreclr where might be an appropriate place to enter an issue since I couldn't find a GitHub specifically for .NET Core tooling in VS. It was suggested I should enter an issue directly from VS2015 which I did. If you know of a GitHub repo that might be applicable I'd definitely be will to add an issue there as well. I've entered VS issues before with mixed results.
I'm going to mark you first reply as an answer. I think this is a tooling issue at this point and it doesn't seem like we have options outside of the types of work-arounds you've suggested.
Sunday, July 17, 2016 6:52 PM -
User1066278571 posted
Thanks, what's the issue link? I would like to watch this as well
Greetings Damien
Monday, July 18, 2016 8:13 AM