I was reading this article: https://blogs.msdn.microsoft.com/cesardelatorre/2016/06/28/running-net-core-apps-on-multiple-frameworks-and-what-the-target-framework-monikers-tfms-are-about/ about using different monikers for .NET core app and I was wondering what is the difference between creating ConsoleApp with .NET framework 4.5.1 and creating ConsoleApp .NET core with moniker set to .net framework 4.5.1.
Is it expected to have any differences in behavior? The only difference I can think of is that the first one will use csproj and the second one will use xproj (ok xproj is deprecated now, so new csproj format). I'm asking this question because my current app is built on top of .NET framework 4.5.1 and I was thinking of migrating it to .NET core on top of .NET framework.
Calling the project.json build tools the ".NET Core SDK" was only partially true: the tools can be used to build for runtimes other than .NET Core, i.e. .NET Framework. A console app built for .NET Framework using project.json is exactly the same as a console app built for .NET Framework using csproj.
The new csproj format tries to correct this common mixup. You'll notice in VS 2017, projects use the ".NET SDK", aka "Microsoft.NET.Sdk" (dropped Core from the name). This new SDK can be used to build .NET Framework, .NET Standard, and .NET Core projects.
Related
Good afternoon.
I am planning to move a large project from .net framework 4.6.1 to .net core 3.1. First, I decided to update/replace libraries that are not supported in .net core 3.1. For packet analysis I use .net portability analyzer (recommended by Microsoft).
The project uses System.ComponentModel.Composition to dynamically import .dll. Tried updating this package to the maximum version (6.0.0) - still not compatible. Then I tried using System.Composition and Microsoft..Composition - to no avail, although it says that .net standard 2 and .net 6 are supported. How can I replace this package for a successful migration to .net core 3.1.
I'm trying to figure out how to reuse a legacy .net 4.7.2 library with both a legacy .net 4.7.2 app and a new .net core 3.1 app.
The legacy lib depends on EF 6.4 and Oracle.ManagedDataAccess.EntityFramework nuget packages.
My initial take was to multi-target both .net 4.7.2 and .net standard 2.1 to be able to consume the lib from the new .net core 3.1 app alongside with the old .net 4.7.2 OWIN app.
While EF 6.4 supports .net standard 2.1, Oracle.ManagedDataAccess.EntityFramework seems to target .net only, resulting in NU1702:
package Oracle.ManagedDataAccess.EntityFramework was resolved using
'.NETFramework,Version=v4.7.2' instead of the project target framework
'.NETStandard,Version=v2.1'. This package may not be fully compatible
with your project.
It may be ok for a library targeting .net standard to reference a .NET Framework library that happens to only use types within the .NET Standard API set, so chances are Oracle.ManagedDataAccess.EntityFramework, apparently built for .net 4.5, may still work.
I haven't been able to find a replacement for that package targeting .net standard, so the question is: is this situation ok and, if not, may be better ways exist to reuse such legacy libs in .net core apps?
how to reuse a legacy .net 4.7.2 library with both a legacy .net 4.7.2 app and a new .net core 3.1 app. The legacy lib depends on EF 6.4 and Oracle.ManagedDataAccess.EntityFramework nuget packages.
You can't. Oracle.ManagedDataAccess.EntityFramework can't be used in a .NET Core app.
You can use Oracle.ManagedDataAccess.Core and Oracle.EntityFrameworkCore in a .NET Core app, but only with EF Core, not EF 6.
IE Oracle doesn't support the combination of EF 6 and .NET Core.
I am new to .NET Core Framework. I am building a .NET Core 2.0 console application that references the following two dependencies:
System.Configuration.ConfigurationManager built for .NET Framework 4.5 downloaded from NuGet.
A project from the same solution which is a .NET Framework 4.5 class library project
Since the Core Framework is cross-platform, I want to publish the application and run it on Linux. Should it work even though the two dependencies are not build for .NET Core? Or do I have to care during development that all of my dependencies are explicitly published for .NET Core?
In other words: Is a .NET Core app only cross-platform portable if all of it's dependencies are .NET Core?
Our development team has many .net framework 4.6 projects (VS 2015).
We want to start a new .net core project to eventually deploy on linux.
We have installed VS 2017 and the .net core 2.0 preview.
But how can we reuse the existing library projects in this new one ?
We research but it is not clear for us :
- we need to change the target of the old projects from ".Net Framework 4.6" to ".NetStandard 1.x" ? (and solve the incompatibility)
- or we can use them like that ? (but how?)
Thanks
Microsoft publishes official guidelines for the porting process: https://learn.microsoft.com/en-us/dotnet/articles/core/porting/
To summarize:
Deal with your dependencies (by migrating them), recursively
Retarget your projects. Applications move to .NET core, libraries move to .NET Standard, where possible.
Use some helpful tooling to verify your ports
Test
So, to share things between .NET Framework and .NET Core, your libraries should target .NET Standard, as much as possible. Otherwise, you could possibly share the code and have to do multiple builds - build once targetting .NET Framework and again targetting .NET Core.
You can use/reference your old projects only if you target Full Framework in your new projects (which is not the case if you are going to run them on Linux).
If you started with preview you should convert you old projects to .Net Core projects and either target .NET Core 2.0 Preview or NetStandard 2.0 Preview. If you are not going to reference/use your old projects outside your application it might be better to target .NET Core 2.0 Preview because it might provide more API than NetStandard 2.0 Preview.
I have a .NET Core (ASP.NET Core) project created using Visual Studio 2017 RC (MSBuild).
I also have an old F# project library (traditional .NET Framework Library) that compiles to a dll file. I want to use it in said ASP.NET Core project.
To do that, I added a project reference in the ASP.NET Core project, opened the namespace, and made a few function calls in my controllers; it works perfectly when running the ASP.NET Core server using ISS from VS.
My question is, will this arrangement work if I want to deploy to linux (Ubuntu)? Or does using external PCLs/dlls from .NET Core instantly make it windows-only?
Note that I didn't have to add .NET Framework as a target framework in my csproj (it's MSBuild Core), it just worked.
Since your F# project targets the .NET Framework it will not run cross platform. If you modify your F# project to target the .NET Standard library it will. Here is a video by Immo Landwerth explaining how the .NET Standard Library works.
You should be able to just to reference the .NET standard library and not have to change anything. However the current version, which is 1.6, is missing a lot of API's from .NET Framework. This is fixed in 2.0. Infact since your using .NET Core 1.1 I think you are already using 2.0, but I'm not certain. Here is another video by Immo explaining how it should work.
That being said, I'm not sure what the F# support is like with .NET Standard.