Tooling: Add Reference to .NET 4.5.1 class library project from ASP.NET 5 web app not working

[johnciliberti]

I am running the RC of Visual Studio Enterprise on a Windows Server 2012 R2 Virtual Machine. Folder that solution is added to is part of a git repo.
Steps to reproduce:

1. Create new Web Application Project with ASP.NET 5 Starter Web Template
2. Add an existing .NET 4.5.1 class library project to the solution. Project includes a reference to EF 6.1.3
3. Add the class library project as a reference in the web application project.

Results:

1. A reference is added to the project.json file in the web project
   "frameworks": {
   "dnx451": {
   "dependencies": {
   "Recipe05.Dal": "1.0.0-*"
   }
   }
2. In the class library project a wrap directory is created with the folders:
3. EntityFramework
   
   
   
   • EntityFramework.SqlServer
   
   
   • Recipe05.Dal
     
     each folder has it's own project.json file with a bin configuration
     
     "bin": {
     
     "assembly": "../../obj/{configuration}/Recipe05.Dal.dll",
     
     "pdb": "../../obj/{configuration}/Recipe05.Dal.pdb"
     
     }
   
   
   • In the web project package restore fails with the following error:
     
     Error NuGet Package Restore failed for one or more packages. See details in the Output window.
     
     Restoring packages for C:\MVC6Recipes\MVC6Recipes\Chapter06\Recipe05\src\Recipe05.Dal\wrap\Recipe05.Dal\project.json
     
     GET https://www.nuget.org/api/v2/FindPackagesById()?Id='Recipe05.Dal'.
     
     OK https://www.nuget.org/api/v2/FindPackagesById()?Id='Recipe05.Dal' 1081ms
     
     Unable to locate Recipe05.Dal >= 1.0.0
   
   

[davidfowl]

Can you show your solution layout? From the error, it looks like it can't figure out what kind of reference Recipe05.Dal is. What does the ICON show in visual studio? Is it yellow?

[johnciliberti]

Yes. I get the yellow warning icon when I drill into references.

One thing that seems off is that in the wrap directory
"frameworks": {
"net451":

not
"dnx451"

Changing this has no effect however.

[davidfowl]

You missed my first question. what is your solution layout. Do you have more than one global.json in your project structure? It looks like things were adding in the wrong place and the ASP.NET 5 project can't figure out the project references.

[johnciliberti]

There is two global.json files but only one appeared in the solution explorer. The one in the class library project only had:
{
"projects": [
"wrap"
]
}

Interesting, if I create the ASP.NET 5 project first, then create a NEW class library project as part of the ASP.NET solution it seems to work fine.

If I include an existing library created as part of another solution, I run into issues. Does not seem to matter where the location of the referenced class library is.

Seems like in the latter case the wrap command is adding a global.json file to the class library project. This could be because I am adding a reference to a project that was created in another solution. Wrap command sees a solution folder without a global.json so it adds one.

[davidfowl]

1. Add an existing .NET 4.5.1 class library project to the solution. Project includes a reference to EF 6.1.3

That project is where on disk?

On again, can you post the solution layout at each step? I'd like to be able to reproduce this but the steps still look too vague.

[johnciliberti]

I had tried it several ways. Bold indicates a solution folder, italic project folder:

1. Causes issue

Shared Library

MVC6Recipes/Shared/Mvc6Recipes.Shared.DataAccess/_Mvc6Recipes.Shared.DataAccess_

ASP.NET 5 Project

MVC6Recipes/Chapter06/Recipe05/src/_Recipe05.Web_

2. This fails also

Dal solution was created first. Closed solution. Created new Web Solution. In this case, two solution files in same directory.
MVC6Recipes/Chapter06/Recipe05/_Recipe05.Dal_

ASP.NET 5 Project

MVC6Recipes/Chapter06/Recipe05/src/_Recipe05.Web_

3. This works Fine

In this case I had created the web app first then created the library. Library does not have it's own solution

Shared Library

MVC6Recipes/Chapter06/Recipe05/Recipe05.Dal/

ASP.NET 5 Project

MVC6Recipes/Chapter06/Recipe05/src/_Recipe05.Web_

[johnciliberti]

Here is another way to make it fail. :-)

1. Start with an empty solution
2. Add Class Library project
3. Create ASP.NET Project and select ASP.NET 5 template
4. Build Solution
5. Add reference to class library in web project

In this case, since you started with an empty solution, you do not get a global.json file at all.

The work around is to remove the reference, manually delete the generated wrap directory in class library project folder and then manually create a global.json file. After that, you can add the reference and it will get you past the issue of not being able to find the package.

Even after this fix, there are other issues such as what lucamorelli mentioned in issue #8 where you get Entityframework 7 beta 4 rather then EntitityFramework 6.x. Seems like the only way to make it work is to manually add

"bin": {
        "assembly": "../../../packages/EntityFramework.6.1.3/lib/net45/EntityFramework.SqlServer.dll"
      }

To the web project's project.json file.

I think maybe you should rethink how the wrap command works for Visual Studio. Maybe you can add an option to the command line interface that would tell wrap to modify a specified project.json file rather then creating the wrap directory as it does today.

[davidfowl]

In #8 he Luca was referencing EF7 and EF6

[AlexeiScherbakov]

I have this situation.
Project C depends on Project B, which depends on Project C
All them needed to be referenced in ASP.NET 5 project.

1. I call 'dnu wrap' on Project C - it references normally [ "Project C Wrapped" ]
2. I call 'dnu wrap' on Project B - it have trouble with reference to Project C. [ "Project B Wrapped" ]
   So I cannot reference entire chain even if I disable 'dnxcore50' compilation

[BjBlazkowicz]

I can't get this to work even how hard I try.

Issue is reproduced by the following steps:

1. Create Empty ASP.NET 5 Application
2. Create new .csproj class library in the same solution
3. Reference the class library from the ASP.NET 5 app and it does not work:
   Dependency ClassLibrary2 >= 1.0.0-* Could not be resolved

Tree:
├───artifacts
│ └───obj
│ └───WebApplication3
│ └───Debug
│ └───ProjectRawReferences
│ ├───DNX 4.5.1
│ └───DNX Core 5.0
├───ClassLibrary2
│ ├───bin
│ │ └───Debug
│ ├───obj
│ │ └───Debug
│ │ └───TempPE
│ └───Properties
├───src
│ └───WebApplication3
│ ├───Properties
│ └───wwwroot
└───wrap
└───ClassLibrary2

[jcmordan]

I resolved this,
The ASP.NET 5 web app project must have in < 4.5.2, not 4.6.

[sayedihashimi]

This issue is pretty old. We have worked on improving the Add Reference support. We still have some issues related to wrap but I think the basic scenarios should work.

I'm going to close this, but if you are still having issues you can either re-open this or open a new issue with steps to reproduce.

[runxc1]

So how is this supposed to work? I am running into some of the same problems here. I have an existing Solution with projects A, B,C,D in it and I created a new Asp.Net 5 Solution with 4 new projects and everything working fine.

I added the 4 existing projects to the Solution and saw that a project.json file was added for each of them in a /wrap folder. I then tried to reference to projects A-> D to one of the Asp.Net projects and am now getting an error.

How do I work around this error?

[nigel-dewar]

I tried this and many other things. Nothing works. Why is it so hard to add a class library and reference it from the asp.net 5 project?

[nigel-dewar]

Even if you can reference it, it breaks within a short time. For instance I checked that I could reference a class called Class1.cs from the class library in the asp.net 5 project.

But then after a short while, it is like the link breaks, And the only file you can now reference in the asp.net 5 library is that Class1.cs class. No other class you add is can be referencing.

Really weird and frustrating.

[pettys]

Experiencing a similar issue - got a pretty small asp.net 5 app, pull some of my older Class Library .csproj files into the solution, try to Add Reference > Projects... so I can use those assemblies, and am getting error project.json(35,43,35,43): DNX 4.5.1 error NU1001: The dependency MyClassLib >= 1.0.0-* could not be resolved.

Pretty much everything I google for to try to learn more (like trying to figure out how the "wrap" stuff is supposed to be set up) shows this thread as a top link. :)

[runxc1]

We probably need to test this and open a new ticket if it doesn't work inside the dotnetcli repo as dnx is dead and this may not even work the same in RC2.

[sebastianbk]

I can confirm the issue @nigel-dewar and @pettys have experienced. I experience this issue too in a brand new solution.

[jmblakl]

Experiencing the same issue. I building a test Service Fabric App with a stateful service backend and an ASP.NET 5 web front end. I added a proj reference from the Web project to a common interfaces project I was building which defined the contract to the back end services.

The solution was created for the service fabric and then web project was added to that dir structure. Initially the project seems to work, but when I make changes to the interface in the contracts project the new contracts do not become available to the web project. Interestingly enough, it appears at design time to work; there are no syntax errors or indication that the method doesn't exist. At build time, however the output clearly show that it can't find the method and the build fails.

Directory structure:
C:/ServiceFabApp
|__ServiceFabAppProj/
|__DataServiceProj/
|__WebProj/
|__wrap/
|__global.json
|__packages
|__ServiceFabApp.sln

[RMHR]

Similar issue, trying to add a Nuget package written in a 4.6 class library, adding it as a reference adds it to the project json but says it can't resolve it. I understand ASP.NET 5 is the new and shiny but seriously this is the first thing people will be doing to port their projects - add references to their existing ones.

[kkleeberger]

Same Problem, I can't add my own .NET 4.5.1 DLL as a reference to my ASP.NET 5 Project.
CLR Type: .NET Framework

It works if I make the following changes:

if DNX4.5.1

....

endif

Exists for that a gobal Setting or can i remove the DNX Core Features ???

[javivalero]

I think that this issue is related with https://github.com/aspnet/Tooling/issues/245

[navinv789]

Same Problem not able to add my class library as reference.
Not even getting the proper error why it is not allowing to add

[jemiller0]

I noticed it's setting the following in project.json even though I had .NET Framework 4.6.1 selected when I created the ASP.NET 5 Web project.

"frameworks": {
"dnx451": { },
"dnxcore50": { }
},

I changed it to "dnx461". I was able to add the reference. However, the project won't build. It says a dependency to the library that I added couldn't be resolved. Honestly, I have no idea what is going on with ASP.NET anymore. Why is MVC 5 not the default in Visual Studio 2015? I had to install a separate download to get the templates for it. Defaulting to beta software is not a good idea. I know you guys want to push everyone into using the latest and greatest code, but, this is ridiculous. I think you should just outright call it something else and not ASP.NET. Everything is different now. It used to be the case that one could work productively in ASP.NET. It is clear that that is all changing now. You may as well use Ruby On Rails now. It has to be better than this garbage. Adding a library should be a no brainer. Yet Microsoft has convinced itself that it needs to make everything cross platform. Now there are 10 different types of libraries. This is Silverlight all over again. I don't even think Microsoft cares about it's existing developer base. All they care about is parrotting all the other open source projects. Sorry for the rant, but, I don't see how this is an improvement. It doesn't help when it comes to getting real work done as opposed to constantly shuffling the deck chairs on the Titanic. This is exactly why I always liked .NET over Java. It was a productive environment. Now we are entering the days of Maven hell on .NET.

[jemiller0]

