Running on full .NET framework with referenced assemblies

I'm sorry if this has been asked before, but I can't find good/definitive information about this. The ASP.NET 5 RC1 MVC app had the option to be run either on full .NET framework or on .NET Core. The target monikers from RC1 are obviously not relevant anymore.

The reason I'm asking is because I'd like to reference existing .NET assemblies in the new MVC app which are not portable assemblies.

In the blank dotnet new app, I see only netcoreapp1.0 moniker:

 "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }

while the MVC app has the following moniker:

  "frameworks": {
    "netcoreapp1.0": {
      "imports": [
        "dotnet5.6",
        "dnxcore50",
        "portable-net45+win8"
      ]
    }
  }

The "imports" suggest that it should be possible to run on full .NET CLR (I'm guessing) but I can't reference assemblies (.NET Core projects only support referencing .NET framework assemblies in this release. To reference other assemblies, they need to be included in a NuGet package and reference that package) nor can I reference a .NET nuget package (for instance, try log4net) -- (The dependency log4net 2.0.5 does not support framework .NETCoreApp,Version=v1.0.). So, are we unable to run the "new MVC" framework on full .NET? Is this a tooling issue (and if so, what would be the workaround) or RC2 issue or is it actually designed that way (to be run only on .NET core and not on full .net framework)?

To be as concrete as possible, we're looking into upgrading existing infrastructure in a corporate environment and we need to reference (among other stuff) IBM DB2 and CTG assemblies, which are not (and who knows when and if) .NET core "compatible").

I'm guessing it should be possible by wrapping existing DLL in a "project.json" wrapper project while defining target framework moniker compatible with netstandard1.5 and somehow referencing the wrapped project from the MVC, but I'm not sure whether this is a way to go and whether it is a supported approach. I got the idea from Corefx documentation.

Any feedback would be appreciated.

You could target net451 in your projects - for e.g. https://github.com/aspnet/Mvc/blob/dev/samples/MvcSandbox/project.json#L37

@pranavkm

@pranavkm thanks, for the pointer; I tried that -- my project wouldn't build if I add the net451 target framework moniker to project.json. The errors are along the following line:
Error NU1002 The dependency System.Diagnostics.Process 4.1.0-rc2-24027 does not support framework .NETFramework,Version=v4.5.1.

If I move the dependencies under the frameworks/netcoreapp1.0 element, the net451 does not build (missing dependencies, obviously).

I suppose I should use different dependencies for full .NET?

The referencing of the existing assembly is still unclear to me, though; previously we had a dnu wrap command to wrap an assembly; currently, there is no dotnet wrap command; Perhaps something like dotnet pack? Or is this because the tooling is "preview 1" and we should manually wrap the existing DLL?

I created a directory in the src folder (sibling of MVC Website project directory) and I put the simplest DLL in there with the following project.json:

{
  "dependencies": {
  },
  "frameworks": {
    "net451": {
      "bin": {
        "assembly": "ClassLibrary1.dll",
        "pdb": "ClassLibrary1.pdb"
      },
      "dependencies": {
      }
    }
  },
  "runtimes": {
    "win": { }
  },
  "version": "1.0.0-*"
}

I couldn't create a NuGet package:

C:\tmp\DeleteWeb\src\WrapLib>dotnet pack
Producing nuget package "WrapLib.1.0.0" for WrapLib
NuGetResources.CannotCreateEmptyPackage

nor could I reference this project.json project from the existing project.

So, in other words, recipe on how to target the full .NET framework and how to reference an existing assembly would be very nice.

BTW I set up a quick mtg for Monday to discuss this.

Yes, why default templates don't provide .NET framework (Windows only) templates?

@Jupakabra

@Jupakabra that template is effectively Windows-only anyway, unless you use Mono.

@skyflyer

@skyflyer there are a few things going on here:

If you're using netcoreapp then you cannot use .NET 4.x assemblies/packages
If you're using net4xx then you can use the frameworkAssemblies section of project.json to reference DLLs that are installed by .NET Framework (the stuff in the GAC)

Either way, in general you should be able to "wrap" a DLL (either one that's on disk, or one that's built from a csproj) and then reference that from your app's project.json file.

@pakrym will see if we have a good sample we can share with you for how to do a wrapped project.

@Eilon

@Eilon, sounds good, but doesn't answer the question entirely. I'll tried searching for information, but came empty handed.

It would be nice if target framework monikers would be documented (or is it just me and I can't find them)?

And also, it would be nice if it was documented how to reference an existing dll with RC2 tooling.

Sure, this is not an MVC-only issue (and I should direct the question in another tracker), but the issues at hand relate to "how to run the new MVC on a full .NET framework". Given your answer, I suspect "File new project" and "changing netcoreapp to net451 framework should do the trick (will test it again ASAP tomorrow, but I tried that before and documented my failure above (3 days ago))? What about MVC dependencies?

@skyflyer

@skyflyer You can look at mappings and names in https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Frameworks/DefaultFrameworkMappings.cs

All,

I managed to get it working with the following steps:

remove netcoreapp framework from project.json and replace it with an empty net451
add relevant NuGet dependencies in the main dependencies section of the project file
add a blank Class library project
reference an existing DLL in a Class Library project: I used a snippet from the web to reference the DLL on the disk using the following syntax:
```
"net451": {
  "bin": {
    "assembly": "external\\ClassLibrary1.dll",
    "pdb": "external\\ClassLibrary1.pdb"
  }
}
```
I referenced the class library project from the web project
It compiles and runs fine, even though Visual Studio Intellisense is not happy and is complaining that the "type or namespace ClassLibrary1 can not be found", which is strange, since it compiles and runs just fine.

It runs from visual studio and from the command line using dotnet run. I've uploaded the solution for reference. I've also reported the Visual Studio Intellisense error through their feedback mechanism.

Indeed, RC2 broke the adding of .NET DLLs. Your method worked, but didn't have any Intellisense, which is a must.
But it works if you pack them using nuget and install via local nuget server for example.

How to create a package is here.
First option (from dll) didn't work for me, so I did it from csproj using this command: nuget pack MyProject.csproj

Kotylo, Did you create a class library (core) project to reference DLLs/legacy (.NET 4.x) projects. Or directly created packages out of legacy csproj? Do you mind uploading your sample project to Github? I'm having lot of trouble referencing legacy DLL/projects (.NET 4.x). RC1 allowed us to directly reference legacy projects. I'm struggling to upgrade to RC2. I have a bunch of legacy projects (DLLs) to use in RC2.

I tried creating a class (Core) project and plain Class library project and referenced legacy projects and created Nuget packages and tried to install them in core project. Either way, it still complains "The dependency xxx could not be resolved"

Thanks much.

@inianp

@inianp
This one:

Or directly created packages out of legacy csproj?

Just create package from your .NET 4.x .csproj, if you have sources, that is. For some reason it didn't work for me if I tried to create Nuget package directly from DLL. Maybe I did something wrong there.

@skyflyer

@skyflyer

From the ASP.NET Core 1.0 Schedule and Roadmap:

"The November and May release candidates (RC1 & RC2) are supported and production-ready cross-platform releases."

production-ready

perhaps "somewhat production ready" would be more appropriate.

Here is a very trival 4.5.2 class library: TemperatureConversionNet452

using System;

namespace TemperatureConversion
{
    public class CelsiusFahrenheit
    {
        public static Double Celsius(Double fahrenheit)
        {
            return (fahrenheit - 32d) / 1.8d;
        }

        public static Double Fahrenheit(Double celsius)
        {
            return (celsius * 1.8d) + 32d;
        }
    }
}

There is nothing in the above code to prevent it from working in all versions including Core.

The pain you feel is more than just mine; it is the collective pain of our global gobsmacked community.

isA Lie by any other name still a lie?

"Does your dog bite?"

.NET Standard Library
"Each .NET runtime version advertises the highest .NET Standard version it supports, a statement that means it also supports previous versions."

"It's not my dog."

The table ".NET Platforms Support" at .NET Standard Library implies that .NET Core, a.k.a. netcoreapp will never be able to reference .NET Standard, a.k.a. netstandard.

the real problem / truth in advertising

Given the number of globally gobsmacked complainants, imho it's fair to suggest that a disclaimer be presented when one is choosing, for example, which version of Web API to use.

Miha, if you revisit the table, .NET Standard (netstandard), .NET Core (netcoreapp), and .NET Framework (net) are all on separate rows; imho, wishful thinking on my part, they should be able to reference one another.

.NET Core Roadmap, version 2016-07-15

the following is open to interpretation:

Q4 2016 / Q1 2017
This will be the first minor update, mainly focused on replacing .xproj/project.json
with .csproj/MSBuild.

Project format update should be automatic. Just opening a 1.0 project
will update it to the new project format. There will also be new functionality
and improvements in the runtime and libraries.

As context, .NET Core 1.0 included a preview version of the .NET Core Tools,
referred to as “Preview 2”. The tools were “preview” primarily because
we knew that we would change the tools experience post 1.0.
.NET Core and the .NET Core Tools will both be “RTM quality” or “stable” with this release.

.NET Core Tooling
Support for .csproj/MSBuild project system
dotnet restore improvements to not restore packages that are part of .NET Core
New commands for managing the frameworks on the machine
dotnet publish will publish only required dependencies, for optimal distribution size

BOTTOM LINE

WEB-facing applications and DESKTOP-facing applications share many Enterprise custom code bases; it's the customized code that can give one company a competitive advantage over another company.

FWIW, this needs to be fixed, soon; if that does not happen, it may cost Microsoft loss of customers; already it has cost Microsoft loss of trust.

The support statements were true when they were made and continue to be true. Running .NET Framework assemblies on .NET Core is not supported. That doesn't mean it won't work. But it's definitely not supported. And there are countless cases where it in fact won't work - e.g. try using System.Web or WCF. It turns out that if the API surface used by the assembly is sufficiently limited and doesn't conflict with anything in .NET Core, it'll work. It's ultimately just a plain old .NET DLL that contains MSIL, so as long as it has the right references, it'll generally work.

The only supported ways to implement this scenario is to either:

Cross-compile the code for each target framework, and thus have one assembly per target framework.
Build one assembly that targets one of the netstandard targets that support all the desired .NET implementations, e.g. netstandard1.2.

Admittedly, I have only just started looking into moving from RC1 (and the only reason we're doing it now is that Azure now only supports RTM applications) but we're running into trouble at almost every turn. Third party libraries that we are using have not been moved to Core versions and bits of the framework haven't been ported across (System.Data).

If running .Net framework assemblies on .Net Core is not supported how do we move forward?

If running .Net framework assemblies on .Net Core is not supported how do we move forward?

You can run ASP.NET Core on .NET Framework or .NET Core.

Hi David, thanks for the response, how do we do this? As examples, we are using SendGrid for emails and there doesn't appear to be a Core compatible version. We also use DataSets for reading from Excel files and having trouble referencing that as well.

@redowl3

@redowl3 have your project target net451 (or similar) instead of netcoreapp1.0 in the frameworks section of project.json. That will use .NET 4.5.1 (or similar), which means that you can use just about any .NET 4.5.1-compatible NuGet package. SendGrid should work just fine (I haven't tried it, but I can't imagine why it wouldn't work).

Thanks Eilon. When we target net451 does that mean all referenced projects need to target net451 instead of netcoreapp1.0?

Is this how MSFT envisaged working with non core assemblies would be?

We're having real trouble in finding out how to reference multiple frameworks to update our working RC1 solution to RTM (which has been forced on us by the decision by MSFT not to support these versions on Azure). The solution suggested by Eilon has helped fix some issues but created others.

@redowl3

I landed here trying to google if there is a way to target multiple frameworks in project.json and still do a nuget pack without using a nuspec, thanks google!

@redowl3 @gerryLowry

It saddens me to see everyone complaining about project.json and the dotnet CLI departure from MSBuild with expectations that one can actually move without changing stuff ... Using datasets in 2016, is doing it wrong, it's code that should have been refactored ages ago.

project.json and the dotnet CLI is a breeze of fresh air in the Microsoft space, it is a very clever attempt to bring the stack closer to what the rest of the world is doing in the node.js stack and the rest of the open source stack. Working with these two is a very nice development experience, despite all the current issues with packing and immature tooling around them.

MSBuild was/is a pain to customize, a pain to deploy custom extensions across a globalized code base, the development experience is a piece of crap and editing the proj files XML is clunky.

Azure doesn't force anyone to do anything! If I'm using Azure App Service without deploying my own ASE there's not much I can do to control my stuff. However if I want to do my own thing and have a high level of control I'm on other PaaS offerings with other level of control: Docker, App Service Fabric, Cloud Services, etc. I think there's still people maintaining Docker images with the preview versions of DNX :)

Hi djfr, thanks for joining in the discusssion.

In our particular circumstances we do need to use DataSets as we are using a 3rd party library that converts Excel to DataSets. Like a significant amount of 3rd party components this has not been ported to Core so we need to target multiple frameworks, which in our opinion has been a major pain, mainly due to the complexity of trying to understand multiple frameworks, dependencies, includes etc... We totally understand the direction MSFT are trying to move to and that there would be some pain points along the way.

And your right Azure does not force anyone to do anything(!) but again in our circumstances we had an ASP.NET RC1 application running very nicely in the cloud but since this announcement (https://blogs.msdn.microsoft.com/waws/2016/06/14/supporting-asp-net-5-core-rc1-on-azure-app-service/) if we want to continue hosting our application on Azure we are 'forced' to upgrade to Core.

Hello All,
I haven't read all the discussion. I start working with .net core framework (not the real core, but ASP.NET Core Web Application(.net framework)) few weeks ago, I am having a problem with referencing the DLL. I can add the NuGet package that I created myself, but the intelligence would not recognize the namespace.
If I add reference to the project directly with source code in the same solution, then everything works fine. In this way, I have to have the source code for the projects that I am willing to reference .
I assume this is a bug, but correct me if the core framework is designed this way.

@benzhi2011

@benzhi2011 I haven't read all your comment, but basically no actual support for "old" .net 4.5.2. Even Azure will only support Core.

As a workaround, you can have intellisense by adding the dll through Nuget Package manager. So you can create your own package from solution, then setup .net core project to use the Nuget.config file :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="MyProjectSource" value="nuget\packages" />
  </packageSources>
</configuration>

@kotylo

@kotylo Thank you for your workaround, it works perfect.

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.

Navigation Menu

Repository navigation

Running on full .NET framework with referenced assemblies #4682

16 remaining items

production-ready

isA Lie by any other name still a lie?

"Does your dog bite?"

"It's not my dog."

the real problem / truth in advertising

.NET Core Roadmap, version 2016-07-15

BOTTOM LINE

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Running on full .NET framework with referenced assemblies #4682

Description

Activity

pranavkm commented on May 19, 2016

skyflyer commented on May 20, 2016

Eilon commented on May 22, 2016

Jupakabra commented on May 23, 2016

Eilon commented on May 23, 2016

Eilon commented on May 23, 2016

skyflyer commented on May 23, 2016

javiercn commented on May 23, 2016

skyflyer commented on May 24, 2016

kotylo commented on May 26, 2016

inianp commented on Jun 1, 2016

kotylo commented on Jun 2, 2016

16 remaining items

gerryLowry commented on Aug 24, 2016

production-ready

isA Lie by any other name still a lie?

"Does your dog bite?"

"It's not my dog."

the real problem / truth in advertising

.NET Core Roadmap, version 2016-07-15

BOTTOM LINE

Eilon commented on Aug 25, 2016

redowl3 commented on Aug 29, 2016

davidfowl commented on Aug 29, 2016

redowl3 commented on Aug 29, 2016

Eilon commented on Aug 30, 2016

redowl3 commented on Aug 30, 2016

redowl3 commented on Sep 5, 2016

djfr commented on Sep 20, 2016

redowl3 commented on Sep 20, 2016

benzhi2011 commented on Oct 13, 2016

kotylo commented on Oct 13, 2016

benzhi2011 commented on Oct 13, 2016

Eilon commented on Jun 9, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions