I am converting a project from .net framework to .net core 2.
I need to check if my dependencies are compatible with .net core 2.
how do I check if https://www.nuget.org/packages/Aspose.Cells/7.6.0 supports .net core 2 or .net standard or .net framework?
Thanks
Please check in their link
Platform Independence
You can use Aspose.Cells for .NET to build any type of a 32-bit or
64-bit .NET application including ASP.NET, WCF, WinForms, UWP, .NET
Standard, .NET Core etc. It is possible to use Aspose.Cells for .NET
via COM Interop from ASP, Perl, PHP and Python. You can also use
Aspose.Cells for .NET to build applications with Mono.
Updated
On 2018 they have updated their Feature overview page indicating they support .net core, so probably must have supported after 18.0 version.
You can ask them by using their customer support forum
Related
I'm working on a class library project whose Target Framework property is set to .NET Standard 2.0.
Based on the documentation, I understand that my code will compile in such a way that it will be compatible with .NET Core 2.0 and .NET Framework 4.6.1. Is that correct?
Does this mean that I can use (and mix together) types and assemblies from .NET Core 2.0 and .NET Framework 4.6.1 in my project? I'm also unsure about which pages from the Microsoft documentation apply to my project.
Would I be correct in thinking that both the following documentation pages reference the types and assemblies that I'll use in my project?
.NET Core 2.0
.NET Framework 4.6.1
I tend to think of .NET Standard as a specification of APIs that are supported for different platforms and .NET versions. It’s a “least common denominator” of APIs supported for different platforms. A platform might be .NET Core, .NET framework or Unity.
So let’s say your library is Standard 1.0 this means that it can run on a wide range of platforms, but the number of APIs specified in that standard is limited compare to the full .NET Framework or .NET Core.
It’s important to understand that .NET Standard is just a “standard” or a promise of supported APIs for a given platform, you could write an OS for a microwave that supports .NET Standard 1 (implements all API in the standard) and the a class library for .NET Standard 1 work run on that microwave
Have a look at the docs, they have a great table that explains this: https://learn.microsoft.com/en-us/dotnet/standard/net-standard
You can use all the things, you just have to setup your project correctly. Limitations will be that .NET Core objects/methods/etc. will not be directly interoperable with .NET Framework. You will have to work through .NET Standard for indirect interoperability.
This article explains how to target both in the same .sln:
.Net Framework and .Net Core in same solution
This article helps you understand .NET Standard in relation to .NET Framework and .NET Core. Essentially, .NET Standard is base library which both .NET Core and .NET Framework sit on. .NET Core and .NET Framework are completely separate libraries, however they are both interoperable through .NET Standard.
http://www.codedigest.com/quick-start/9/what-is-netstandard
I created a new project in VS 2019 in .NET Framework 4.6 and now I want to upgrade it to .NET Core 3.1.
I do not want to do manually because their is ton of code.
How can I do this?
Microsoft published a guide for porting .NET Framework applications to .NET Core:
https://learn.microsoft.com/en-us/dotnet/core/porting/
In a nutshell, it boils down to the following:
Manually convert your dependency and project files.
Ensure that all your dependencies are compatible with .NET Core.
Use the .NET Portability Analyzer to find out if you are using features which are not supported in .NET Core.
Use the .NET API analyzer to find out if you are using features which are not supported on some platforms.
Target .NET Core, fix compile errors and test.
The guide contains detailed descriptions for specific steps (e.g., how to port your WinForms/WPF UI code), which are too long to paraphrase in an SO answer, so be sure to read it carefully.
I do not want to do manually because their is ton of code.
Then you'll have to pay a developer to do that for you. Sorry, but at the time of writing, there is no fully automated .NET Framework -> .NET Core converter available.
Can someone help me out with the following questions please. Our team is trying to use Aspose.Total and have the following concerns
Does Aspose.Total for .NET support .NET core? If yes which version
Does Aspose.Total(version that supports .NET core) have all the features that may be in Aspose.Total full .NET Framework?
As Microsoft is moving to saying .NET 5(no more .net core after 3.1 or so) is it advisable to develop with Aspose.Total that currently support .net core? Or we should develop using .net full Aspose.Total version
Thanks
The short answer is yes, Aspose.Total supports .NET Core, the products included in Aspose.Total supports .NET Standard 2.0, so you can use them in .Net Core 2.0 or newer. Regarding version of Aspose.Total that supports .NET Core - you should note that Aspose.Total includes all Aspose products and some of them started to support .NET Core earlier some later. Aspose.Words for example support .NET Standard 2.0 starting from 17.12.0 version.
.NET Standard versions of Aspose products has some limitations. For example, Aspose.Words for .NET Standard does not support printing and saving to the client’s browser. Also, in case of using it in Linux environment it is required to install Linux Native assets for SkiaSharp. https://docs.aspose.com/display/wordsnet/Xamarin+and+.NET+Standard+2.0+Limitations+and+API+Differences
In addition to this Aspose.Words for .NET Standard 2.0 and .NET 4.6.1 supports reading PDF documents; this feature is not supported in earlier .NET framework versions.
Microsoft recommends to use .NET Core and then .NET 5 to develop new applications. So, I would recommend to follow their recommendations. Both .NET and .NET Standard versions of Aspose products use the common codebase (with minor differences). So both will give you the same set of core features.
Referring to Why use the full .NET Framework with ASP.NET Core?, it appears .NET 4.7.2 is the way to go forward?
Our existing application targets .NET 4.6.1 using ASP.NET Boilerplate.
Is it mandatory to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features?
To use .NET Core 2.1 features, you need to target .NET Core 2.1
There is .NET Standard, which is an intersection of features that are available in a range of implementations, including .NET Core and .NET Framework. If you target .NET Standard (some specific version), then you can use the features available in that version of .NET Standard, and it should run on either .NET Framework 4.7.2 or .NET Core 2.1.
As a general guide: libraries (such as Aspnet Boilerplate) should now - where possible - target .NET Standard, but will often have a multi-target build to allow them to internally exploit target-specific features of specific frameworks (perhaps using the enhanced "span" or SIMD capabilities in .NET Core).
Application code should (and must, if it is an executable) target a specific framework such as .NET Framework or .NET Core.
No, it is not necessary to migrate to .NET 4.7.* in order to leverage ASP.NET Core 2.1 features.
ASP.NET Core 2.x is made up of .NET Standard libraries. Apps written with .NET Standard 2.0 run anywhere that .NET Standard 2.0 is supported.
ASP.NET Core 2.x is supported on .NET Framework versions compatible with .NET Standard 2.0:
.NET Framework 4.7.1 and later is strongly recommended.
.NET Framework 4.6.1 and later.
You only need to migrate to .NET 4.7.2 if you need features in Announcing .NET Framework 4.7.2:
ASP.NET – Dependency Injection in WebForms
ASP.NET – SameSite Cookie
ClickOnce – Per-monitor support for WPF and HDPI-aware ClickOnce deployed apps
ClickOnce – Enable SHA256 timestamping of Deployment Manifests
SQL – Azure AD Universal and Multi-factor Authentication Support
BCL – Cryptographic Improvements
BCL – ZLib decompression support to DeflateStream
BCL – Additional Collection APIs
WorkflowDesigner High Contrast Improvements
WPF – Finding ResourceDictionaries by Source
WPF – Finding ResourceDictionary owners
WPF – Finding StaticResource references
References:
ASP.NET Core targeting .NET Framework
.NET Standard implementation support
For real, if you're building an application using .NET Core/Standard, but in your application, you may have some reference that using .NET Framework, it must be a big problem.
A story: I'm building a web application using ASP.NET Core, in this application, I want to have an extension that converting HTML to pdf.
I've tried to searched on Google and found a plugin that is called: itextsharp. And the problem comes from here.
itextsharp is using .NET Framework while my main project is using .NET Core. Since I want to create a class library to build this extension, I have 3 options:
Using .NET Core class library.
Using .NET Standard class library.
Using .NET Framwork class library.
All of them can be refered to the main project. BUT:
I cannot use itextsharp references (itextsharp.dll, itextsharp.xtra.dll, itextsharp.pdfa.dll, itextsharp.xmlworker.dll...) in .NET Core/Standard class libray. All of them can run only on target .NET Framework.
(I haven't mentioned about how to convert the code to target .NET Standard or Core because of license yet)
And my solution is: Build a .NET Framework app and publish it to exe file before appending to the main project as a reference.
P/S: For now, itextsharp has a Core version but I think it's not good enough (problems about: displaying images, fonts with unicode text, style tag...).
Totally, if you want to build some app that is using target .NET X, you must make sure all of the references can use target .NET X, too.
Another example: if you want to build a class library that using Razor class library. You must make sure that all of the references are using target .NET Core/Standard. Because Razor class library cannot refer to .NET Framework class library.
We've a server side "classic" WCF .NET application running on Windows. We added last year Linux support using Mono and a Web-Api replacement of WCF.
Checking the compatibility with the Api-Port tool, we found that the we would need much few changes targeting directly .NET Core instead of .NET Standard.
So for server side application like ours, that will be running only on Windows and Linux, is it correct to say that does not make any sense to target .NET Standard?
For server-side applications targeting .NET Core is enough.
There is a detailed answer here: What is the difference between .NET Core and .NET Standard Class Library project types?