Besides that, according to https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-ending-for-the-net-framework-4-4-5-and-4-5-1/. Support for .NET 4.5.1 is ending (already has). I have no idea why it is defaulting to that. Probably Microsoft isn't evening bothering to test on the full .NET Framework.

[runxc1]

Yeah this is pretty much a dead thread as so much of this changes with RC2 as it will no longer be using DNX at all and will be running on the .Net CLI

[sayedihashimi]

We are redoing p2p references to standard c# projects. We will no longer be using wrap, we will replace it with something else.

[ghost]

@sayedihashimi when do you think it will be released?

[danjarvis]

:+1:

[kwaazaar]

Is there at least any documentation on how to reuse existing code or assemblies? I cannot really find any.

Dotnet core documentation is getting a pretty mess anyway, as it keeps changing, but even official documentation is not updated in time. :-1:

[nigel-dewar]

asp.net 5 is brilliant, but I am using it for what it is good for at this stage ( front end projects ). We continue to build our APIs in .net 4.5 .

I think its a case of experimentation seeing what works and what doesn't until the day you can leave .net 4.5 behind. At this stage, I can't do this.

[coderabsolute]

Am facing this issue, not sure what the fix is really? Am starting a project and I really got a deadline to meet. If this is not working, can someone please propose an alternative until this is fixed?

[ghost]

@coderabsolute you can reference compiled dll's of your class libraries projects. This worked for me.

[kneerunjun]

@jemiller0 - agree , take my upvote ! - It is all Silverlight all over again! Trying to get around this issue is like a dog chasing his own tail. MongoCore C# driver needs net451 and boom , aspnet core is just adamant. Frustrating , I have spent a day trying out things - no light at the end of the tunnel.

[coderabsolute]

I think, I have solved this issue. I have created a brand new solution and started to add projects and all seems to work. yay! Am a happy man again!

[kneerunjun]

@coderabsolute : please post the project.json here

[rhwilburn]

I am having the same issue here. I am surprised for my project library added reference, that it is searching for it on Nuget but failing. This doesn't make the slightest bit of sense. My log shows:

Restoring packages for E:\Dev\RouteMe\1.2 webTier\RouteMeWeb\project.json
  GET https://www.nuget.org/api/v2/FindPackagesById()?id='Mobile.Common'
  OK https://www.nuget.org/api/v2/FindPackagesById()?id='Mobile.Common' 1458ms
  CACHE https://www.nuget.org/api/v2/FindPackagesById()?id='System.Net.Sockets'
Unable to locate Dependency Mobile.Common >= 1.0.0-*

Mobile.Common is a PCL that is in the sln. It allows me to add it from my project. It then hangs for about 30 seconds (visual studio that is) and then mentions it failed to restore nuget references.

My project.json file has:

  "frameworks": {
    "dnx451": {
      "dependencies": {
        "Mobile.Common": "1.0.0-*"
      }
    },
    "dnxcore50": {
      "dependencies": {
        "Mobile.Common": "1.0.0-*"
      }
    }
  },

Im using RC1 and have to say this wasn't the first issue I noticed. I also noticed that there was one dll missing from the default MVC project to get that to work.

[leontyr]

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

[takazm]

Related to this; Can i have it the other way round. I have a web api 2.2 project targeting .net 4.6.1 and a class library on same framework but created using the dnx project type. I checked the "produce output on build" and the package from the class library is there. I referenced this in my web api 2.2 project but seems not to work. I added the artifacts path to the solution package sources. Here the error i get :* Error Unable to resolve dependency 'EntityFramework.Commands'. Source(s) used: 'nuget.org', 'myget', 'Local Entities', 'Microsoft and .NET'.
*

[leontyr]

Don't think you can do that. The class library (package) doesn't have dll right?

[ghost]

Takazm, add this reference on ef in webApi project and it may work

[takazm]

@AloeDream that doesnt work. install-package : Package 'EntityFramework,7.0.0' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json'. Please verify all your online package sources
are available (OR) package id, version are specified correctly

[takazm]

@AloeDream Actually, i managed to install EF but still cant reference the package from my class library output

[zemien]

From my experience you would want to test this on your build server/CI
server as well. I had this issue, fixed it on my machine by manually
tweaking json files, committed it to source control, and it failed to build
on the server. It works if I manually tweak the json on the build server as
well, but that defeats the purpose of automated builds. I have since moved
back to .Net 4.5.2 for my project while MS figures out a more reliable
method for Core to talk to the full framework.

On Wed, 4 May 2016 at 04:41 Takaz [email protected] wrote:

@AloeDream https://github.com/AloeDream Actually, i managed to install
EF but still cant reference the package from my class library output

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/aspnet/Tooling/issues/45#issuecomment-216589265

[murpheux]

Did anyone figure out the fix to this? I am having same issues and it's been about a year since this conversation started.

[jemiller0]

Yeah, wait until RC2. There is something on the .NET Blog about how they’re getting rid of the stupid JSON config file and going back to XML.

Jon

