Aspnetcore: .net core projects only support referencing .net framework assemblies in this release

[dotnetdeveloper786]

i am getting this error when i am trying to add reference of 3rd party dll that not on nuget i am using Asp.Net Core Web Application(.Net Framework Standard 4.6)

[rdefreitas]

Can you provide any details of the 3rd party DLL?

[dotnetdeveloper786]

Yes Stripe.dll and SimplePsd.dll both are not available on nuget

[MV10]

@rdefreitas the DLL details don't matter, VS2015 throws this error trying to reference _any_ DLL via the Add Reference dialog. Fire up VS and build a simple class project then try to reference that DLL from any core project (even a console app) and you'll see this message every time.

Our team really wants to begin using MVC Core because we don't want to base a large new years-long project on the old stand-alone WebAPI, yet this problem is giving us a lot of heartburn. We can get around it with NuGet packaging but that's a big hassle when the DLLs are in active development and changing frequently (versus just referencing them in a centralized build-target folder somewhere).

[rdefreitas]

@MV10 @dotnetdeveloper786 I didn't try this with the current version of the tooling for Visual Studio... it was one of the nightly builds sitting on my machine at the time.

I'll see if I can figure out a workaround, as I've got a couple of projects where I did pull this off.

[MV10]

In my case this is with VS2015 Update3 and .NET Core 1.0 with tooling Preview 2, which I think is still current. (Since it also affects things like Core console projects I wondered if it might belong over in one of the rosyln gits somewhere...)

[rdefreitas]

@MV10 this is probably the right place to start...
@rowanmiller do you know who the right person on the team would be to look at this, or the best repo to open an issue is?

[dotnetdeveloper786]

@MV10 @rowanmiller but if i create portable class library and than i add that dll as reference and then i add this portable library reference in my core web application it's working fine but i am not able to add reference of that dll directly in to my core web application it throws me above exception
so what to do?

[MV10]

@dotnetdeveloper786 yes, my point was that it doesn't matter what kind of DLL you try to add, a core project always shows that error. I was agreeing with you and that is the issue they're investigating now.

[rdefreitas]

@MV10 that's why I asked Rowan. He's a member of the asp.net team and would probably know who the best person is to address this. I'm just a lowly community member like you ;-)

[gulbanana]

it is likely that the conversion back to msbuild will fix this issue

[avoxm]

I am having the same problem. Is there any workaround for this ?

[MV10]

I have to put my files into a NuGet package locally, set up that folder as a NuGet source, browse to the package and load it up that way. Then when I change the DLLs, I update the package then update the version (and filename) and load the new file. Or, since I don't want useless old packages proliferating, save with the same version/filename, blow away the global package cache (batch file), then do a full restore in all referencing projects (which, incidentally, also requires me to close all open VS instances otherwise NuGet will throw file-locked errors).

It's pretty annoying. (And in my case it's worse than that since part of the project requires a companion set of .NET 3.5 assemblies and isn't NuGet compatible, so there is more batch-file jockeying to update that project too.)

How this got through testing without anybody doing a simple Add Reference is beyond me. Isn't that what Unit Test coverage is all about? Do they really not have test coverage for VS and tools???

[harald]

Same problem here (VS Update 3, Tooling Preview 2). This is more than annoying. It makes .NET Core pretty much useless for enterprise development. When will this be solved?

[MV10]

Another report: 1612
And a dupe by the same OP: 1661

I've noticed this issue posted in other repos as well (and not getting any official attention).

I still question whether "aspnet" is the right repo area for reporting this issue (and having any chance of somebody from MS paying attention to it). Awhile back I stumbled across a repo called "roslyn-project-files" or something similar, which sounds like it might be an exact match for the team that might care about this, but I spent 90 minutes this morning paging thru github project lists and search results, and I can't find it again. Ring any bells with anybody?

Edit, found it: roslyn-project-system

Is that a better place to report this issue?

@aarnott, since you work with VS at the project level can you perhaps comment or offer guidance?

