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:
   • 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

[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:notifications@github.com] Sent: Thursday, May 19, 2016 2:59 AM To: aspnet/Tooling Tooling@noreply.github.com Cc: Jon Miller jemiller@uchicago.edu; Mention mention@noreply.github.com 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:notifications@github.com] Sent: Saturday, May 21, 2016 8:54 AM To: aspnet/Tooling Tooling@noreply.github.com Cc: Jon Miller jemiller@uchicago.edu; Mention mention@noreply.github.com 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 notifications@github.com<mailto:notifications@github.com> 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 Files\dotnet\dotnet.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 Files\dotnet\dotnet.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.piskunov@microsoft.com.

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.