Since some of our applications are written in .Net framework 2.0 & 4.5, We've plan to migrate our applications to .Net framework 4.8 and we have used MS enterprise library v3.0 & v5.0 and would like to uplift to enterprise library v6.0 Before going to migrate, need to know will the latest .Net framework 4.8 support enterprise library v6.0.
There is a port of Enterprise Library 6.0 that is supports .Net Core and .Net Standard 2.0.
I have not used that yet, so I cannot tell anything about its quality but based on the Nuget stats it seems tell that people are using these packages.
Also the original Microsoft Enterprise Library source code was published on GitHub so you could recompile the whole project using updated references, not sure how much effort would that cost.
Related
We currently have a production server running multiple .NET Core 2.1 websites and we need to deploy a website running .NET Core 5.0 on that same server.
I know I need to install dotnet-hosting-5.0.7-win.exe to be able to host the new site. Will installing that version of dotnet-hosting have any negative effects on the 2.1 sites?
I just want to make sure that running both versions is possible. Thank you.
Our company has multiple applications that are .Net Framework 4.8 and we also are growing the number of applications that are .Net Core 3.1.
We have written a whole library of NuGet packages (in a private repository) written in .Net STANDARD 2.0 that are currently consumed by both the 4.8 and Core 3.1 applications mentioned above.
Standard 2.1 offers many new language features, such as Nullables, and we want to start to migrating our NuGet packages over to Standard 2.1, but obviously need to continue to support those applications still on .Net 4.8 (which can't consume Standard 2.1).
Obviously we need to branch our source code, but what is the convention for publishing two almost identical NuGet packages, one written in 2.0 and the other 2.1?
NuGet supports multiple-target-frameworks for a package. Please refer to doc to learn more.
And if not, will it be? If so, when?
I haven't been able to find any clear official information on this, and the limited information I was able to find on Stack Overflow is a year or two old.
I was able to find official information saying EF 6.3 will be able to be used in a .NET Core project, but I couldn't find a release date for it, nor am I sure what the implications for use in a .NET Standard project are.
EF 6 supports .NET Standard 2.1, which is currently supported by .NET Core 3.0 or later - no .NET Framework version. EF 6 also supports .NET 4.0 and 4.5 or later.
https://github.com/aspnet/EntityFramework6/blob/release/6.4/src/EntityFramework/EntityFramework.csproj#L6
Some clarification, since EntityFramework 6.3.0 .NET Standard 2.1 has been supported. However there is no .NET Framework version that supports .NET Standard 2.1. Comment from Microsoft:
NET Framework won't support .NET Standard 2.1 or later versions. For
more details, see the announcement of .NET Standard 2.1.
This means that a majority of all applications using EntityFramework 6.X won't be able to use the .NET Standard 2.1 project anyway.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard
https://www.nuget.org/packages/EntityFramework/#
I have a NuGet package for a library that is currently implemented only for .NET 4. But I have ported library code to support various platforms (WinRT, SL5, WP8) so ideally I would like to package it as a portable class library (PCL) to simplify the maintenance. But the library is using LINQ to XML (XELements etc.) that requires targeting .NET 4.0.3 and installting .NET 4.0.3 on a client machine.
So I have a dilemma regarding how to target plain .NET 4. If it was not about NuGet packages and I had a control of the user base I could simply state as a prerequisite installing .NET 4.0.3 runtime. However, I don't want to limit the user base in any way, so it looks like I will have to have two versions of the library: portable that targets .NET 4.5, SL5 and WP8 and non-portable targeting just .NET4. What's silly is that both libraries will have exactly the same code since LINQ to XML is of course supported in .NET 4, it's just PCLs that don't have such support when targeting .NET 4.
My first question is whether this seems to be a right strategy? The alternative would be to take away all XElement-dependent code from PCL and have it in non-portable parts, but this does not seem right because the code will be exactly the same for all libraries.
The second question is whether it makes sense to target .NET 4.0.3 from a PCL at all: if I have separate version targeting .NET 4 will users that have .NET 4.0.3 runtime installed gain anything from getting a PCL rather than plain .NET 4 version? I know .NET 4.0.3 has other improvements but those don't affect my library.
Yes, I think the best thing is to create two versions of your library, one targeting .NET 4 and another portable library that targets the other platforms you support. Use source file linking so you don't have to have two different copies of your source code, just two different Visual Studio projects.
You only need one NuGet package though. Put the .NET 4 version in lib/net40 and the portable version in lib/portable-net403+win8+wp8+sl5 (or whatever combination of platforms you decide to support). Then NuGet will install the right one depending on what a project is targeting. NuGet 2.1 or higher is required for this to work for the portable version.
In reference to the question about .NET 4.0.3, it's about giving the consumers of your library flexibility. The people using your library are using it to create applications. Supporting .NET 4 may not be as important to them as it is to you. By supporting .NET 4.0.3 in the portable version of your library, it means that if they choose to require .NET 4.0.3 in their apps, then they will be able to use your library from their own portable libraries and more easily share their app code across platforms.
I am having a Web Application with build target as .Net Framework 4.0.
I want to interact with the Sharepoint Object Model API's but it gives a framework 4.0 runtime does not supports Sharepoint.dll error.
Is their any tweak such that I can use Sharepoint 2010 with .Net Framework4.0.
Note: I cannnot change the build target of the web app to any other framework as I am using some exclusive features of .net 4.0 in my application.
Sorry you probably will have no luck:
There appears to be some confusion
around whether or not ASP.NET 4 is
supported for both MOSS and SharePoint
2010 - in short, the answer is that it
is not currently supported in either
product.
Whilst it is possible to use ASP.NET
3.5 in MOSS by making some modifications to the SharePoint site
web.config (instructions for doing
that in MOSS here; SP2010 uses 3.5 by
default), this is unfortunately not
the case with version 4.
The reason? ASP.NET 4 uses a new
version of the Common Language Runtime
(CLR). Whilst .NET 2.0, 3.0 and 3.5
all used version 2.0 of the CLR, .NET
4 uses version 4. I'm not entirely
sure what happened to version 3. There
is a decent post on stack overflow
with further details.
from SharePoint 2010 and .NET 4: confused?
Maybe .NET 4.0 Support will be added in a future update (SP1?) who knows...
Unfortunately, .Net 2.0 to 3.5 use a different application pool type from .Net 4.0; Mixing in the same app pool is not going to work.
What features of .Net 4.0 are you using, and perhaps the community can help you with a 3.5 solution?