From: Clement Onawole [mailto:[email protected]]
Sent: Sunday, May 15, 2016 8:50 AM
To: aspnet/Tooling [email protected]
Cc: Jon Miller [email protected]; Mention [email protected]
Subject: Re: [aspnet/Tooling] Add Reference to .NET 4.5.1 class library project from ASP.NET 5 web app not working (#45)

Did anyone figure out the fix to this? I am having same issues and it's been about a year since this conversation started.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/aspnet/Tooling/issues/45#issuecomment-219286919

[kwaazaar]

Nope, project.json will remain for now. After RTM (end of june) it will very likely be replaced by the existing csproj, which will probably need changes as well.

[ghost]

Please, leave that json alone! It works and it's readable and more understandable and already supported by tooling!
What's really need to be changed - "wrap" and references system!

[guardrex]

@AloeDream Sorry ... they made the design decision, so it will be happening after RTM. We'll just have to get used to it (unfortunately).

[WolfspiritM]

Now that RC2 is out I can't figure out a way to Reference a Dotnet 4.5.1 Class Library via DLL.
According to the project.json Documentation you can use the bin syntax to reference DLLs but it seems like this is not working with the dotnet-cli.

Is having a 4.5.1 API Library which needs to be referenced by ASP.NET really that uncommon that this whole thing got removed (or at least no replacement got added on the move to dotnet-cli)?

Referencing the Assembly in Visual Studio (which did wrap the DLL in RC1) completly fails saying that only Dotnet Framework Assemblies can be referenced in this release and others need to be nuget packages.

As a workaround it seems to work to set the Asp.NET Core project.json to net451 and add the other project (The Library) to the solution and Reference that Project from within Visual Studio via the Add Reference -> Solution window.
That creates a:

  "frameworks": {
    "net451": {
      "dependencies": {
        "TestLibrary": {
          "target": "project"
        }
      }
    }
  },

This might be used to create a "wrapping" Project but this can't be the final solution to this problem.
There needs to be a way to reference existing Assemblies as there was for RC1!

[codemasta]

Any solution to this yet. Facing same problem here. Really really frustrating.

[ShikiGami]

Same problem here, using a wrapping I can get it to compile, but then it fails at runtime.

[ghost]

It can be closed, as adding refs on .net class libs projects is now working.
I've migrated my RC1 project to RC2, removed refs to dll files, added refs for projects and it's working!

[WolfspiritM]

@AloeDream I think this issue should actually be reopened (as it's closed at the moment) cause the main issue of using compiled DLLs is still a problem. There are cases where you don't have the project for the Libs available (thirdparty libs for example). And creating a wrapper project only cause of that isn't a good idea in general.

[davidfowl]

Project references work but dll references are currently broken.

/cc @piotrpMSFT @abpiskunov

[davidfowl]

@WolfspiritM can you wrap those DLLs in a nuget package?

[jemiller0]

It makes you wonder how Microsoft thought any of this was release candidate quality, if now, after all these months doing something as simple as adding a library to a project doesn’t work. Entity Framework appears to be nowhere near ready either. I think they must be setting unrealistic deadlines for when they expect this to be done. Honestly, they should rename it to alpha.

Jon

From: David Fowler [mailto:[email protected]]
Sent: Thursday, May 19, 2016 2:59 AM
To: aspnet/Tooling [email protected]
Cc: Jon Miller [email protected]; Mention [email protected]
Subject: Re: [aspnet/Tooling] Add Reference to .NET 4.5.1 class library project from ASP.NET 5 web app not working (#45)

@WolfspiritMhttps://github.com/WolfspiritM can you wrap those DLLs in a nuget package?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/aspnet/Tooling/issues/45#issuecomment-220253949

[WolfspiritM]

@davidfowl Thanks! I hadn't done much with creating own nuget packages before but that actually works and I have to say it's way clearer!

For everyone else having that issue and also hadn't worked with nuget packages (creating them) before:

1. I downloaded nuget from here: https://docs.nuget.org/consume/installing-nuget (VS has a version, too, but I used this one)
2. Add nuget to your path variable
3. Create an empty Folder (for example "TestPacket") and put the needed DLLs into a directory structure like that (replace net452 with the dotnet version of the DLLs (e.g. 451, 452, 46)):
   TestPacket/lib/net452/TestLibrary1.dll
   TestPacket/lib/net452/TestLibrary2.dll
4. Open command prompt in TestPacket
5. Type "nuget spec TestPacket". This creates a TestPacket.nuspec
6. Open that file in a texteditor (or visual studio) and Edit the lines accordingly.
7. In the CMD Promp type: "nuget pack". This bundles all the content in that Directory to a File TestPacket.1.0.0.nupkg.

Now to use that file in my ASP.NET RC2 Project:

1. Create a folder beside the "src" folder and the NuGet.Config file of your project and put the nupkg in there. (I called it "nuget")
2. Open the NuGet.Config
3. Add the following line inside the packageSources somewhere under <clear /> (I added it directly under clear):
   <add key="Local" value="nuget" />
   (Replace "nuget" with the foldername created in step 1)
4. Open project.json and remove the "Microsoft.NETCore.App" dependency (including the version and type) and also change the framework to the framework you want to use:

"frameworks": {
    "net452": {}
  },

Finally: Under "dependencies" add (make sure to set the version according to your package):
"TestPacket": "1.0.0"

Here are both changed Files I used:
https://gist.github.com/WolfspiritM/35f6831587af975116bcb44e20977fc4

After that Nuget should load the package from the local folder and your DLLs should be available!
I'm not quiet sure if I missed something or left something in that is not needed for .NET Framework but at least it works standalone and in IIS Express. Especially the "tools" part of the project json has a "imports" declaration which I'm not quiet sure about yet and if it just can be removed.

[guardrex]

@davidfowl Can you comment further on the first part of that ^^ (Steps 1-7)? Can one just dotnet pack a wrapped DLL in a little wrapped DLL package project that you can setup?

[johnciliberti]

@WolfspiritM
I think your solution is the way to go. Just adding a DLL to a project is somewhat of an anti-pattern. If you app is using any automated CI process such as Jenkins or even working with a team of developers, direct references to DLLs are problematic. You also have no way of quickly determining what are the dependencies of that DLL. NuGet packages solve both problems.

If you run into issues sharing the NuGet packages with your team, you may want to look at something like Nexus or Artifactory which allows you to set up an aggrigated NuGet repository that can combine packages from the public NuGet with your private repo.

I think that this problem of adding a DLL is a great opportunity for ad-on developers. Maybe add a menu item to Visual Studio that says "Create NuGet package from Assembly". Ideally this would create the package and add it to your private NuGet repo then add the NuGet package reference to your project. If any of you want to work on this, I can spin up a new project on GitHub.

[senj]

I tried building my own nuget with dotnet pack. It creates a nuget, but referencing this nuget in another project fails to restore. both projects target net46.
I noticed there is no XML in \lib{framework}.. which may be intended now but was there in rc1.
Why it doesn't work automagically as in rc1?

[WolfspiritM]

@johnciliberti I agree completly. It's way cleaner and easier to manage. I hope that it will be made easier to create nuget packages from old and new class librarys with upcoming Releases. Right now VS doesn't seem to support any real way to create nuget packages. Even for Dotnet Core Class Librarys the creation of nuget packages out of VS seems to not work yet ("Produce outputs on build" in Project Properties is missing). For easier integration it would also be nice if VS could just wrap an existing DLL into a nuget package on the fly when you try to reference it.

@senj I assume you have a Dotnet Core Class Library outside of your solution you'd like to reference in your ASP.NET project/solution? I had no problem doing that yesterday with "dotnet pack" which packs the Output Folder of a Dotnet Core Project (it needs project.json) into a nupkg file. I created a "Class Libary (.NET Core)" removed all dependencies and changed frameworks to "net46". Then I ran "dotnet pack" from the command line which created a nupkg inside my Output Folder. I've but that nupkg inside my local package repository (the folder I created in the second part (1-4) of my post above) and added the name of my Library as dependency to a another dotnet core project and it restored without issues.

[johnciliberti]

@WolfspiritM
I think the questions that the Visual Studio team is probably asking are;

• Is adding a standalone DLL an edge case or a mainstream practice?
• If it is a mainstream practice should we be condoning it by making it easier?

For the first question I think the answer is yes. Many people are still adding DLL references directly. Before NuGet this was the most common way to add a 3rd party reference. Many people have not learned the new pattern and many vendors or older products have not created NuGet packages.

For the second question, I think it has two parts.
No they should not be condoning this practice since it is an anti-pattern.
On the other hand, they do need some Visual Studio GUI that simplifies package creation. Maybe right click on a project and select "Publish as NuGet". Maybe an option under the Build menu. Ideally all of your libraries should be kept in a private NuGet Repo available to your build servers.

For 3rd party DLLs that do not have NuGet packages, I think this is an edge case that the community can take care of. The problem is a bit more complex then wrapping a DLL. Remember not all DLLs are stand alone .NET assemblies. DLLs can also be COM objects, ActiveX Controls and even drivers. You need to scan for dependencies and determine if a package is even an option. For example, does the DLL depend on things deployed to GAC? Does it use PInvoke? Does it assume you are running a particular flavor of Windows?

[jemiller0]

Requiring everything to be in a NuGet package seems overly complicated and like a terrible idea to me. Who says adding a standalone DLL is a an anti-pattern? Not everyone has or wants to setup a build server, private NuGet repository, etc. etc. Sounds like massive overkill for something that should be a no brainer. I absolutely hate what has happened with Java and Maven and it looks like .NET is heading in the same direction.

Jon

From: John Ciliberti [mailto:[email protected]]
Sent: Saturday, May 21, 2016 8:54 AM
To: aspnet/Tooling [email protected]
Cc: Jon Miller [email protected]; Mention [email protected]
Subject: Re: [aspnet/Tooling] Add Reference to .NET 4.5.1 class library project from ASP.NET 5 web app not working (#45)

@WolfspiritMhttps://github.com/WolfspiritM
I think the questions that the Visual Studio team is probably asking are;

• Is adding a standalone DLL an edge case or a mainstream practice?
• If it is a mainstream practice should we be condoning it by making it easier?

For the first question I think the answer is yes. Many people are still adding DLL references directly. Before NuGet this was the most common way to add a 3rd party reference. Many people have not learned the new pattern and many vendors or older products have not created NuGet packages.

For the second question, I think it has too parts.
No they should not be condoning this practice since it is an anti-pattern.
On the other hand, they do need some Visual Studio GUI that simplifies package creation. Maybe right click on a project and select "Publish as NuGet". Maybe an option under the Build menu. Ideally all of your libraries should be kept in a private NuGet Repo available to your build servers.

For 3rd party DLLs that do not have NuGet packages, I think this is an edge case that the community can take care of. The problem is a bit more complex then wrapping a DLL. Remember not all DLLs are stand alone .NET assemblies. DLLs can also be COM objects, ActiveX Controls and even drivers. You need to scan for dependencies and determine if a package is even an option. For example, does the DLL depend on things deployed to GAC? Does it use PInvoke? Does it assume you are running a particular flavor of Windows?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/aspnet/Tooling/issues/45#issuecomment-220779022

[davidfowl]

Requiring everything to be in a NuGet package seems overly complicated and like a terrible idea to me. Who says adding a standalone DLL is a an anti-pattern? Not everyone has or wants to setup a build server, private NuGet repository, etc. etc. Sounds like massive overkill for something that should be a no brainer. I absolutely hate what has happened with Java and Maven and it looks like .NET is heading in the same direction.

It's not an anti pattern, we're going to be adding support for adding assembly references, the current workaround is to use a nuget package and it's not ideal.

[johnciliberti]

@jemiller0
Thinking about it more, you are right. At a platform level you need the ability to directly add DLLs. In the Java world they allow you to reference a JAR file. No one forces you to use Maven or Gradle.
On the other hand the utility of leveraging package managers goes way beyond the CI use case. Even if you are a lone wolf dev and you are moving to a new machine, you will find many broken references the first time you run your project. For that and other reasons I still hold that it is a poor practice.

Also if you plan on deploying ASP.NET Core apps in the Enterprise a private package repository will be a really good idea. It will help not only for NuGet but also for NPM and Bower.

@davidfowl
Are there plans on a first party NuGet packaging / deployment utility as part of Visual Studio? I see a few in the Visual Studio marketplace.
https://visualstudiogallery.msdn.microsoft.com/455301f5-cc32-4261-b4da-998bd9a6a690?SRC=VSIDE
https://visualstudiogallery.msdn.microsoft.com/d9a0cb72-99f5-4186-9149-0a9b8ab82356?SRC=VSIDE

[amcdnl]

When will DLL references be added back?

This is quite ridiculous! ^^^^

[abpiskunov]

Did you read comments 2 lines above your post?

[amcdnl]

@abpiskunov WHEN is what i asked.

[sayedihashimi]

@amcdnl we are working through plans. We don't have a specific timeline for this feature yet. We may know more in a few weeks.

[amcdnl]

@sayedihashimi Thanks for the feedback! I think FEATURE is a stretch, more like a regression.

[johnciliberti]

@sayedihashimi
Do you know if DLL references is a current gap in the tooling or is it missing from the ASP.NET Core Framework? If it is only a tooling gap can someone explain how this can be done manually without first creating a NuGet package.

[abpiskunov]

It is gap in runtime and thus tooling also does not support it.

On May 23, 2016, at 8:55 PM, John Ciliberti <[email protected][e-mail]> wrote:

@sayedihashimihttps://github.com/sayedihashimi
Do you know if DLL references is a current gap in the tooling or is it missing from the ASP.NEThttp://asp.net Core Framework? If it is only a tooling gap can someone explain how this can be done manually without first creating a NuGet package.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/aspnet/Tooling/issues/45#issuecomment-221138241

[davidfowl]

It is gap in runtime and thus tooling also does not support it.

It's not a gap in the runtime. It's a gap in the tooling. If you drop dlls into the output folder it'll load like normal. As a temporary workaround it might be possible to do something like this https://github.com/dotnet/cli/tree/rel/1.0.0/TestAssets/TestProjects/TestAppWithWrapperProjectDependency

[dmikov]

@sayedihashimi I apologize in advance for nerd rage that follows. But seriously? It worked in RC1 and now the application that we wrote is broken because of this change and you are talking about the feature and future plans, instead of jumping on it and fixing the BUG. We were promised production ready when we started with RC1. Now I am looking like an idiot because third party libraries that we used don't have NuGet packages for that versions. At least you can treat the developers with some honesty and respect.
@davidfowl I will try the workaround. Thank you for taking this issue seriously and trying to help us.

[dmikov]

@davidfowl Well, wrapping didn't work. So the only way is to roll back RC2 to RC1

[leak]

I got my RC1 project successfully converted to RC2 and it compiles on console, but Visual Studio is currently pretty much unusable. Is it true that not only the "Add reference" feature is missing but also Build and Intellisense for referenced assemblies is not working at all?

[WolfspiritM]

@leak When adding the references via nuget package, I have no problem to get Intellisense working for the references assemblies. Have you tried to add the DLLs as I described above?

[leak]

@WolfspiritM Your workaround works perfectly - thanks.

Still I believe this issue should be way up on the priority list. The assumption that everything is a NuGet package these days is just illusionary...

[rclabo]

@WolfspiritM On May 17th you said that: ...it seems to work to set the Asp.NET Core project.json to net451 and add the other project (The Library) to the solution and Reference that Project from within Visual Studio via the Add Reference -> Solution window.
That creates a:

  "frameworks": {
    "net451": {
      "dependencies": {
        "TestLibrary": {
          "target": "project"
        }
      }
    }
  },

My Question
Your comments make me hopeful that in Visual Studio 2015 Update 2, using ASP.NET Core RC2, I can add a reference from an ASP.Net Core MVC Application Project to a Windows Class Library Project which uses Framework 4.51. When I try doing this it creates the project.json entry you mentioned, but in my case, intellisense put red squigly under the project name in the entry and shows an error message "The dependency ExampleLib could not be resolved."

Any ideas how to resolve this?

Any help you can provide would be greatly appreciated. Also I have a somewhat related StackOver flow question here: http://stackoverflow.com/questions/37398128/reference-a-full-framework-library-project-from-asp-net-core-mvc-web-application/37398784

[abpiskunov]

What restore output contained after you added ExampleLib project reference?

[rclabo]

It all looks good except the reference to the Windows Library Project.
Restore output:

[abpiskunov]

Restore output from Output pane, not from solution Explorer. Also could you please check what is output assembly name for your ExampleLib project? Is it also ExampleLib or is different from project name?

[rclabo]

I checked and the assembly name for the ExampleLib project is ExampleLib

Here is the restore output from the output pane. Interestingly ExampleLib never shows up in the output.

PATH=.node_modules.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
C:\Program Filesdotnetdotnet.exe restore "C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication.vs\restore.dg"
log : Restoring packages for C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.AspNetCore.Razor.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
info : GET https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHostResolver'
info : OK https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHostResolver' 916ms
info : GET https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHost'
info : OK https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHost' 73ms
log : Restoring packages for tool 'Microsoft.AspNetCore.Server.IISIntegration.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.EntityFrameworkCore.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.Extensions.SecretManager.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.VisualStudio.Web.CodeGeneration.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
info : Committing restore...
log : Writing lock file to disk. Path: C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.lock.json
log : C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\ExampleWebApplication.xproj
log : Restore completed in 6955ms.
NuGet Config files used:
C:\Users\Ron Clabo\AppData\Roaming\NuGet\NuGet.Config
C:\ProgramData\nuget\Config\Microsoft.VisualStudio.Offline.config
Feeds used:
https://www.nuget.org/api/v2/
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
PATH=.node_modules.bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Web\External\git
C:\Program Filesdotnetdotnet.exe restore "C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication.vs\restore.dg"
log : Restoring packages for C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.AspNetCore.Razor.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
info : GET https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHostResolver'
info : OK https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHostResolver' 1162ms
info : GET https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHost'
info : OK https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.NETCore.DotNetHost' 80ms
log : Restoring packages for tool 'Microsoft.AspNetCore.Server.IISIntegration.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.EntityFrameworkCore.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.Extensions.SecretManager.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
log : Restoring packages for tool 'Microsoft.VisualStudio.Web.CodeGeneration.Tools' in C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.json...
info : Committing restore...
log : Writing lock file to disk. Path: C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\project.lock.json
log : C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication\src\ExampleWebApplication\ExampleWebApplication.xproj
log : Restore completed in 4371ms.
NuGet Config files used:
C:\Users\Ron Clabo\AppData\Roaming\NuGet\NuGet.Config
C:\ProgramData\nuget\Config\Microsoft.VisualStudio.Offline.config
Feeds used:
https://www.nuget.org/api/v2/
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

[abpiskunov]

Could you please past contents of "C:\Users\Ron Clabo\Documents\Visual Studio 2015\Projects\ExampleWebApplication.vs\restore.dg" ?

Also after you close and reopen solution , does this error persist?

[abpiskunov]

Also try to Save All and restore manually again

[rclabo]

THANK YOU! The error went away! It works! The solution seems to be doing a manual restore after setting the reference to the windows library project. AWESOME! I can still send you my restore.dg file if it'd be helpful though.

[abpiskunov]

Hold on :), did you click Save All before manual restore? Or just did manual restore? Or did you closed/reopened solution and then did manual restore?

I am trying to understand what happened - auto-restore should still work, but in your case it seems like it did not even see csproj, which might happen if xproj was not saved before auto-restore was triggered.

[rclabo]

I believe I only did the manual restore after the creating the reference and that is what _I think_ fixed it. I didn't close VS and reopen it and I don't think I did any saves either but I'm less certain about that. I have tried this many times over the past few days and the issue is easy to reproduce on my setup. It happens every time with these steps:

1) In Visual Studio, create a new ASP.NET Core Web Application
2) To that solution Add a Windows Class Library Project
3) In the project.json file of the web application remove the following section from dependencies:

