Let me start by mentioning the best thing about the new ASP.NET Core. – The new ASP.NET Core is independent of the Microsoft ecosystem.
This means it is now possible to develop ASP.NET applications on other platforms such as Linux and Mac.
Although this is not it, there are many new improvements to the new ASP.NET Core framework, which are listed below.
- ASP.NET Core provides support for more than 32,000 APIs.
- The new .NET Standard 2.0 released along with ASP.NET Core has added a new compatibility shim that allows any application developed using .NET Core to refer to any full framework library.
- ASP.NET Core offers better portability of codes to the new .NET Standard 2.0 library without requiring any major changes.
- Lastly, when .NET Core version 1.0 was released, it didn’t have logging libraries as log4net wasn’t available. However, it has been added now using which you can now easily deploy Mac or Linux applications.
After learning about all these improvements, I finally decided to move an existing ASP.NET application to ASP.NET Core.
Here are the lessons that I learned while doing so.
LESSON No. 1 – IIS is dead (kind of)
IIS isn’t really dead. You can still use it as a reverse proxy sitting in front of Kestrel to leverage IIS’s benefits that Kestrel does not have.
What is this Kestrel, though? – Kestrel is basically an essential part of the .NET Core framework that allows deploying any web app as easy as deploying a console app. In simple terms, all the self-hosted packages for web API, SignalR, and others are not needed anymore. Every web app developed using ASP.NET Core becomes self-hosted now.
A New Middleware replaces LESSON No. 2 – HttpHandlers & HttpModules.
The new middleware in ASP.NET Core has been designed to replace both handlers and modules. It is basically how Owin and other platforms handle this kind of functionality. In fact, Middleware is easier to work with. And, you will not be able to configure them in a config file either. With new Middleware, both are set in code. You can learn more about it in ASP.NET docs.
LESSON No. 3 – The StreamReader Constructor Does No Longer Work With a File Path
Actually, many simple uses of standard libraries have been changed. For example, in ASP.NET, the StreamReader was frequently used by passing in a file path, but in the new ASP.NET Core, you will have to pass it in a stream. As a result, it may require small refactorings to use a FileStream, in addition to StreamReader everywhere.
Another good example of a change in the use of standard libraries is the use of GetType(). The standard library now returns a better version of the object (more simplified) for better performance reasons.
LESSON No. 4 – Web API is Now a Part of MVC
Both Microsoft and the community have decided to merge Web API and MVC with the release of the new ASP.NET Core. The reason is that Both Web API and MVC follow the same pattern for controllers and actions. Secondly, the Web API did not have a view engine like a Razor and was designed to be useful for REST APIs.
MVC, on the other hand, was created for standard web application development with HTML front-ends. As you can see, merging Web API and MVC made sense in many ways. So they merged them.
LESSON No. 5 – Basic Classes Have Been Moved Around to Different Packages
While I do not know why some basic classes, such as FileStream, are no longer in the System.IO package, instead, you’ll have to add the package System.IO.FileSystem.
These changes in basic classes may be confusing, mainly because we generally use class namespaces that don’t directly match the packages. But to clear the confusion, I have found a website that shows where some classes have been moved around.
Final Thoughts
Microsoft has indeed made everything right with the release of ASP.NET Core. It is basically an interesting web framework to learn or build web applications to shoot MVPs quickly in the market.
Overall, this has been an interesting experience for me and my team and has helped us to Migrate and develop the ASP.NET Core application from scratch.
Article by