[AArnott]

If your focus is on ASP.NET scenarios, this is probably the right place.
roslyn-project-system is for a new C#/VB project system (based on CPS) that includes .NET Core support I believe, but may or may not replace ASP.NET's project system for web scenarios (I just don't know).

[Tenmak]

Then I don't get either why nobody is answering to that bug... I mean... it's very annoying not to be able to reference a single .NET 4.X DLL...

[harald]

Indeed. The very existence of that bug suggests to me that whoever is developing .NET Core is not actually using it for any real-life projects. As MV10 already said, it is really puzzling how such a fundamental bug could possibly slip through basic testing.

I was tasked to assess if .NET Core is ready for production development.
My answer at this point is a clear No.

[AArnott]

The history of this from my understanding is that the folks who developed the tooling we have today envisioned every single project belonging to their system, and their system creates nuget packages automatically for every assembly. So it wasn't an issue, if you were entirely in the new system.

Going forward the tooling will be MSBuild based, and I _expect_ that means assembly references will be allowed again.

[muratg]

I recommend reporting this on dotnet/cli or dotnet/corefx repos, as this is not an ASP.NET problem.

And I think @AArnott is right.

[MV10]

@muratg I don't have need to use the command line tools myself so I haven't tested whether it's a problem at that level, and corefx is about the core libraries which definitely doesn't sound relevant to project/reference issues.

@AArnott are you saying we probably have to wait for VS 15?

[muratg]

Referencing stuff is all in CLI now (It's true that ASP.NET had that before we moved from DNX to dotnet.)

[MV10]

@muratg Can you set up a quick test and let us know how it goes? On the VS side you can literally create a stubbed-out do-nothing DLL then ref from a console project and it fails. I'll be happy to move the report over there if it's a problem.

This issue brought our decision to use core to a screeching halt on a very large project (and everybody I know in the enterprise world was already unnerved by the project.json/msbuild overnight reversal).

[muratg]

@MV10 Sorry, don't have time. There's enough people reporting the problem (including yourself), so I do believe that there's an issue. :)

[muratg]

cc @piotrpMSFT

[TheRealPiotrP]

@MV10 please see the pattern for wrapping loose dll's here:
https://github.com/dotnet/cli/tree/rel/1.0.0/TestAssets/TestProjects/TestAppWithWrapperProjectDependency

You will need to add a project-per-dependency.

If that doesn't unblock you, let's move this to https://github.com/dotnet/cli.

[pantonis]

Major blocking issue!!

[omuleanu]

so what is the latest solution ? do we just create nuget packages and add them to a local source ?

[jmcglory]

I would like to know if there is a fix for this yet

[Tenmak]

There isn't and the only thing I managed to do was to setup a .net framework 451 dependency.

[omuleanu]

I actually need to reference .net core (.net standard 1.6) dlls, and I had to create .net package for this

[muratg]

@piotrpMSFT Is there a dotnet/cli bug tracking this?

I'd like to move this discussion there, and close this bug on ASP.NET side.

[andrey-moor]

Any updates on this?

[sohamchakravarty]

This is a huge blocker! Any updates on this yet?

[gulbanana]

it works fine in vs2017 using csproj. it will not be implemented for vs2015 and project.json.

[joebri]

I'm fairly new to NuGet so this might be 'old-hat' for some. But, for those who pursue the 'publish NuGet package' option I've just discovered that you can configure NuGet Manager to point to a local directory.

In Options...NuGet Package Manager...Package Sources, click on the + button (top right), and set the 'Source' to a local folder.

I have a step which creates NuGet packages and then copies them to this folder to be available for my .Net Core projects.

[krzysgl]

When adding a reference, use "Browse" tab, not the "Assemblies" tab. Then you can use unregistered libraries.

[pappasa]

In VS2015 there is no "Browse" tab in the "Reference Manager" form:

How can I add references to .NET Framework 4.0 assemblies?

[michaelarner]

Just want to add my weight to the "this is really annoying" camp. I should be able to use basic xunit with a basic class library in core.

[davidfowl]

@michaelarner This is talking about assembly references not project references so the scenario you mention works.

[michaelarner]

Thanks @davidfowl, sure doesn't work for me in VS2015 Update 3: I have a class library and an xunit project -- everything compiles and runs nicely, but I haven't been able to find anything that will let intellisense in my xunit tests see my class library..... ((an assembly OR project reference solution would be equally acceptable to me but neither seems to fly))

[davidfowl]

2 questions for ya:

• Can you put the sample on github?
• Are you using resharper?

[ShreekantG]

I have DLL say "MyCustom.dll" located under my local machine. I want to refer the same in my .Net Core application. I am having below json file.

{
"version": "1.0.0-*",

"dependencies": {
"Microsoft.ApplicationInsights.AspNetCore": "2.0.0",
"Microsoft.AspNetCore.Mvc": "1.1.1",
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"Price.Common": "1.0.0-*",//This is working as it is part of my main source.
"MyCustom": { "version": "1.1.13191.1" }//This is my new dll.
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"bin": {
"assembly": "D:/Clubcard/Shared-Libraries/Lib/API/MyCustom.dll"
}
}

}
}