"Microsoft.NETCore.App": {
      "version": "1.0.0-rc2-3002702",
      "type": "platform"
   },

4) Change the framework section of the same file to this:

"frameworks": {
    "net451": {
      "dependencies": {
      }
    }
  }

5) Save the project.json file and the auto restore happens.
6) Use visual studio to set a reference from the web project to the Windows Class Library

Now the project.json section looks like:

 "frameworks": {
    "net451": {
      "dependencies": {
        "ExampleLib": {
          "target": "project"
        }
      }
    }

And the error appears.

I can send you whatever you want at any step.

[abpiskunov]

Just tried your steps. After i add csproj reference in step 6. , auto restore happens and everything is resolved. Does auto-restore happen for you in step 6?

Could you please do you repro steps again and see the error. After that zip whole solution with all projects and their lock and *.dg files and share with me?

[rclabo]

I just did the repo steps again and in step 5 when I save the project.json file I was mistaken, the auto restore does not happen, I have to do it manually. I guess this kinda explains why the auto-restore does not occur when I add the reference. I guess the thing that had me stumped is that it never occurred to me to force a Restore Packages manually when I got the error "The dependency ExampleLib could not be resolved" since its a local project in the solution. I'd be happy to zip up the whole solution and send it to you. Where should I send it?

[abpiskunov]

you can send it to my email anton.[email protected].

Now let's figure out why you don't have auto restore. Could you please double check your Nuget settings under Tools\Options\NuGet Package Manager. See if you have two check boxes on top checked: "Allow NuGet to download missing packages" and "Automatically check for missing packages ...".

[rclabo]

Both check boxes were unchecked which may have been something stupid I did long ago when working with RC1 before I understood much about NuGet. I have now checked them. abpiskunov you have been extremely helpful. Thank You!

[jreeter]

Can anyone comment on whether I can reference a compiled .dll in my project.json like so:

"frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50",
      "bin": {
        "assembly": "Moserware.Skills.dll"
      }
    }
  }

