.net core projects only support referencing .net framework assemblies in this release #1672

Open
dotnetdeveloper786 opened this Issue Jul 15, 2016 · 34 comments

Projects

None yet
@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)

untitled23

@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
MV10 commented Jul 16, 2016

@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
MV10 commented Jul 16, 2016

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
MV10 commented Jul 17, 2016

@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
avoxm commented Jul 23, 2016

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

@MV10
MV10 commented Jul 23, 2016 edited

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
harald commented Jul 25, 2016

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
MV10 commented Jul 26, 2016 edited

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
AArnott commented Jul 26, 2016

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
Tenmak commented Jul 28, 2016

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
harald commented Jul 28, 2016

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
AArnott commented Jul 28, 2016

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
Member
muratg commented Aug 2, 2016

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
MV10 commented Aug 2, 2016

@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
Member
muratg commented Aug 2, 2016

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

@MV10
MV10 commented Aug 3, 2016 edited

@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
Member
muratg commented Aug 3, 2016

@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
Member
muratg commented Aug 3, 2016
@piotrpMSFT

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

@lilpug lilpug referenced this issue in aspnet/Tooling Aug 16, 2016
Open

referencing third party dll's #731

@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
Tenmak commented Sep 21, 2016

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
Member
muratg commented Sep 22, 2016

@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
gulbanana commented Jan 5, 2017 edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment