Scott Hanselman

How to reference an existing .NET Framework Project in an ASP.NET Core 1.0 Web App

October 09, 2016 Comment on this post [25] Posted in ASP.NET | ASP.NET MVC
Sponsored By

I had a reader send me a question yesterday. She basically wanted to use her existing .NET Framework libraries in an ASP.NET Core application, and it wasn't super clear how to do it.

I have a quick question for you regarding core. We are rewriting our website using core, empty from the bottom up. We have 2 libraries written in .net 4.6 . One is our database model and repositories and the other is a project of internal utilities we use a lot. Unfortunately we cannot see how to reference these two projects in our .net core project.

It can be a little confusing. As I mentioned earlier this week, some people don't realize that ASP.NET Core 1.0 (that's the web framework bit) runs on either .NET Core or .NET Framework 4.6 aka "Full Framework."

ASP.NET Core 1.0 runs on ASP.NET 4.6 nicely

When you make a new web project in Visual Studio you see (today) this dialog. Note in the dropdown at the top you can select your minimum .NET Framework version. You can select 4.6.2, if you like, but I'll do 4.5.2 to be a little more compatible. It's up to you.

File New Project

This dialog could use clearer text and hopefully it will soon.

  • There's the regular ASP.NET Web Application at the top. That's ASP.NET 4.6 with MVC and Web API. It runs on the .NET Framework.
  • There's ASP.NET Core 1.0 running on .NET Core. That's cross platform. If you select that one you'll be able to run your app anywhere but you can't reference "Full" .NET Framework assemblies as they are just for Windows.  If you want to run anywhere you need to use .NET Standard APIs that will run anywhere.
  • There's ASP.NET Core 1.0 running on .NET Framework. That's the new ASP.NET Core 1.0 with unified MVC and Web API but running on the .NET Framework you run today on Windows.

As we see in the diagram above, ASP.NET Core 1.0 is the new streamlined ASP.NET  that can run on top of both .NET Framework (Windows) and .NET Core (Mac/Windows/Linux).

I'll chose ASP.NET Core on .NET Framework and I'll see this in my Solution Explorer:

Web App targeting .NET Framework 4.5.2

I've got another DLL that I made with the regular File | New Project | Class Library.

New Class Library

Then I reference it the usual way with Add Reference and it looks like this in the References node in Solution Explorer. Note the icon differences.

Adding ClassLibrary1 to the References Node in Solution Explorer