I'm running the latest RC2 in OS X. When I try to reference the namespace it pulls the good ole are you missing an assembly reference?

[dmikov]

@jreeter Supposedly and assuming this assembly is at root with the project
the "assembly" value should actually point to assembly location

I personally wasn't able to make it work. But then again I wasn't using "netcoreapp1.0" for framework
In case the original link is gone https://github.com/dotnet/cli/blob/rel/1.0.0/TestAssets/TestProjects/TestAppWithWrapperProjectDependency/TestLibrary/project.json

[PrashanthIBM]

Hi ,

i am trying to update my project.json to use RC2, but i am not able to add the GAC assembly reference for net451 target framework .

Can you please let me know how to add gac assemblies in project.json in RC2 ?

[sayedihashimi]

@PrashanthIBM if you want to use gac assemblies then take a look at the ASP.NET Core Web (.NET Framework) template. Your project.json should look like the one produced from that.

[peterorjeff]

we are working through plans. We don't have a specific timeline for this feature yet. We may know more in a few weeks.

@sayedihashimi or @davidfowl any ETA on when this critical issue will be fixed yet?
This information will help us decide if it's better to wait for the fix or rollback to RC1.

[PrashanthIBM]

@sayedihashimi i looked at it, but it is not able to refer the assemblies from GAC .

