Can't Add .Net 4.6 DLL to ASP.NET Core (.NET Framework) MVC Project

[MelbourneDeveloper]

I do this (Visual Studio 2015 Update 3):

• Create a new ASP.NET Core Web Application (.NET Framework)
  

• Select Web API -> OK
  

• Right click References -> Add Reference
  

• Browse to a DLL compiled with .Net Framework 4.6 
  

This is the error I get:
https://dl.dropboxusercontent.com/u/79781769/Images/Forums/Add%20Reference%20Error.png

[davidfowl]

The reference to the image isn't valid.

[MelbourneDeveloper]

Try again. It is definitely valid:
https://dl.dropboxusercontent.com/u/79781769/Images/Forums/Add%20Reference%20Error.png

[davidfowl]

Yep, direct dlls references aren't supported at the moment. Only thing you can do is wrap it in a nuget package (which kinda sucks) but it's going to be fixed with the move to msbuild.

[MelbourneDeveloper]

OK. Well that's very difficult then.

The reason I'm posting this is because I was referencing a .Net 4.6 project from within the solution, but for some bizarre reason, the MVC app I'm working on, won't pick up the reference. I have documented my frustration here:
https://forums.asp.net/t/2100387.aspx?Debugging+Problem

[MelbourneDeveloper]

Which .NET DLL version is ASP.NET expecting?

[MelbourneDeveloper]

This is the real problem I am having. I have a project in my solution called Adapt.Data.Generic. I found that the MVC app was not referencing the latest version of this DLL. I found that it was picking it up from another project (Adapt.Presentation.AES). So I removed the Adapt.Presentation.AES project from my solution. And yet, the MVC project is still looking for Adapt.Data.Generic in the Adapt.Presentation.AES project. This is the compilation error I get:

https://dl.dropboxusercontent.com/u/79781769/Images/Forums/Compilation%20Error.png

[MelbourneDeveloper]

"Only thing you can do is wrap it in a nuget package"

I'm happy to wrap it in a NuGet package, but do I have to publish that package? Or, is there a way I can reference a NuGet package in Visual Studio directly?

[MelbourneDeveloper]

I figured out how to wrap the problematic DLL in a NuGet package and publish that package on my machine locally. However, now my solution still doesn't compile because all the other DLLs in my solution are not referencing that NuGet package. Does this mean I have to create a NuGet package for each of my referenced DLLs? This is madness!

[MelbourneDeveloper]

Actually, I don't think I was write in my last comment. I have removed all references to the DLL in my MVC project file, and the project.json. I then added a reference to the DLL using the NuGet package manager (package on my local machine). I still get this error:

Could not find a part of the path 'C:\AdaptSource\AES\Adapt.Presentation.AES\Bin\Adapt.Data.Generic.dll'.

What?

Why is it even looking in Adapt.Presentation.AES? Where did it get the idea to look there? I've added the reference through NuGet. The Adapt.Presentation.AES project isn't even in this solution.

[MelbourneDeveloper]

OK. I've managed to successfully work around the problem. I bundled all my reference DLLs in to a NuGet package on my local hard drive and then referenced that.

This is a really poor solution because it's going to mean any time I change code in the referenced DLLs, I'm going to have to rebuild the NuGet package.

Is this going to be fixed soon?

[MelbourneDeveloper]

BTW: I wasted a hole day today trying to figure out why this doesn't work. The Visual Studio team should remove the ability to add references by DLL, or by project altogether until this problem is fixed.

[sliekens]

@MelbourneDeveloper I made something that might ease your pain: an MSBuild tool that automates nuget package creation in .NET 4.6 (csproj style) projects

https://github.com/StevenLiekens/BuildPackage
https://www.nuget.org/packages/BuildPackage/

[MelbourneDeveloper]

Awesome. I'll have a look. Actually, I found that .net core console apps have the same problem as this yesterday. So it's not ASP specific. Which forum/website can I talk to about this?

Actually, it's harder to resolve because the NuGet packager doesn't seem to support. .Net Core. It has standard but not the right version.

[MelbourneDeveloper]

Should I take it that Microsoft is now pushing toward a direct DLL reference free world? I know that managing references can be hard, but honestly, I've had far more trouble with NuGet than I did managing references manually. The concept is sound, but there are a lot of problems to iron out.

[mlorbetske]

With the move to csproj based projects in Visual Studio 2017, this experience has become much smoother, for the project.json based projects, it looks like you've found the best solution available - automatically creating the NuGet packages. If you're still running in to problems with this, please report an issue on the developer community site