I will try to keep this general, as I am seeking a general answer.
When I open the properties window of one of the references in my project in Visual Studio I see this runtime version: v4.0.30319
This reference is used in a project where the target framework is .NET Framework 4.7.1. And it works fine.
My project is communicating with a database, and I want to make sure that this communication will be utilizing the TLS version 1.2 protocol. As I understand it, this can be insured by having the project targeted against .NET 4.7 or above.
Here is my question: if I have a project with a reference, which have a target framework that is lower than .NET 4.7, will this ruin my goal of using a TLS protocol of version 1.2?
How can I make sure that my reference is up to snuff? The runtime version written above, is not suggesting that this reference has a .NET Framework of 4.7 or above, or does it?
Related
My project is completely designed with. NetCore 2.2 and. Netstandards2.0. I need to refer
Microsoft.Xrm.SDK. But Microsoft.Xrm.SDK supported by full framework. I have tried to. NetCore 3.1 also no luck. I have gone through many articles, every one saying now only they start releasing the alpha version. There is only a roadmap so far.
As you already found, the .NET Core version is in Alpha release.
This is an update article to the right packages to use:
https://colinvermander.com/2020/02/13/net-core-cds-sdk-alpha-availability/
Regarding your project, you can eventually include all the calls to Dynamics 365 to a separate project/assembly so the rest of the project can be compatible with .NET Core and only that specific project/assembly to the full .NET
I have a .net Core 2.2 project. This is created using a Webapplication (Model View Controller) template. I can add my .Net Framework 4.7.1 projects into this core project, it compiles, run - and is deployed on my test servers.
1) Then I read about 2.2 End of Life, and I tried to migrate this to 3.1, and I cannot reference .Net Framework 4.7.1 in 3.1 framework. I don't know what is my next step here.
2)I read that I can convert my dll's to .Net Standard and reference - but, how can I do this?
3)These 4.7.1 dll's are shared by .Net Framework projects and core projects, so if I change this to .Net Standard - will my .Net Framework applications work?
4) Also - should I migrate my 2.2 Core projects to 3.0 because of the EOL? Is that mandatory? How will EOL affect audits if I don't migrate?
First, 2.2 is EOL, because 2.1 is the LTS release. You can downgrade to 2.1 if you don't want to jump to 3.x yet, and you'll still have a year or two of support there, I think.
However, 3.x takes the first step towards the new vision of one .NET (.NET 5 for all workflows), so the sooner you can get there, the better. 3.1, specifically, is the LTS release for 3.x, so stick there if you don't want to be forced to upgrade again for a while.
.NET Core 3.x implements .NET Standard 2.1, which is why you can no longer target .NET Framework with that (no version of .NET Framework implements .NET Standard 2.1 and never will). However, .NET Standard 2.0 is supported by both .NET Core (2.x and 3.x) and .NET Framework 4.6.1+. As a result, if you need to share a library between all these targets, you should target .NET Standard 2.0.
As far as converting your existing libraries go, you simply change the target framework to .NET Standard 2.0. That's literally it. Once you do that, some functionality in the library may fail (anything that requires .NET Framework, i.e. Windows-specific APIs). At that point, you either need to rewrite those parts of the library to use .NET Standard-compatible APIs, or use compiler directives to sub-in alternate implementations for .NET Standard 2.0/.NET Core, at which point, you'd have to multi-target the library (i.e. .NET Framework and .NET Standard 2.0 or even specifically .NET Core). When compiling, DLLs will be generated for each specific target, allowing you to seamless reference the same library from projects targeting any of the library targets.
If you're doing anything with ASP.NET Core components in your libraries, you should factor that code out into separate libraries and target .NET Core 3.1 directly there. There's no point in targeting .NET Standard 2.1, as that code will only ever be applicable to .NET Core, anyways. You should also work in the opposite direction. In other words, if there's anything that's only applicable to .NET Framework projects (Web Forms, etc.), then factor that out into separate libraries that will only target .NET Framework. That will allow you to migrate the remaining parts of the library more easily to .NET Standard 2.0.
I done created an application in .net framework 4.6.1 which works perfectly in localhost. But in the server(Windows server 2012), we have .net framework 4.5.
Should we upgrade it to framework 4.7 or will it work in the current framework?
It depends on whether you use any new features introduced in .NET 4.5.1 or later or not.
To ensure compatibility, you should either
upgrade your target system to (at least) 4.6.1 or
reduce the "Target Framework" setting of your project to (at most) 4.5:
Option 1 would ensure that all features that you use in development are available on the target system.
Option 2 would ensure that you get a compile-time error if you use features which are unavailable in .NET 4.5.
The .NET Framework 4.5 and later versions are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5 and later versions. However, by default, apps run on the version of the common language runtime for which they were developed, so you may have to provide a configuration file to enable your app to run on the .NET Framework 4.5 or later versions.
In practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques. For example, performance improvements in the .NET Framework 4.5 can expose a race condition that did not occur on earlier versions. Similarly, using a hard-coded path to .NET Framework assemblies, performing an equality comparison with a particular version of the .NET Framework, and getting the value of a private field by using reflection are not backward-compatible practices.
In addition, each version of the .NET Framework includes bug fixes and security-related changes that can affect the compatibility of some apps and components.
So i would suggest you to upgrade it to framework 4.7.
For more details please check:
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility
Entity Framework Core does not support spatial data, which I need to use in my app.
Can I use Entity Framework 6 in .net core? If so, how can I register DatabaseContext in Startup.cs?
Update
You can now use EF 6.3 with .NET Core 3.0:
https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
Below is an excerpt. However, EF Core has come a long way these days and it's worth giving it another go before going back to something that's reaching end-of-life soon. Specifically for your issue, EF Core supports mapping to spatial data types using the NetTopologySuite spatial library since version 2.2.
What’s new in EF 6.3
Support for .NET Core 3.0
The EntityFramework package now targets .NET Standard 2.1 in addition to .NET Framework 4.x.
This means that EF 6.3 is cross-platform and supported on other operating systems besides Windows, like Linux and macOS.
The migrations commands have been rewritten to execute out of process and work with SDK-style projects.
Support for SQL Server HierarchyId.
Improved compatibility with Roslyn and NuGet PackageReference.
Added ef6.exe utility for enabling, adding, scripting, and applying migrations from assemblies. This replaces migrate.exe.
There are certain limitations when using EF 6.3 in .NET Core. For example:
Data providers need to be also ported to .NET Core. We only ported the SQL Server provider, which is included in the EF 6.3 package.
Spatial support won’t be enabled with SQL Server because the spatial types aren’t enabled to work with .NET Core.
Note that this limitation applies to EF 6.3 but not to EF Core 3.0. The latter continues to support spatial using the NetTopologySuite
library.
There’s currently no support for using the EF designer directly on .NET Core or .NET Standard projects.
Original Answer
It isn’t ready yet, but starting with .NET Core 3.0, you will be able to.
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
Similarly, EF6 will be updated to work on .NET Core 3.0, to provide a simple path forward for existing applications using EF6.
https://youtu.be/GN54OV5cCBM?t=1146
But there's also EF6, which we've already announced is going to be ported to work on .NET Core...
UPDATE: Yes, EF6 has been cross-platform since version 6.3. https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
ORIGINAL ANSWER THAT IS NOW INVALID: No, you can not directly, because EF6 doesn't support .NET Core.
But, you can create another project, that compiles against full .NET framework and use it as a reference.
MS has actually made a decent tutorial for this:
https://learn.microsoft.com/en-us/aspnet/core/data/entity-framework-6#reference-full-framework-and-ef6-in-the-asp-net-core-project
UPDATE: Yes, EF6 has been cross-platform since version 6.3. https://devblogs.microsoft.com/dotnet/announcing-ef-core-3-0-and-ef-6-3-general-availability/#what-s-new-in-ef-6-3
ORIGINAL ANSWER THAT IS NOW INVALID: Like #Niko said, you cannot directly with EF6 but there is a fork that allows it.
Disclaimer: I'm the owner of the project Entity Framework Classic
Entity Framework Classic is an EF6 fork. It's everything you like about EF6, but with better performance, must-have features, .NET Core support, and more.
There is a FREE Community version that includes pretty much everything and an Enterprise version that include additional features.
We have recently taken on support of a web application that was written many years ago and targeted v1.1 of the .net framework. It runs on Windows Server 2003/IIS 6 environment.
After looking at the configuration of the site in IIS the target framework is set to 2.0.
Given that extended support for .net 1.1 will cease in October of this year (http://support.microsoft.com/lifecycle/?p1=1249) I am trying to ascertain whether the site will still use any of the .net 1.1 framework assemblies given that the application is built and compiled in Visual Studio 2003.
I am assuming this is the case because although ASP.net 2 is set as the target framework
in IIS (and therefore the aspet_isapi.dll invoked is the .net 2 one etc) the assembly is a .net 1.1 assembly and will therefore still use the 1.1 framework. However, is this assumption actually true?
The website only has another year or so to live before being replaced by a new solution entirely so I would prefer not to upgrade it if possible and run the risks such changes bring with them.
However, we obviously can't run something on an unsupported version of the framework if any element of if that framework is actually being used.
Any thoughts would be appreciated.
Update:
It would seem that .net 1.1 is a core component of WS2k3 so you can't just uninstall it. I could have attempted to remove the ASP.net component but I don't think that would fully uninstall everything and given that the dev environment is shared I can't risk causing any issues right now.
However I have previously set everything up on my local machine (Windows 7/IIS 7), so I changed the application pool to point at .net 2 (it was already running in classic pipeline mode), uninstalled .net frameworks 1 and 1.1 and cleaned up the files left behind afterwards.
The result was that the site ran absolutely fine, which would suggest in an IIS 7 environment at least that I don't need to worry about upgrading given we are running under .net 2 within IIS.
It's not an ideal test as it isn't a mimick of our live environment. I'm going to post a question on MSDN and asp.net to see if any Microsoft folks can add anything more definitive. I will post back here with any updates.
Just because official support will end doesn't mean Microsoft will pull the plug and force an uninstall of .NET 1.1 via Windows Update. It only means that:
if a gaping hole in the framework's security is ever found, they'll not fix it;
There won't be redistributables for the next versions of Windows, and the next version of IIS won't run it.
So the application will still run in a year. If you leave the server alone, the application might run until the machine breaks of old age.
So my suggestion is relax, and focus more on the new solution.
I got the answer to this questions after reading this link (provided as an answer to this question on the ASP.net forums)
http://msdn.microsoft.com/en-us/library/ms994381.aspx
Under "Application Load Mechanisms and Possible Issues" it states:
By default, an application built using the .NET Framework will run using the version of the Framework it was built against if that version is installed on the computer
It then goes on to detail (for .net 1.1 and 2.0 at least) when a particular version of the framework is used.
Essentially, because our server has both 1.1 and 2.0 installed the application will still be using version 1.1. If 1.1 was not installed then it would run by default under 2.0, which explains why the web application still worked after I uninstalled .net 1.0 and 1.1 from my local machine.
Given that the live server is W2K3 and I can't remove .net 1.1, I will be rebuilding my application to target .net 4.0.