[JohnGalt1717]

This is a triple whammy:

1. You can't just a portable library that targets .NET Core 1.0 in the list of portable definitions as a dependency of a ASP NET CORE project. It both wont intellisense and won't build because it doesn't recognize the dll at all.
2. You can't switch it to target any version of .NETStandard 1.x while leaving it as a csproj and have an ASP NET CORE project recognize it properly. (It will intellisense and compile but then the .dll is not found to load types at runtime)
3. If you copy everything into a new .NET Core 1.0 Class library with xproj it also won't work. It even won't work if you target both .NETStandard AND .NET 45. It will work with the ASPNET Core site but it won't be recognized in the .NET project that depends upon the library.

The only way I've been able to get it to work is to point the dependant project to the .dll from the xproj after editing the project.json to include .NET 45 as well and then send the build dependency accordingly. Then it will work as a reference in the ASP NET CORE project AND will work in .NET 4.6 projects.

Please get at least xproj with .NET Standard (without special target for .NET 4.6) loading as dependancies in .NET 4.6 project and compiling without any additional runtimes or anything required. I'm OK with converting to an xproj, but using the .dll isn't kosher for me and shouldn't be required.

[barrytang]

A lot of the issues are now fixed and this is a long thread. Please try with the latest build - https://github.com/aspnet/tooling/#pre-release-builds and open new issues. Thanks!

[tonyqq]

I just installed _Update 3 RC_ and _.NET Core 1.0.0. RC3 - VS 2015 Tooling Preview 2 (Nightly - 6/17)_ and I could not reference dll within Asp.Net Core app.

Really hoping it will be resolved in RTM.

[bklooste]

Same issue with Release Update3 and release core. Tooling preview 2

[jemiller0]

If that's true, that's completely pathetic. How do you have a release version of anything if something as basic as library references don't work. I ran into a separate issue where it appears that EF Core 1.0 RTM appears not to work with the full .NET Framework 4.6.1 and an ASP.NET Web Forms application. At first, I thought the problem was that I was upgrading from a previous version. Then, created a brand new project and reverse engineered the database following the instructions. Still the same problem. A version conflict on the System.Collections.Immutable library. Why even pretend this is RTM. Apparently, quality control went out the window with the switch to making everything run on Linux.

[lilpug]

"even to this day its still not working 12/07/2016"

this does need resolving the idea of RC2 and RTM was to start being able to build production grade software with the new release, we cannot build production grade software when we cannot even reference a library outside of nuget, there are 2 other threads for this issue and many more on forums, stackoverflow etc, if you would look at it, this seems to be being put on the back bone yet its something which is critically required and to be quite frank is not really giving developers confidence in migrating to your new software, you would think some form of communication to the community about issues and time scales on resolution or even acknowledgement about the issues would be wise at this point.

[veljkocasa]

Maybe they solved it. (15/07/2016)
With VS update 3 kb3165756 I am able to add reference of library project (net451) and successfully build. But I still can't find a way for "using" that assembly in a class.... Does anyone can help?

[davidmdem]

@veljkocasa You don't mention how you were able to add the reference, but when I try through the GUI, Visual Studio gives the following message:

So, I don't think this was addressed. Though I don't remember that error message before. Maybe that was added?

[WolfspiritM]

There is a difference in referencing a "project" (as in a Library Project that resides in the same solution as the aspnet site) and referencing already compiled DLLs.

Cross Project References always worked.
Referencing a DLL still doesn't work (without using a nuget package) since ASP.net tooling moved to the dotnet cli.

[jemiller0]

No, referencing library projects did not originally work. I have no idea if it works now or not. At the moment, I don't have time to beta test alleged release software.

[veljkocasa]

Sorry, I've meant on cross project referencing, and for me it not working...
@davidmdem I am not getting that message, but from semantic I can see it is the same issue. Try to check does .net version which you use for building library proj is the same as .net version you are including in asp core proj, but probably that is not the solution :/

[JohnGalt1717]

FYI, you cannot add a .NET standard 1.x project as a reference to a .NET 4.6.1 project. It still fails to compile properly and intellisense doesn't work. The only way to do this is to link to the resulting DLL from the bin folder of the .NET standard project which of course causes issues.

It will add it, it just wont' work right which is kind of embarrassing that this is still broken given how key to the whole "Universal" .NET core thing this is.

[chdev77]

This is very frustrating! Created WebApi .NetCoreApp, Version=1.0. Cannot reference libraries 4.6.1. The only way is to directly reference the assembly in the bin/debug folder. This won't work well for CI builds. I've read many things on this topic and its continuously clear a Mud!.

So I created .NetCore SelfHost WebApi. Have an older 4.6.1 and cannot use it in the WebApi. This is great! The thing is, it builds with no error and the reference is added...but I cannot access it's objects from the WebApi.

Here is the project.json
`{
"dependencies": {
"BundlerMinifier.Core": "2.1.258",
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Mvc": "1.0.0",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.AspNetCore.StaticFiles": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0",
"System.Diagnostics.Process": "4.1.0"
//"ULPS.Dialer.Models": "1.0.0-*"
},

"tools": {
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final"
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"net461": {
"dependencies": {
"ULPS.Dialer.Models.dotnet461": {
"target": "project"
}
}
}
}
},

"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},

"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},

"publishOptions": {
"include": [
"wwwroot",
"Views",
"Areas/**/Views",
"appsettings.json",
"web.config"
]
},

"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}
`

[StarpTech]

Hi
what is the status of this issue? I can't add references to my project. The message from @davidmdem appears. I'm using the most recent tools.

[AlexeiScherbakov]

I think it will be fixed after .csproj/MSBuild will be able to build .net core/project.json/xproj directly

According to (https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/) - Q4 2016 / Q1 2017