VS2015 unable to resolve references to class library in solution

[austinlparker]

Since updating to beta 8, VS2015 is unable to resolve references to my class libraries. The libraries are wrapped, and the solution builds and runs correctly - I am unable to use intellisense or autocomplete, however. I was able to reproduce the issue in a new MVC6 solution created with the beta8 tools; I created a solution with a new MVC6 project and then added a class library (non-packaged) to the solution. I then removed the reference to core CLR from project.json and switched the class library to build against .NET 4.5.1. I then added the new class library to the project.json via right-click 'Add - Reference', restored packages, and confirmed that the class library appears in the solution explorer. After this, I attempted to reference the new class library via a using statement, and VS shows an error claiming that the type or namespace does not exist. I am able to build the solution, however.

[felipem]

I've had this exact same issue. Externally referenced .NET 4.5 projects are not recognized in VS2015. The project (ASP.NET MVC Web API 6 project) builds and publishes just fine but VS2015 visually marks any references to the external library as errors and intellisense doesn't recognize objects in the libraries.

Any solutions to this? I've tried clearing the dnx package cache, re-getting source from source control into a new path.

Thanks,

[sayedihashimi]

So this is a regression from previous releases?

[felipem]

Perhaps? I couldn't get external references working in beta7 due to issues mentioned on issue #120 so can't really say if this issue existed before.
In Beta8 it worked perfectly for a few weeks until I applied a workaround to publish as mentioned on asp.net issue dotnet/aspnetcore#1017

[felipem]

Found a temporary workaround until this bug is fixed.

It seems that if the project.json files for the external references in wrap folder have a reference to the 'dnx451' framework than it seems this bug appears. So the simple way to get Visual Studio 2015 to 'see' the external .NET libraries again are as follows:

1. Close or unload the project in question
2. Go into each project.json file in the wrap folder and replace framework dnx451 with net45 (or remove dnx451 if you have both frameworks referenced).
3. Reload the project
4. Now you can re-add the dnx451 framework reference in the project.json files again. This is needed to get around the publish bug mentioned previously (Can't publish asp.net 5 application after update to beta8 - the dependency … could not be resolved dotnet/aspnetcore#1017).

Obviously a sucky workaround for two bugs. Hopefully fixed soon!

[sayedihashimi]

Sorry for the delay here. Is this still an issue?

[miloush]

VS 14.0.24720.00, ASP.NET tools 14.1.11120.0. (Update 1)

1. Create a new ASP.NET Web Application (framework version left to default 4.5.2)
2. Select Empty Web ASP.NET 5 Template
   (ignore the JavaScriptWebExtensionsPackage package load failure I guess)
3. Right click on Solution and Add New Project.
4. Select Visual C# > Class Library (framework version left to default 4.5.2)
5. Edit project.json /frameworks to have only net452 (note there is no intellisense for these values :()
6. Save the file which creates bunch of errors and turns references section into warning.
7. Right click on the web project and do Restore Packages (this should not be necessary for me).
8. Right click on the web project and Add Reference.
9. From Solution, select the class library project just created.
10. You get NU1001 The dependency ClassLibrary1 >= 1.0.0-* could not be resolved (this should not happen either).
11. Okay, maybe it needs building, build the solution. Nothing changes.
12. Restore packages and builds solution again (this should not be necessary for me)
13. You get MSB3274 warning The primary reference ... could not be resolved because it is against the 4.5.2 framework. This is a higher version than the currently targeted 4.5.1.
14. Note that 4.5.1 version was nowhere mentioned or selected. And does not seem you can change it. Also probably relevant to DNX4.5.1 selected as framework even if I select 4.6 inside VS when creating project (RC1) #326.
15. Well go ahead and change the new library project to target 4.5.1. Note you might be not able to do this with existing libraries.
16. Save the project and build the solution. Success!
17. Go to Startup.cs and wherever, e.g. in ConfigureServices, type Class1.
18. Not resolved. Try fully qualified name: ClassLibrary1.Class1 c;
19. CS0246 This type or namespace 'ClassLirbary1' could not be found.
20. Build the solution again, output window says success.
21. Hit F5 to check if it really works. Browser opens but never loads the web site, any breakpoints created in the code remain unresolved.

This still looks like an issue to me, and really non-trivial amount of work needed to add a class library to a web site!

[sayedihashimi]

TFS: 174588
I've added this to our internal TFS, we will reply back here soon.

[sljohnst]

Chiming in here with what seems like it might be another variation of this problem...

I'm running VS 14.0.24720.00 Update 1, ASP.NET and Web Tools 2015 (RC1 Update 1) 14.1.11120.0.

I create a new solution containing an ASP.NET web application with .NET Framework 4.5.1. I add an existing class library project (non-packaged) to the solution. If I add a project reference in the web app to the class library, I get the NU1001 "The dependency ChartCapture.Common >= 1.0.0-* could not be resolved" error, and I cannot build.

Adding a project reference in this scenario will create a “wrap” folder at the project level, which isn’t working.

Adding a new non-packaged library project to the solution and then adding it as a project reference in a web app does not cause this problem. It only occurs for existing projects that were not created in my solution.

Workaround:

1. Build the class library project.

2. In the web application, add an assembly reference to the class library DLL. This will create a “wrap” directory at the same level as the solution file, and it contains a project.json file for the class library.

3. I can convert the assembly reference to a project reference by editing the project.json file, adding the wrappedProject entry.

4. To see the resulting change in the reference in the IDE, close the solution and reopen it.

Here is example of a project.json file (at the solution level) BEFORE I have edited it:
{
"version": "1.0.0-*",
"frameworks": {
"dnx451": {
"bin": {
"assembly": "../../src/Common/obj/Debug/Common.dll",
"pdb": "../../src/Common/obj/Debug/Common.pdb"
}
}
}
}

and AFTER I have changed it to a project reference:
{
"version": "1.0.0-*",
"frameworks": {
"dnx451": {
"wrappedProject": "../../src/Common/Common.csproj",
"bin": {
"assembly": "../../src/Common/obj/{configuration}/Common.dll",
"pdb": "../../src/Common/obj/{configuration}/Common.pdb"
}
}
}
}

[sljohnst]

Update...

1. I cannot make the project.json entry configuration-neutral by replacing 'Debug' with '{configuration}', like I did in my previous post. If I do, I get build errors when I write code using the class library, because classes in the class library cannot be found.
2. Even though I can convert the assembly reference to a project reference (by manually modifying the project.json for the class library, adding a wrappedProject, as I mentioned above), and the projects will successfully build, this messes up Intellisense.

So, for now, it's probably best for me to just use an assembly reference to the class library's Debug DLL.

[ilyalozovyy]

I think I am having a related issue.
Running VS 14.0.24720.00 Update 1, ASP.NET and Web Tools 2015 (RC1 Update 1) 14.1.11120.0

Created a ASP.NET WebApi project and added a second Class Library project using .NET 4.5.
In the Class Library project I am trying to add a reference to 3 dlls to make SCCM SDK calls:

adminui.wqlqueryengine
microsoft.configurationmanager.managedbase
microsoft.configurationmanagement.managementprovider

The first two DLLs are loaded without any issues however the last one ending with "managementprovider" is giving me the following error:

"NU101 Dependency microsoft.configurationmanagement.managementprovider >= 1.0.0-* could not be resolved"

I've tried the recommendations listed above without any luck.

[ilyalozovyy]

I was able to solve the issue but I think that there is a bug somewhere here.
I noticed when I removed the assembly that was causing the problem from the "dependencies" section in the project.json and performed a build or executed "dnu restore" command that the issue still occurred.
I had to open up one of the project.json files in the "wrap" folder for the "adminui.wqlqueryengine.dll" that had a "dependencies" section as well and remove it from there and then everything started to build and restore without any problems.

[abpiskunov]

@sljohnst Can I see your global.json?

Also what is relative folder structure of your solution root comparing to a project reference you are trying to add? (I assume you used Add Reference dialog to add a project reference?)

[javivalero]

Really a big problem, if we can't add references to class libraries. A work around could be add as nuget package, but we loose the capability to debug.

I a m working in a project and we have decided start with the ASP.net core and MVC6, so a work around will be appreciated.

[jonbartlam]

@javivalero Joined so I could post this as I've been struggling with the same issue. Can you confirm if this works for you as I've managed now to reference Class Projects within a Asp.Net 5 solution. It's worth noting that my class projects were in a completely separate path from the web project.

In my case you have this structure (I'll use these in the examples below):
Dev\WebProj\WebProj.sln
Dev\Classes\class1\class1.csproj
Dev\Classes\class2\class2.csproj

Here are my steps (apologies if any of this is condescending - don't mean it to be):

• Ensure targetting framework 4.5.1
• Remove core 50 from frameworks in Webproj project.json
• Right click solution, Add existing projects -> class1.csproj
• Right click solution, Project Dependancies and select them so they build when building the solution
• Right click references in Webproj and select class 1. You'll get the error but that's ok for now.
• In explorer, navigate to Dev\Classes\wrap\ and copy
• Navigate to Dev\WebProj\wrap\ and paste
• Edit Dev\WebProj\wrap\class1\project.json
• Change the paths to be the relative paths to the files it references in the class1 project folder. For example mine were ..\class1\class1.csproj (the paths are relative to the wrap folder) which I changed to ....\Classes\class1\class1.csproj
• Right Click References inside of WebProj and click restore. It should now resolve without an error being thrown.

What seems to have happened, at least with me, is that when referencing the csproj, the wrap folder was created in the classes project folder where it should have been in the webproj folder, pointing to the other projects location. Seems like the assumption is that in most cases, the classes projects will sit in the web projects folder directly, as when adding a class project directly, it works fine.

Hope this helps. Let me know if I can clarify anything, or whether it works

[pranavanmaru]

Using VS2015 to Build an MVC6 site and I'm not facing issues trying to refer my class libraries....
I can't even refer Microsoft's MVC reference itself ! :) Opened up queries everywhere still no hope !
using Microsoft. has only C#,VBNET and WIN32. I'm able to see the reference in the solution explorer but not in the code.

[abpiskunov]

@pranavanmaru I am not sure if I understand your comment. Could you please add step by step details about your scenario?

[pranavanmaru]

@abpiskunov it was a mistake I did !
My folder structure was accidentally created inside the wwwroot and I didn't notice it until wasting too much time !

[dimasmessias]

I had the same failure.
Here goes what I've done to solve:

1. Right click "Solution"
2. Click "Project Dependencies"
3. In "Dependencies" tab select your project in dropdown
4. Check the projects needed
5. Hit "OK" after finished
6. In the project that you need to add those references, right click "References"
7. Check the projects needed
8. Hit "OK" after finished
9. Build the solution

Before you build the solution, it may show some red squiggles.
This may solve it.

[pranavanmaru]

@dimasmessias
this was a completely different case. I had all of those references and was just not able to resolve them because i had the server side controls created inside "wwwroot" by accident. The compiler doesn't resolve references inside wwwroot I guess. Which is why I was not able to resolve the references I typed down even if they were available in the "References" section of the solution explorer.

[sclode]

@jonbartlam - thanks for the detailed explanation. Your fix worked for me.

[BradRem]

@jonbartlam You're detailed explanation makes sense, but I just can't get it to work for my solution. I have an ASP.NET core web project and I can not get it to locate the references to my .NET 4.5.1 class library projects.

I guess it makes sense that the wrap files that get created under the class library, should really go under the web project (with the corrected paths), but how does the web project now about them? Is it strictly convention or shouldn't we have to make some changes to either the global.json file or the web projects project.json file?

I'm a little baffled at why not more people are having a problem with this -- I would think there are a considerable number of people who are going to want to transition over to the new asp.net, but still target older class libraries.

[jonbartlam]

@BradRem Apologies for the delay. Had to double check but it looks like if you check under solution Items > global.json, it shows wrap as a project. In the root of the project directory, you'll find the corresponding wrap and src folders (although test folder is missing on mine).

Here's what mine looks like from the example above:
{ "projects": [ "src", "test", "wrap" ], "sdk": { "version": "1.0.0-rc1-update1" } }

I'm guessing it will pull all other projects project.json files from the folders below wrap.

I'm with you regarding more people not having this problem.Information on fixing this is more difficult to find than I'd have thought, and all the solutions that were available didn't work for me.

[BradRem]

@jonbartlam After creating a brand new solution with an empty core web project and an empty "old" class library and having that work, I found what was causing my problem by looking at the differences between my project and the new project: the folder structure of the solution.

• MyFolder
• ____Class Library
• ____WebProject
• ____Solution
• .......|___MyApp.sln

When the solution file is in a subfolder of the folder structure, the references and wrap files just don't work. The folder structure that creates the proper wrap files and works is:

• MyFolder
• ____MyApp.sln
• ____Class Library
• ____WebProject

Don't put the .sln file under a sub folder; it needs to be in the root folder.

[juri33]

This ist strange. I had the same issue and couldn't fix it

The folder structure was:

• MyFolder
• __/SolutionFolder/
• ____MyApp.sln
• ____Class Library
• __/WebAPI with reference to the class Library

This didn`t work. ... could not resolve reference...

So i have moved the class library one higher:

• MyFolder
• __/SolutionFolder/
• ____MyApp.sln
• __/Class Library
• __/WebAPI with reference to the class Library

And it works now....

[jonbartlam]

All slightly different set ups but the solution seems to be the same throughout - folder structure isn't correct when originally adding the references. Perhaps this is something that MS should be addressing - or at least document it so it can be found easily? Not sure who would be best contacting over this as I'd be happy to pass this on?

[leontyr]

In my case, removing "dnxcore50" from project.json resolved it.

[balachir]

Tooling for .NET Core RC2 got released today. This now has better support for referencing .NET Framework class libraries from an ASP.NET Core project on .NET Framework.

[rchamila]

I'm having the same issue even with RC2. Seems something to do with intellisense,

[abpiskunov]

@rchamila There were multiple scenarios in this issue. What exactly is your scenario and repro steps with RC2? Could you share your sample solution please (a github link?)?

[rchamila]

hi @abpiskunov looks like its working now. I'm not sure what has changed. Bit looks ok now.

[punmechanic]

I still appear to be experiencing this issue with RC2 as well.

I've wrapped two .dlls that work on .NET 4.5 in project.json like so

{
  "frameworks": {
    "net45": {
      "bin": {
        "assembly": "TapiConnectSDK.dll"
      }
    }
  }
}

Intellisense is unable to reference these correctly from net45 projects; they build fine with the dotnet tool. I'm using RC2.

EDIT: Apparently they don't build either, so it looks like I'm doing something catastrophically wrong.

[stormleoxia]

Hi,
I've got the same problem. It's limited to Intellisense (it builds fine).
It's really annoying because it affects xunit test project and when you try to make test driven
it gets in the way.
I've narrowed it to the following situation:
- Class in Library project are not seen as valid in Console/Web App projects.
The following works:

• A class in a Console/WebApp is well recognized from a referencing Console/WebApp.
• Class from Library project referenced by another Library project is also seen as a valid class.
  I've added a Github link to a sample solution where I've tried to check all cases.
  https://github.com/stormleoxia/lxdotnetcore

In this test class, MyLibClass is not viewed as valid by Intellisense.
https://github.com/stormleoxia/lxdotnetcore/blob/master/test/Lx.SampleLib.Test/MySampleLibTest.cs
I'm using Visual Studio 2015 Update 2.
EDIT: I've tried with RC3 ... Issue remains. (Should I open an issue ?)

[abpiskunov]

@danpantry could you please share zip with your sample solution?

[abpiskunov]

@stormleoxia Could you also share your solution please? Or narrow it down to a sample that has same problem..

[punmechanic]

@abpiskunov Unfortunately, no, as it is closed source, however the solution is quite literally just that project file (with a binary of your choosing) being linked to by another project.json being built with the net451 framework.

[abpiskunov]

Well if it would be just that, we could repro it :). I need to know contents of your xproj files and project jsons for all projects to see what are targets and if dependencies were added correctly. Could you just create a small sample that reproduces your problem and share that?

[punmechanic]

I mean, here's an example of what I haev right now:

./precompiledLibrary/project.json

{
  "frameworks": {
    "net451": {
      "bin": {
        "assembly": "precompiledLibrary.dll"
      }
    }
  }
}

./precompiledLibrary/precompiledLibrary.xproj

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>
  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.Props" Condition="'$(VSToolsPath)' != ''" />
  <PropertyGroup Label="Globals">
    <ProjectGuid>0d4784e6-b6b3-43dc-b4c6-75b186560fc5</ProjectGuid>
    <RootNamespace>PrecompiledLibrary</RootNamespace>
    <BaseIntermediateOutputPath Condition="'$(BaseIntermediateOutputPath)'=='' ">.\obj</BaseIntermediateOutputPath>
    <OutputPath Condition="'$(OutputPath)'=='' ">.\bin\</OutputPath>
  </PropertyGroup>

  <PropertyGroup>
    <SchemaVersion>2.0</SchemaVersion>
  </PropertyGroup>
  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.targets" Condition="'$(VSToolsPath)' != ''" />
</Project>

./Services/project.json

{
  "version": "1.0.0-*",

  "dependencies": {
    "precompiledLibrary": "1.0.0-*",
    "NETStandard.Library": "1.5.0-rc2-24027"
  },

  "frameworks": {
    "net451": {
      "imports": "dnxcore50"
    }
  }
}

./Services/Services.xproj

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>
  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.Props" Condition="'$(VSToolsPath)' != ''" />
  <PropertyGroup Label="Globals">
    <ProjectGuid>627e690c-6b1d-4a3b-91f3-b5bb1b9cd761</ProjectGuid>
    <RootNamespace>Services</RootNamespace>
    <BaseIntermediateOutputPath Condition="'$(BaseIntermediateOutputPath)'=='' ">.\obj</BaseIntermediateOutputPath>
    <OutputPath Condition="'$(OutputPath)'=='' ">.\bin\</OutputPath>
    <TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
  </PropertyGroup>
  <PropertyGroup>
    <SchemaVersion>2.0</SchemaVersion>
  </PropertyGroup>
  <Import Project="$(VSToolsPath)\DotNet\Microsoft.DotNet.targets" Condition="'$(VSToolsPath)' != ''" />
</Project>

This is just after wrapping precompiledLibrary.dll in a project.json and then referencing it via the Visual Studio menu.

[stormleoxia]

@abpiskunov the solution is here https://github.com/stormleoxia/lxdotnetcore
it's just a sample solution containing several projects (no real code): its sole purpose is to show the problem. If you want to reproduce it, just add a project Library reference from another project which is not a Library project (either Console or Web Application), all of them in the same solution.
If you open https://github.com/stormleoxia/lxdotnetcore/blob/master/Lx.Sample.sln
in
https://github.com/stormleoxia/lxdotnetcore/blob/master/test/Lx.SampleLib.Test/MySampleLibTest.cs
the MyLibClass part of
var myClass = new MyLibClass();
remains red.
@abpiskunov : Sorry in fact it's not related with the tooling (issue with Resharper)

[Sn3b]

Is there a fix for this? I seem to be experiencing the same issue... Was fine with RC1 but now I get all references to external dlls in red, and it compiles fine...

Nevermind, didn't know you can just reference assemblies without going through wraps in RC2...

[martinmani]

Usually csproj type project is created when full framework is targeted (for the referenced or library project).
Seems like visual studio have some dependency on the referenced project's xproj file when it is added to xproj type project (.net core projects).

I have resolved this by creating a dummy xproj file in the same folder of the referenced project and add it to the solution. intellisense assistance will be back.

Note: Doing this there will be two project for the same in the solution. You can open the classes and other resources from either project since they are under the same path and files.

Hope this workaround helps, cheers....