If we look in the project.json (Be aware that this will change for the better in the future when project.json's functionality is merged with csproj and msbuild) you'll note that the ClassLIbrary1 isn't listed under the top level dependencies node, but as a framework specific dependency like this:

"dependencies": {
"Microsoft.StuffAndThings": "1.0.0",
"Microsoft.AspNetCore.Mvc": "1.0.1",

"frameworks": {
"net452": {
"dependencies": {
"ClassLibrary1": {
"target": "project"

Notice also that in this case it's a type="project" dependency in this case as I didn't build a NuGet package and reference that.

Since the .NET Core tooling is in preview there are some gotchas when doing this today.

  • Make sure that all your class libraries are targeting an appropriate version of the .NET Framework.
    • For example, don't have a 4.5.2 Web App targeting a 4.6.2 Class Library. This could bite you in subtle ways if things don't line up in production.
  • dotnet restore at the command line may well get confused and give you an error like:
    • Errors in D:\github\WebApplication2\src\WebApplication2\project.json - Unable to resolve 'ClassLibrary1' for '.NETFramework,Version=v4.5.2'.
    • Use Visual Studio to build or run msbuild at the command line.
  • You can restore packages from the command line with nuget.exe version 3.4.4 or greater if you restore on the .sln file like this:
    • D:\github\WebApplication2>nuget restore WebApplication2.sln
      MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
    • I recommend you run nuget.exe to see what version you have and run nuget update -self to have it update itself.

These gotchas will be fixed when the tooling is finalized.

Hope this helps!

Sponsor: Big thanks to Telerik for sponsoring the blog this week! 60+ ASP.NET Core controls for every need. The most complete UI toolset for x-platform responsive web and cloud development. Try now 30 days for free!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
October 09, 2016 7:32
Does it differ in performance,
Whether the app be written in full .net framework or .net core ?

Performance is too important for us.

If i choose full .net is it then possible to referenced ef 6?
October 09, 2016 8:59
What if you started as .net core, like the girl who asked the question and want to change to full framework ? Is it enough to update the project.json to. Resemble your example ?
October 09, 2016 16:59
I still cannot get this to work, even though I am able to add a reference to the "old" class library from the "new" core web project, both msbuild and visual studio cannot resolve the reference.
October 09, 2016 19:27
is there a word that has a meaning opposite to "supercalifragilisticexpialidocious"?

if there is, that's the word that i'd use to describe some of the .NET Core 1.0 gotchas.

KEY .NET FRAMEWORK libraries are NOT available YET for .NET CORE!(a)

Alternative libraries are available although many are works in progress.

That does not mean key .NET Framework libraries will not become available in "the future", however, .NET CORE 1.0 was RTM'd June 27th, 2016(b) and is missing, among other things, System.Drawing(c, d, e) and System.Net.Mail(f).

Programmers will want to do a lot of research and reading before committing enterprise applications to .NET Core 1.0.(g, h, i, j, k)

The sample references below are only the tip of the iceberg ... be careful that your legacy enterprise projects do not suffer the same fate as the Titanic while crossing over to .NET Core 1.0.




(d) (James Jackson-South)




(h) and


(j) Pay attention to the notes!

October 10, 2016 11:59
I was having the same issue with dotnet restore from my VSTS environment. Its very annoying that you have to do the Nuget restore trick to get things building in VSTS. I'm not seeing any progress in the github issue, is this still on your list to fix before marking the tooling as release candidate?
October 10, 2016 12:28
What benefits does ASP.NET Core have over the full framework ASP.NET ?

October 10, 2016 13:28
Thanks Scott for this post!

Im having problems with exact opposite thing: created a .net core class lib, and want to reference it from full .net class library. Added a reference, but intellisense doesn't see the namespace or any type from core lib, and can't compile it. Any ideas?

What's interesting, somehow worked once, then stopped working. But when it worked, it was complaining about Func<,>, that i need System.Runtime 4.0.2, which I added through nuget. But after it stopped working, couldn't reproduce it again.

October 10, 2016 14:32
It's simply a horrible time for, .net core etc... I guess it will be easier once the tooling is updated. This has been the strength of Microsoft over the past 3 to 4 decades and why I've used it so much, but there's a push inside MS to work on an antiquated command line environment, throwing the opensource stuff in the mix. I get the feeling that there are too many rails fanboys in MS. What MS needs to do is listen to the VB people, they have always had this sense of developer productivity, but they have been sidelined because VB is probably not cool enough. We know this because core doesn't even support VB. I say MS needs to stop copying others to look cool and start doing what they do best and that's supporting the developer in his/her productivity goals.
October 10, 2016 17:37
If we look in the project.json (Be aware that this will change for the better in the future when project.json's functionality is merged with csproj and msbuild)...

So does that mean that project.json will become more like the old-style projects with all the stuff hidden away and you do everything via property dialogs?

If so, that makes me sad. I was looking forward to being able to change the project definition and build script by editing the file (with decent intellisense) and having that be the change
October 10, 2016 19:16
Gerry, I unfortunately have to agree. Although .NET Core (the set of assemblies) RTMed months ago, the ecosystem did not. For serious projects that would've otherwise relied on several NuGet packages, a medium to large team of developers, working continuous integration, etc., .NET Core is simply not ready for prime-time.

Microsoft declaring that something has RTMed has nearly always meant the tooling had also RTMed at the same time; however, that was not the case with .NET Core. The Visual Studio and command line tooling is far from robust, and downright buggy in many instances. Additionally, .NET Core developers--especially developers of packages--are forced to learn and interact with project.json, a file that Microsoft has already said is deprecated in favor of MSBuild. And yet, what exactly will be replacing project.json is still an unknown.

It will be many, many months before .NET Core development is as easy and seamless as .NET Framework development is today. I look forward to deploying applications in Linux someday; that day is just not today.
October 11, 2016 13:20
Has anyone tried to use their Class Library with EF6 and Stored Procedures, this would be so useful to get working. I Keep getting,

"No connection string named 'MyEntities' could be found in the application config file."

October 11, 2016 13:22
How about a blog post for references going the other way - .NET Framework class library --> .NET Core project.
October 11, 2016 16:46
If I understand correctly ASP.NET Core is next main version of ASP.NET and it can use main version of .NET Framework and "forked" version: .NET Core.
Why did Microsoft change its name to "Core" that suggest that it is "forked" too?
October 11, 2016 18:41
Just wrote the blog post how to do the opposite thing, use Core lib from 4.6 project in the same solution: Hope it helps, but I'm wandering if there's a better solution ...
October 11, 2016 19:00
I followed your instructions (new project, new class library) and can't get it work.
When i tried to add my reference, I always get the error message which tell me to make a nuget package, etc ...
Did i forgot something ?
October 12, 2016 1:11
I'm hoping that somebody here can answer my question I posted on StackOverflow:

When running .NET Core on the Traditional .NET Framework, I want to allow only a certain assembly access 4.x methods. I don't want to 'accidently' use 4.x methods throughout my project, I could designate only certain assemblies as ones that can access 4.x features.

I know there's something I'm missing in configuring the project.json, but I'm having a hard time figuring it out. Thanks!
October 12, 2016 16:07

Just in the process of working on a new Web Api. For various reasons we have to use an older legacy object model, build for x86, targeting .Net 4.5.1.

The new WebApi is based on Asp.Net Core - and using the approach above works perfectly (after some initial struggling).

Only problem I had left was the toolchain, and being able to do a "dotnet restore" - but it sounds like that is soon fixed.

Keep up the good work.
October 13, 2016 3:32
Sander Hammelburg, we have an N-tier web project, with our DAL as a .net4.6 core class library - we used the tools as to help us get EntityFramework 6 working.
October 13, 2016 14:45
Hello Scott.
Probably a bit off topic but that's the best place I was able to find so far.

I'm trying to embed some json documents into a core assembly. The problem is that those documents are in a different git repository and I have them as submodule and it is outside the project folder:

----{some subfolders}

In project.json I have the following:
"buildOptions": {
"embed": [ "../../submodules/shared-documents/unit-tests/**" ]

Compiler doesn't like this and complains as follows:
CS1508: Resource identifier 'unit-tests.invalid.json' has already been used in this assembly.

Do you think it's possible to make this kind of trick with core project?

October 17, 2016 18:01
Hi Scott. I have a similar issue and I am targeting .NET Framework 4.5.1.
After reading your blog article on this subject I am a little unclear what TFS Online Build Process I need to change; my build works fine in VS2015 Update 3.

Please could you advise?

##[section]Starting: Run dotnet.exe
##[command]dotnet.exe restore
Welcome to .NET Core!
Learn more about .NET Core @ Use dotnet --help to see available commands or go to
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4726 ms
2016-10-17T13:23:05.7606879Z log : Restoring packages for C:\a\1\s\Mainline\src\MyNamespace.Web\project.json...
Expanding 100% 19475 ms
error: Unable to resolve 'MyNamespace.Common' for '.NETFramework,Version=v4.5.1'.
log : Restoring packages for tool 'BundlerMinifier.Core' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json...
log : Restoring packages for tool 'Microsoft.AspNetCore.Razor.Tools' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json...
log : Restoring packages for tool 'Microsoft.AspNetCore.Server.IISIntegration.Tools' in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json...
log : Writing lock file to disk. Path: C:\a\1\s\Mainline\src\MyNamespace.Web\project.lock.json
log : C:\a\1\s\Mainline\src\MyNamespace.Web\project.json
log : Restore failed in 4208ms.
Errors in C:\a\1\s\Mainline\src\MyNamespace.Web\project.json
Unable to resolve 'MyNamespace.Common' for '.NETFramework,Version=v4.5.1'.
##[error]Process completed with exit code 1.
##[section]Finishing: Run dotnet
October 18, 2016 0:07
While works for primitive, empty projects, this is not currently working in real life due to "read-only on copy bug" for 3rd party DLLs referenced in Full .Net Framework project. - "error : failed to make project runnable".
October 21, 2016 13:30
How do you feel about the move away from project.json to an MSBuild XML file?
October 22, 2016 19:31
Hi Scott,

I'm still really confused by what is compatible with what. I always see the graphic, the first one in your post, for .NET Core 1.0 with .NET 4.6, but then you reference .NET 4.5.2 to be a "little bit more compatible"? Why does the graphic have .NET 4.6 if .NET 4.5.2 is compatible with .NET Core 1.0? What am I missing?

I'm working to create a roadmap for our enterprise, but this makes it difficult to understand what we should be doing now to set ourselves up for a future move to .NET Core when other key pieces of it, libraries and tooling, become available.

If you could clear up this ambiguity for me, I would greatly appreciate it!
October 26, 2016 7:43
This is kind of a cop-out answer. You're basically saying "How do you reference a 4.6 Library from a .NET Core project? Make sure it doesn't target the core framework!".

If you want people to actually be USING the new framework then there needs to be support in the Visual Studio tooling to allow developers to easily reference projects of any type. So I should be able to have the following combos:

  • .NET Core Framework Project should be able to reference libraries that are built against .NET Standard or Full .NET
  • .NET Standard Project should be able to reference libraries that are built against Full .NET or .NET Core Framework
  • Full .NET Framework Project should be able to reference libraries that are built against .NET Standard or .NET Core

    The fact that this situation (the state of the tooling) is SOOOO bad is shameful. By no means is .NET Core Framework really RTM. At best it's a glorified beta.
  • November 03, 2016 15:30
    This means I can only add .net framework 4.5.2 projects, but not .net core projects. :(

    Comments are closed.

    Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.