For .NET Framework, there is this question, but was answered twelve years ago and might be no more relevant in the age of .NET Core.
Did anything change in the exception mechanics of .NET Core? Are exceptions in .NET Core as slow as in .NET Framework?
Related
We currently have a web api targeting .NET 4 framework which is hosted within IIS using an application pool which is using .NET 4 CLR.
We are investigating migrating the web api from .NET 4 to .NET Core 2.1 (for performance improvements). The web api has other DLL references which have been built using .NET 4 framework. I have a simple proof of concept up and running using .NET Core 2.1 and the references which had been built using .NET 4 framework appear to have imported fine as I can reference them and the project builds.
If I have the new .NET Core 2.1 web api referencing the 3rd party DLLs using .NET framework 4 which is then going to be hosted in IIS using the CLR 4... how would we see any performance increase? If everything is being run using the CLR 4, is that not the bottleneck for performance? Or is it the binaries that the CLR reads being more performant where you will see better performance?
Any guidance would be greatly appreciated as I'm very confused at the moment!
Thanks
It depends on how you're handling things. .NET Core 2.0+ fully supports .NET Standard 2.0, which has an API footprint large enough to cover most .NET Framework functionality. As a result, the compiler will let you add a .NET Framework library reference to a project that's actually targeting .NET Core 2.0+. There's no guarantee that the library will actually work (and you get a warning to that effect), but unless it's using Windows-specific APIs, there's a very good chance it will function fine.
Assuming this is the case with your .NET Framework libraries and you're actually targeting something like .NET Core 2.1, then you are not in fact using .NET Framework, and you don't even need .NET Framework installed on the server you're deploying to. All the requisite framework dependencies will come from the .NET Core runtime, or can even be packaged along with your app if you opt for a self-contained deployment. In that case, once compiled, it's virtually inconsequential that the libraries you referenced actually targeted .NET Framework.
If however the libraries do not work without full .NET Framework, you can still build a .NET Core app, but you'll be forced to continue to target .NET Framework, rather than .NET Core. In that case, you will of course be reliant on the .NET Framework CLR, with the performance drain that entails. That said, an ASP.NET Core app, for example, is still generally more performant than something like an ASP.NET MVC app, so you will get some gains - just not as much as if you were actually targeting .NET Core.
Regardless of what you ultimately end up targeting, your app is actually served via Kestrel. IIS acts merely as a reverse proxy.
I am mostly interested in the unified Web API in MVC 6 for building restful services. However I am a bit confused at the moment on how these components fit together. When building a new app with the latest Visual Studio 2015, MVC 6 is available as an ASP.NET 5 template. My understanding is that ASP.NET 5 is now ASP.NET Core 1.0. What does this mean for MVC 6 and how will it be supported in the future? Will it be part of the ASP.NET Core 1.0, ASP.NET 4.6 or both?
Could someone please explain how these components fit together? Thanks!
ASP.NET Core is the unification of MVC and WebApi.
It can run on the .NET Core framework or on the .NET full desktop framework.
The MVC design pattern is still there but there is less reason to call it "MVC" when talking about it. In the old days we talked about "MVC" to distinguish it from other things like WebForms or WebPages, but ASP.NET Core doesn't have those other things so calling it "MVC" is not really necessary. It was earlier called "MVC 6" but that was before everything got renamed to ASP.NET Core.
You can find a good explanation here: ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0
In few words:
ASP.NET 4.6 is the newest version of the ASP.NET we have known so far. This version is available right now.
ASP.NET 5 was going to be the name of something that wasn't a newer version of the ASP.NET we've used so far. SO Microsoft decided to rename it as ASP.NET Core
MVC 6 was the name of the MVC included in ASP.NET 5, so this name no longer make sense
One of the characteristics of ASP.NET Core is that, as you're asking, the MVC and Web API controllers are unified (which aren't on ASP.NET 4.6). But another very interesting thing is that ASP.NET Core runs on OSX, Linux and Windows, and there are available tools to develop thiskind of projects on these 3 platforms.
ASP.NET Core runs on .NET Core (previously named .NET 5), which is a "reduced" version of the .NET CLR that runs on OSX, Linux and Windows.
ASP.NET Core is already incomplete: it doesn't include SignalR or Web Pages so far, but it expected in the future.
Does ASP.Net Core 1.0 support .Net WebForm projects? Or it is an MVC only environment? Also can I create classic web services(asmx) there?
Short answer: No, ASP.NET Core does not contain Web Forms or Web Services.
Long answer:
Depends on your meaning of "support". If you aim to run ASP.NET Core project on top of CoreCLR and CoreFX, then the answer is no: ASP.NET Core will contain support only for MVC ja Web API -projects (which are the same thing in ASP.NET Core).
If you can run on full .NET Framework, then ASP.NET Web Forms can co-exist with ASP.NET Core. The Web Forms will be the same Web Forms they are today on System.Web. In this scenario you would host your web forms in a different project (normal ASP.NET 4.x application) on IIS and ASP.NET Core would live in it's own application on Kestrel.
A need to use .NET technologies not available for .NET Core
Some .NET Framework technologies are not available in .NET Core. Some of them will be available in later .NET Core releases, but others don’t apply to the new application patterns targeted by .NET Core and may never be available. The following list shows the most common technologies not found in .NET Core 1.0:
ASP.NET Web Forms applications: ASP.NET Web Forms is only available on the .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Currently there are no plans to bring ASP.NET Web Forms to .NET Core.
ASP.NET Web Pages applications: ASP.NET Web Pages are not included in ASP.NET Core 1.0, although it is planned to be included in a future release as explained in the .NET Core roadmap.
ASP.NET SignalR server/client implementation. At .NET Core 1.0 release timeframe (June 2016), ASP.NET SignalR is not available for ASP.NET Core (neither client or server), although it is planned to be included in a future release as explained in the .NET Core roadmap. Preview state is available at the Server-side and Client Library GitHub repositories.
WCF services implementation. Even when there’s a WCF-Client library to consume WCF services from .NET Core, as of June 2016, WCF server implementation is only available on the .NET Framework. This scenario is not part of the current plan for .NET Core but it’s being considered for the future.
Workflow related services: Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service) and WCF Data Services (formerly known as “ADO.NET Data Services”) are only available on the .NET Framework and there are no plans to bring them to .NET Core.
Language support: Visual Basic and F# don’t currently have tooling support .NET Core, but both will be supported in Visual Studio 2017 and later versions of Visual Studio.
source Choosing between .net Core and .net Framework
Officially, it's supported. I get that. I've personally done it in a VM. My question is, are there any hidden gotchas of running VS2012.x side by side with VS2010 SP'd and hotfix'd? I recall reading about an issue with the version of .NET or the CLR, I don't recall the details and it was last fall.
My coworkers and I would really like to move to 2012 but we have a lead developer that refuses to move. We need to convince him, especially since we have a large project that was started on 3.5, moved to 4.0 (will not go to 4.5), but we've heard rumblings about the aforementioned possible problem.
.NET Framework 4.5 is an in-place update. This means that once you install it all apps (including VS 2010) will be running against .NET Framework 4.5 and not .NET Framework 4. While there has been a great effort to make .NET Framework 4.5 backwards compatible there are some (mostly minor) bugs where the behavior changed in .NET Framework 4.
I think the biggest thing you should consider is whether you are going to target .NET Framework 4 in your apps. The problem is that when you target .NET Framework 4 your VS2012 will only allow you to use APIs that as they were in .NET Framework 4 but your app will actually run using .NET Framework 4.5 runtime. I have seen cases where a legitimate bug in .NET Framework 4.5 was fixed (i.e. an incorrect exception is no longer thrown) but when you run your app against real .NET Framework 4 the app did not work even though it targeted .NET Framework 4 because the bug is still there. Note that you can get to the same situation even with VS 2010 if you install .NET Framework 4.5 on your box. I have been running both SxS and I have not had any problems (but am primarily using VS2012 - is so much faster and more stable).
I think the main take aways here are
if you are working on .NET Framework 4 make sure you test your app on real .NET Framework 4
try running VS2012 sxs with VS2010 on a limited set of machines and if you don't see any problem move on
you may also try running VS2012 only if you don't use any functionality that is not supported in VS2012 (the biggest risk in this case is the .NET Framework anyway and running VS2010 only will not protect you anyways)
Is it worth spending time in these frameworks. Or they just another framework like microsoft developed in the form of MFC library.
I dont want to waste precious time, so please help. Under what scenarios these frameworks will be helpful.
EF and L2S are Object-Relational Mappers (ORM). They would be used wherever an ORM is used. StackOverflow uses Linq to SQL as its ORM layer, to good effect. Entity Framework is up-and-coming, and although it currently has issues, it will be greatly improved in the upcoming version 4.0.
Your time would be well spent learning one or both of these frameworks, as it will be highly likely you will use an ORM in your applications at some point.
It really depends on what your alternative is. If your alternative is using ADO.NET and DataSets, then yes, LinqToSql and EntityFramework are likely a step forward. If your alternative is NHibernate or another feature rich ORM, then they may be a step backward.
Microsoft has really strongly moved away from LinqToSql while still continuing to offer support for it and making minor changes. Microsoft is recommending all LinqToSql users move to Entity Framework. However, the Entity Framework that came out with VS 2008 SP1 / .NET 3.5 SP1 was in many ways a step back from LinqToSql. The Entity Framework that is coming out in April with VS 2010 and .NET 4.0 should be mostly an upgrade from LinqToSql, assuming you can migrate to VS 2010 / .NET 4.0 sometime in the near future.
YES! It is worth Learning. No! its not just another framework. It is useful for any application that uses a SQL Database to query data and present/do some logic.
Linq2Sql was introduced with .NET 3.5. Very useful if you dont have your own set of domain entities. A bit difficult to map Linq2Sql classes to our own domain entity classes in complexed scenarios.
But, recommend to use Entity Framework. EF was introduced with .NET 3.5 SP1. Much improved version of Linq2Sql and came as part of Olso Mixed Models. This can be used as a real ORM to map our own set of domain entities and the designer provides most of the features.
There is a new version of EF (EF4) ships with .NET 4.0.
Watch Evolving ADO.NET Entity Framework in .NET 4 and Beyond for what you can do with EF4.
Download the "Layered Architecture Sample for .NET" from Codeplex.com