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.
Related
My current project class library is in .Net Framework 4.7.2 (target framework) and we are using Microsoft.Azure.DocumentDB package. we have to update to version 3 of Azure
Questions
Does we will be able to do update into Microsoft.Azure.Cosmos package with class library in .Net Framework 4.7 or Microsoft.Azure.Cosmos package only supporting ".Net standard" framework ?
2)If Yes, then while migrating code we are getting "Inaccessible due to protection level error" in number of places.
3)If No, then does we need to change class libaray from .Net framework 4.7 to .Net Standard to migrate code ?
Microsoft.Azure.Cosmos is a NET Standard 2.0 library, NET Standard is an interface that defines a series of APIs that are implemented by different frameworks: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0
.NET Framework 4.7.2 is a framework implementation, compatible with NET Standard 2.0:
So the answer is, you can use Microsoft.Azure.Cosmos on a .NET 4.7.2 application without issues.
For migration from Microsoft.Azure.DocumentDB to Microsoft.Azure.Cosmos see: https://learn.microsoft.com/azure/cosmos-db/sql/migrate-dotnet-v3
The "Inaccessible due to protection level error" errors you are getting are probably due to your code still referencing APIs or types from Microsoft.Azure.DocumentDB. These are two different Major Version libraries, so your application code needs to change due to the breaking changes.
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.
im building an app using c# (not my first. other projects i dont have this problem). this one i included nuget package json
the problem that VS generates too many .dll files in my bin/debug folder (with exe). i don't want these dll files but it seems like the exe doesn't run without them (i coppied the exe to another path and run it)
when i search on the internet all the details about merging using some merge tool but my problem is related VisualStudio in the setting i believe?
This happens when you include a library which targets .NET Standard 1.5 or higher, from a project which targets .NET Framework 4.7.1 or lower.
The .NET Platform Standard table hints at this: it claims that .NET Framework 4.6.1 supports .NET Standard 1.5 or higher, but there's a footnote:
The versions listed here represent the rules that NuGet uses to determine whether a given .NET Standard library is applicable. While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
One of these issues is that you'll get a lot of extra DLLs, apparently because .NET Framework 4.6.1 only has partial support for .NET Standard 1.5.
The solution is for your project to target .NET Framework 4.7.2, or .NET Core.
I am working on a large C# project which uses code contracts extensively and compiles against an older version of the .NET Framework (3.5). This project is a library, and I am also developing other applications which consume it as a dependency. I would like to use .NET Core 2.1 for these new projects. I believe my options are as follows:
Upgrade the library from .NET Framework 3.5 to .NET Framework 4.6.1+, which I believe will make it compatible with .NET Standard 2.0 and thus usable by a .NET Core 2.1 project.
Upgrade the library to build against .NET Standard 2.0 explicitly, using the new .NET Core toolchain.
I have the following questions:
It looks like code contracts are dead and unsupported in .NET core; this means I will be unable to run the code contract analyzer if I go with Option (2), correct?
If I go with Option (1), the analyzer can still run but I'll have to switch to Igor Beck's unofficial NuGet package per this answer to support .NET 4.6.1+, correct?
Ideally I'd like to keep the benefits of code contracts, although since they're unsupported I recognize this will continue to hold back the library version as time goes on.
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.