Can any one help on how to reference the dll.

[michaelarner]

Thanks David.  I'm unable to put it up on github, but I >am< using resharper  (I also notice that if I open with 2017 RC1, which I just installed, and which hasn't been upgraded with resharper), the problem does not appear.
M.

On Sunday, February 19, 2017 1:03 AM, David Fowler <[email protected]> wrote:

2 questions for ya:

• Can you put the sample on github?
• Are you using resharper?
  —
  You are receiving this because you were mentioned.
  Reply to this email directly, view it on GitHub, or mute the thread.

[S-Raghav]

Is this issue fixed? I couldn't add Nunit to a .NET Core project from nuget since I got a "dependency Nunit >=3.6.1 could not be resolved" so I downloaded Nunit and tried adding references to the NetStandard1.6, 4.5 and portable DLLs. None of them worked

[S-Raghav]

I solved this for myself by making my test project a 4.6.1 Project instead of .NET core (NetStandard1.6), Nunit gets added. I am not able to add a project reference to netstandard1.6 project though. I have to manually add a reference by navigating to the project's Debug->netstandard1.6 folder and selecting the DLL

[zoehart]

I have a solution that has an ASP.NET Core Web Application (.NET Framework) project, and two Class Library (.NET Core) projects. One of the class library projects needs to reference some legacy .NET Framework 4.6 assemblies. I am having the same problem as many of the people on this thread and, like them, am wondering if there is any resolution.
I saw references to moving this topic to dotnet/cli, but looked there and could not find it.
I saw some references in this thread to maybe needing to package my legacy assemblies in nuget packages and add them to my .NET Core class libraries that way. Is that the recommended workaround at this point?
I am using VS2015 Update 3 with Dot Net Core Tools Preview 2.

[zoehart]

I've gone ahead and created a NuGet package for my .NET Framework 4.6 assembly and have successfully (I think) installed it in my project. My project.json now looks like this:
{ "dependencies": { "NETStandard.Library": "1.6.0", "mycompany.myassembly.pkg": "4.6.0" }, "frameworks": { "netstandard1.6": { "imports": "dnxcore50" } }, "version": "1.0.0-*" }
VS2015 puts a squiggly red line under the "4.6.0" version of my package and complains that "The dependency mycompany.myassembly.pkg 4.6.0 does not support framework .NETStandard, Version=1.6." And I am not able to reference any namespace or class within my packaged assembly. Has anyone else gotten this far, seen this problem, and found a way around/past it?

[omuleanu]

I also created a local nuget package source on c:mypackages for referencing my own .net core dlls

[StuartSmith]

I ran into this problem as well. see the following link

https://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx

Basically you have to make the portable library target .net 4.6 if not the references do not work and compile time problems abound.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.