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)
Can you provide any details of the 3rd party DLL?
Yes Stripe.dll and SimplePsd.dll both are not available on nuget
@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).
@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.
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...)
@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?
@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?
@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.
@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 ;-)
it is likely that the conversion back to msbuild will fix this issue
I am having the same problem. Is there any workaround for this ?
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???
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?
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?
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).
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...
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.
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.
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.
@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?
Referencing stuff is all in CLI now (It's true that ASP.NET had that before we moved from DNX to dotnet.)
@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).
@MV10 Sorry, don't have time. There's enough people reporting the problem (including yourself), so I do believe that there's an issue. :)
@MV10 please see the pattern for wrapping loose dll's here:
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.
Major blocking issue!!
so what is the latest solution ? do we just create nuget packages and add them to a local source ?
I would like to know if there is a fix for this yet
There isn't and the only thing I managed to do was to setup a .net framework 451 dependency.
I actually need to reference .net core (.net standard 1.6) dlls, and I had to create .net package for this
@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.
Any updates on this?
This is a huge blocker! Any updates on this yet?
it works fine in vs2017 using csproj. it will not be implemented for vs2015 and project.json.