Some Lessons Learned while Converting from ASP.NET to .NET Core

Converting ASP.NET to .NET Core

We are doing many a lot of work on .NET Core at Samarpan Infotech since last some months. We are making sure that our app tools performance should be up to date. Its prefix and retrace can be used to.Net Core based applications. We have changed the whole code of prefix to the core for running this code on Mac.

Some information of converting ASP.Net MVC Development to .Net Core

  1. Using xproj and csproj files together: If your current setup with your build server is not working properly then it is better to use xproj and csproj files together at the same time. It will help to end up your Windows targeted builds of the prefix.

    It is not important that two project types may resemble each other then you have to move all to xproj but MSBuild will be of no use then after.

  2. NetStandard vs NetCoreApp1.0: The major difference between this two is that NetStandard is designed to set common standard to target to common standard in .Net 4.5, Core, UWP, Xamarin etc. Thus for making a shared library based on nugget package, NetStandard is the best option.

    On the other hand, if an actual application is being under planning then to target NetCoreApp 1.0 as the framework u should target .NET 4.5.1 OR Later versions. It can be deployed on Mac or Linux also. For targeting windows you can directly target too .Net 4.5.1.

  3. HttpModules and HttpHandlers are replaced by new “middleware”: For substituting the modules and handlers middleware has been introduced. These are same as Owin and other languages which handle this kind of functionality. For more information, you can go through ASP.NET. it is very easy in working. It has a drawback that it can’t be configured in the config file. It will be set of codes.
  4. FileStream moved to System.IO.FileSystem ? ? ?: Generally, classes were used earlier which now is being converted into different packages. FileStream is totally removed from the System.IO assembly package or reference. System.IO.FileSystem package is to be added in the system explicitly. It is somehow confusing as we are using the class namespace which did not match to the packages.
  5. Platform-specific code like Microsoft specific RSA: .NetCore is being introduced to run on an operating system like Windows, Mac, LINUX etc but it is not possible because sometimes the code which is compiling on windows will become failed at runtime when it is run on Mac or Linux. RSACryptoServiceProvider is an example of such case which is useful. On Mac “platform not supported” type exception will occur at runtime. This RSA provider API is just for Windows. In place of using RSA API’s, you can use RSA.Create() which is generic implementation and has different methods. This both are present in System.Security.Cryptography. it is slightly confusing.
  6. Newtonsoft changed to default to camel case on field names: It is the most difficult conversion among all. Newtonsoft now defaults to camelCase. If you are using PascalCase then it will cause to all sorts of REST APIs. Lastly, we use the JsonProperty attribute on some attributes to force their casing at the end which is our main motive.
  7. DataSet and DataTable doesn’t exist: DataSet and DataTable are still being used by some people. DataTables is being used to send a table to a SQL stored procedure as an input parameter.
  8. Creating a Windows Service in .NET Core: VisualStudio 2017 can create WindowsServices as your code targets to full .NET Framework. You have to convert yours .NET Core code to a class library which targets Net Standard which can be shared via other .NET Core app and your Windows Service.
Leave a Reply

Your email address will not be published. Required fields are marked *