English Original:ASP.NET Core Drops Support for .NET
On Friday, ASP.NET Core quietly adjusted, from the original support for both. NET. Standard 1. and. NET 4. only to support. NET Core 2.0. This means that ASP.NET Core 1.0 / 1.1 applications running on Mono or the full version of the .NET Framework will not be able to upgrade to ASP.NET Core 2.0, a new version that is expected to be released in the next 2-3 months. As a result of such a significant change to the platform without open discussion or formal instructions,This angered a lot of heavyweight developersThe
Cross-framework support has been seen as an important feature of ASP.NET Core. The basic idea is that users can immediately switch to the ASP.NET Core while continuing to use their original service classes, code libraries, and third-party libraries. And then wait until the .NET Core grows to be consistent with the .NET Framework, and you can switch back at any time.
ASP.NET development manager Eilon Lipton explained the reasons behind this change:
Yes, for ASP.NET Core 2, most libraries are targeted primarily at .NET Core 2, which is intended to make use of the new APIs that are not available in .NET Standard TFM. For code that needs to target multiple platforms such as Microsoft.Extensions. *, Entity Framework Core, and other libraries, you need to continue using .NET Standard.
After asking why Microsoft did not directly develop .NET Standard 2.1 with the necessary APIs, K & eacute; vin Chalet continued to ask:
My question is very simple: before you RTM, whether you can re-adjust / revise these changes, allowing users to continue to use the ASP.NET Desktop 2.0 on the .NET Desktop, or .NET Core 2.0 on .NET Desktop Has been completely gone? (This is a very bad factor for many people, including me).
Although it is not intended to be used in full text, many developers have expressed similar concerns.
Scott Hanselman tries to appease the developer through his own main reason for continuing to use ASP.NET Core in the .NET Framework:
AD & ndash; To be honest, if you want to call LDAP directly, there is still a big problem in this area. Although it is still possible to authenticate with Windows Auth, we plan to provide a more specific DirectoryServices namespace for Core 2.0 this summer.
Drawing & ndash; this is also a problem. We plan to provide Core 2.0 with capabilities this summer, but before that, these Netstandard options are also widely available in ImageSharp, ImageResizer, Mono and other options.
COM automation & ndash; This feature has never been implemented in Core 2.0, if you want to worry, developers can certainly use PInvoke, if this trouble is not enough, but also for the net461 + process using the local WebAPI.
And WFP applications to achieve code sharing & ndash; yes, this is entirely feasible in Netstandard2.0.
Then Scott Hanselman reiterated that:
.NET Core is experiencing rapid parallel development, the development rate is far more than the full version of the .NET Framework, in fact, this is a good thing. By using .NET Core 2.0 (do not forget, this is a superset of .NET Standard) to build ASP.NET Core 2.0 applications, which means that you can use far NetFx or even Netstandard speed of development.
Although .NET Core 2.0 is a superset of .NET Standard, it is not a superset of the .NET Framework. K & eacute; vin Chalet wrote:
Many of the re-introduction of. NET Core 2.0 "ancient" and "API" are actually historical remnants, (from a functional point of view) has never been used normally. Not to mention the .NET Core is still a lot of API, and even deliberately omitted support for many areas (IdentityModel, WCF server, remote, full AppDomain support, etc.).
Trying to persuade everyone to "safely" and deploy their own ASP.NET Core 1.0 application developed by .NET Desktop to ASP.NET Core 2.0 applications developed using .NET Core, which in my opinion is a downright lie.
Turning to the pace of development of the technology, he added:
I think (most) people are not concerned about this. Many people do not need to develop such a fast library, they want to stabilize the library, according to their own rhythm will be integrated in the old application, without worrying about the risk of compatibility.
Including Allan Lindqvist, many developers are also worried that this may cause the community to produce rift.
Many really recognized Asp.NET Core 1.1 developers feel betrayed, they may now be reluctant to switch to Core version 2.0 without. This may seem unreasonable, but I would like to say that many people will have such a feeling, and they will have to deal with other more conservative colleagues raised the various questions.
Are these important? Asp.NET Core2 /. NET Core2 will therefore & ldquo; death & rdquo; Not, but will drag the user to accept the speed, so that the entire ecosystem fragmented, in my opinion this is the greatest sad. I hope that everyone can use the 2.0 version of all the excellent technology, but the cross-compiler capacity can only be used for. NET Standard will undoubtedly have an impact. Of course, this is not a problem for most regular developers who stick to the original code base, but only to pass the problem to their manager.
Another concern is that this decision is made in private, and there is no publicity or open discussion. Demis Bellot says:
Since the official did not publish the news or listen to the user feedback in advance, and did not make a solicitation or give a reasonable reason, the decision seems to be completely unrelated to the community, nor does it have an existing .NET. Of the image of any analysis, may lead to the entire ecosystem in the next few years become fragmented. Eliminating support for .NET v4.x means that many organizations can not migrate existing code to a new development model for ASP.NET in a sufficiently smooth way. This move can not allow them to speed up the acceptance of. NET Core, but will dispel their idea of doing so, serious fragmentation will further lead to the entire. NET ecology into two. I think the final result will be similar to the Python 2/3 situation, inevitably get fragmented damage, resulting in more than ten years are irreversible consequences.
Continuing to talk about library support issues, Gulbanana lists some of the features that he does, but .NET Core does not support:
We are Core CLR and portable ability of faithful "iron powder" ralph lauren pas cher, we have their own many components transplanted to a number of different Netstandard. At present we have hosted an application through Linux, it is expected that there will be more applications in the future to do so. But soon will be completely unable to transplant! At present we still keep some code in the maintenance of the following technologies:
NTLM authentication (including some advanced applications related to Token and SPN).
System.Drawing As mentioned above (there is an interesting story in this area: we need to use some of the old image formats, such as TIFF, and the new OSS library does not support it at all).
Connect to the WCF / SOAP API - still in use in our code.
Windows Crypto APIs (including RSACng, ECDSA, and CSPs for PKI tokens).
WPF GUI - Our customers will not upgrade to Windows 10 in the short term, but even if they are upgraded, they will not use the store application.
Microsoft Office Interop implements data import and export (mainly using Access and Excel).
Visual Studio's extensibility
Third-party plug-ins, such as Oracle ADO.NET providers
Core CLR may never support some of these technologies, but these technologies also have their own value, but also the basis of new application development work. We need a .NET version that supports these technologies. At present our position is still controllable: we will isolate the "reliance" and "rdquo;" (in fact, is dependent on the specific platform) dependencies, will be isolated in the net461 compliant proprietary components. If a business application relies on these features, you can set up dependencies for Netfx. Although I envisage later applications rarely need to do so, but I do not think you can completely avoid this practice.
This is all about csproj and the SDK because interoperability is really important. ASP.NET Core is the incentive for everyone to achieve interoperability, I think it is unreasonable to cancel this point. Of course, & ldquo; though can be a one-way load reference, but in the end is likely to run at the time of failure & rdquo; this approach is absolutely not interoperable.
Tim Miller further added:
OData and SignalR are also used in our current web applications, and ASP.NET Core must continue to be used before upgrading. However, what I would least like to encounter is that we are unable to migrate because the support for ASP.NET Core 1.x is weakened and we are caught in it because the framework components we are currently using are not supported. I think ASP.NET Core will eventually replace ASP.NET, perhaps the road is still very long, but eventually one day will be achieved. So I do not want to use ASP.NET MVC 5 to rewrite our UI now (a small amount of content has been rewritten, but mainly because of the small size, so the process is simple), and just a few years later when ASP.NET ends Use ASP.NET Core to rewrite again.
Another focus is on the Entity Framework. Although there are EF Core, but very few developers will use it instead of EF 6, because EF Core only supports the old version of some of the features. In fact, Reddit and other forums have a common view: ASP.NET Core should be used for new projects, but become more stable before, developers should avoid using. NET Core and EF Core.
For Louis Lewis, the biggest obstacle is the detection of hardware:
From your list, we are currently using but not yet transplanted system.management DLL. Specifically, we need to use hardware identifiers to automatically establish links between the Azure service bus and all of our license servers and client packages. I can not help but think that these things are no longer API, and whether we will cause some serious problems?
Christian Weiss added:
Of course, Azure Service Fabric library does not support. NET Core, for us this is also an obstacle.
In response to all these criticisms, Damian Edwards has announced a revised program.
Support for ASP.NET Core 1.x on the .NET Framework will be extended for at least a year (until July 2019). We will also consider this time frame again each year and will ensure that we will announce the 12 months before the end of ASP.NET Core 1.x support (that is, we will announce in July 2018 whether to continue for a year to 2020 July). (Digression: now consider the 2020 thing, no one was scared? No? Well, it seems only me).
The new release of SignalR will target ASP.NET Core 1.x and provide full support (released by the end of this year).
We will continue to update ASP.NET Core 1.x, in order to support the new language version or other features, this approach and System.Web processing is no different
ASP.NET Core 1.x running on .NET Core 1.x, whose support deadline is 2018 July (no change).
ASP.NET Core 1.x running on .NET Core 2+, with support for ASP.NET Core 1.x running on the .NET Framework. This is to ensure that the supported ASP.NET Core and the supported .NET Core are always overlapped with each other, and that they are running on the .NET Framework so that customers can migrate their code to supportable Technology.
.NET Core 1.x (as run-time) support will not change and will end in July 2018. Customers who use ASP.NET Core 1.x need to migrate to .NET Core 2.0 or the .NET Framework (or migrate to ASP.NET Core 2.0 running on .NET Core 2.0) before that.
This year we will be System.DirectoryServices and System.Drawing ported to. NET Core (full support, cross-platform, this summer at least provide Windows preview version).
After that, you will also have ServiceBase ported to .NET Core (for support for .NET Core Windows Services). There is no specific time schedule, but it has been determined that this is a follow-up to work (with the progress of the work, the schedule can no doubt be more accurate). We will also adjust follow-up work arrangements based on customer feedback.
At present we do not have the System.ServiceModel (server-side WCF) ported to the .NET Core program. But may further refine WCF for .NET Core and add new features based on user feedback, such as HTTP message encryption.
If you can publish this information earlier, perhaps everyone will complain less, David Fowler has mentioned the reasons Microsoft hopes to withdraw from the .NET Standard.
We have confirmed that the string will be used as the core goal of .NET Core to continue to improve, and we put forward a wide variety of ideas, one of which refers to the default use of UTF8 format string (compatibility issues there are many, and Listen to me one by one)
Another problem we intend to address is to be able to use any contiguous memory to create a lower cost array / string slice (Slice). We have added Span and are trying to implement the corresponding Buffer. This may mean that the new interface implemented by String and Array allows us to create slices that do not need to be allocated at all.
This provides a new method for String, which can be split without having to allocate an array every time.
But this will be the Int, UInt, etc. (TryParse) to accept Span and Span content burden.
This also produces a new coding routine that can accept Span.
Buffer and Span allow us to render the memory in a uniform way, and we want to upgrade the network stack to pass a Pre-pinned buffer that accepts Span or Buffer.
Kestrel will implement HTTP2 during the 2.x version (currently target version 2.1), which requires the need for a new API through SSL flowALPNThe
The HttpClient running on .NET Core supports Duplex streaming, which allows you to implement streaming endpoints with a non-WebScoket HTTP request via HTTP in HTTP.
We also pass HttpClient andSystem.NET.HttpCreating a branch for the implementation of the header parser and changing the name so that it can be improved to support both the .NET Framework and the .NET Core. .NET Core already contains these improved copies, but is not in use because it does not need to be improved (not used).
Many new primitives related to threads are neededNew API, Which can create a new application of the scene, but these are just my personal views.
While these reasons can appease some people, Stefan Olson also sums up the idea of most developers:
In my opinion, it seems that ASP.NET Core will run on .NET Core instead of .NET Standard? So what am I still wondering. Whether it was destined that day will be destined to eventually be abandoned?
I think the more reasonable approach is that ASP.NET Core needs to rely on. NET Standard 2.1, because the framework does not currently have some of the features users need. Then we can only wait for the full .NET Framework to support these additional features before you can use the latest version of ASP.NET Core. This is feasible and reasonable.
But they even abandoned the Standard, so that it does not play a role (I do not know the current situation of this confusion is correct).
At the moment, the .NET Standard is not so sad that it is still a good way to provide third-party libraries with both the .NET Framework and .NET Core capabilities.
The sense of frustration continues
Stack Overflow's Nick Craver demonstrates examples of the frustration that many teams may have. After spending a lot of time porting their code to the ASP.NET Core + .NET Framework, they felt that their efforts were done:
There are still gaps in the basic functions. The work of transplanting to 1.x is basically a side-by-side (Lateral) project that gives us very limited functionality. 2.x version to some extent it is worth the upgrade, but we can not guarantee that eventually will do so. There is a great deal that we spend a lot of time, cost and effort to transplant to the 1.x version of the effort will eventually ran aground, because then also need to rely on a complete Framework. I do not want my company to bet on luck in this respect. Ultimately we can get the support may be far less than the current use of ASP.NET 4.x.
Unless this can be changed, our application will not be ported to ASP.NET Core, and all of our libraries may face more trouble than the lack of internal testing.
I sincerely hope that you can reconsider this decision. Hopefully one day you can let Stack Overflow take full advantage of thousands of hours of personal time we contribute, helping the .NET Core platform to the next level.
Yes, the specific reasons I understand, I hope I can say "already guessed that there is such a day, but no prior notice to give up, it really makes people very uncomfortable.
And other manufacturers similar, we also have application of ecological, born in more than ten years ago or even earlier before the library, there are many MVC 3,4,5 applications, a console application, a Windows service, there are hundreds of thousands of lines of code The Compared to some other technology, the situation is completely bad to the point where it is necessary to upgrade.
Recently, we used ASP.NET Core 1.1 to develop several new Web applications, which is bound to a full 4.6.2 version of the Framework as the goal. These applications have used a lot of our existing shared libraries. We have used a lot of development work time to handle project.json, followed by the new .csproj, just to mix the old and new .csproj in the same solution, back to the VS15 will only use the old one. Csproj type, broken System.Dependencies, cumbersome assembly binding issues, build and publish problems, and so on.
And now we have to fly into a dead end. Whether to give up the development of several months, or put more time to find out which code is available and not available, and then try to upgrade, then we can know that this approach in the end is not feasible.
Can not say that I totally disagree with the current direction and necessity, but hope to inform you in advance.
The key to this series of comments is that Microsoft's changes have been "long time", but they are not open only. David Fowler says:
This is also the main reason why the lifecycle of version 1.1 ASP.NET Core is extended (though still going to end). We need to make sure that SignalR is working properly because that's why we chose to use ASP.NET Core 2.0. At the same time, in the final analysis, this is not the goal of ASP.NET Core, their purpose is always as a unified. NET Core platform, an integral part of the release to the user.
In response to Scott Sauber,
I am really witnessing the development of each version of ASP.NET (including Hanselman and Glenn on the Docker 3 hours of troubleshooting & hellip; because I am a technology house), I will read the blog, I always brush Twitter, I I will participate in various activities every year, but I have never seen anyone discuss this for ASP.NET Core's development plan. On the contrary, I only hear that everyone is saying that it can run across the platform, right, feeling like you want to sit down when someone moved the chair away. I have even done a speech about ASP.NET Core, and I've also said that it can run on each platform. "Now, I feel like I'm playing my face." I think that people like ITT who walk in the forefront of technology may be able to accept such news, and this will certainly lead to a lot of boycott. Feeling that when more can not quickly adapt to the developers and their managers, that is, more conservative than the ITT group of people heard the news, the situation may become worse.
Other concerns about the .NET Framework
This discussion also talked about the .NET Framework. David Fowler says:
Span itself has a portable version that can run on a variety of platforms, but I'm not sure whether the implementation on the .NET Framework is one of the fastest. These APIs are about to join the .NET Framework, they can take full advantage of Span, but may be slower than Span itself, after all, very large range. What was the last time we changed the string and the array in the .NET Framework?
The problem is not with Span itself, but on the impact of the .NET Framework, and whether it and other improvements related to .NET Core can be achieved. Matt Nischan says:
We have always thought that it would be possible to use a variety of novel libraries (such as Kestrel) wherever possible, but still have to wait for .NET Core to become more stable (it's nice that we are patient and the reason is that the tool itself ), Or wait for a cool Core version to eventually fit into the Framework. I think most people will assume that Corefx's improvements, if not all, are mostly mostly included in Framework vNext or vNext + 1, and that's the result is excellent. However, (from more than 30,000 page views) it seems that the various changes around the Framework can not shape a future-oriented platform.
Frans Bouma added:
Is it a good question: What about leaving .NET Core's functionality backwards to the full version of .NET? See here I found that the full version of .NET is really too fragile, the code of the transplant need to invest a lot of time (it is really too slow to improve), and may even be interrupted at any time (there is such a possibility, just do not know how difficult ), So I think that this situation should not happen often.
This may result in two consequences: or backward migration to the full version of .NET is feasible, but the release frequency is not so high (for example, every six months or every year); or the whole process is very complex and error-prone. If this is the case, just follow the pace, but this does not allow users to pay, and do not use the latter as an excuse. If the latter case, then that Netstandard is "heresy" is the most reasonable conclusion, after all, the most important future is the. NET Core API is not it?