.NET Core is the way forward for .NET! Model 4.eight of the .NET Framework is the final main model to be launched, and Microsoft has stated it’ll obtain solely bug-, reliability-, and security-related fixes going ahead. For purposes the place you wish to proceed to make the most of future investments and improvements within the .NET platform, it’s worthwhile to think about porting your purposes to .NET Core. Additionally, there are further causes to contemplate porting purposes to .NET Core comparable to benefiting from innovation in Linux and open supply, improved utility scaling and efficiency, and lowering licensing spend. Porting can, nonetheless, entail important handbook effort, a few of which is undifferentiated comparable to updating references to challenge dependencies.
When porting .NET Framework purposes, builders have to seek for suitable NuGet packages and replace these package deal references within the utility’s challenge recordsdata, which additionally must be up to date to the .NET Core challenge file format. Moreover, they should uncover substitute APIs since .NET Core comprises a subset of the APIs out there within the .NET Framework. As porting progresses, builders must wade by way of lengthy lists of compile errors and warnings to find out the perfect or highest precedence locations to proceed chipping away on the activity. Evidently, that is difficult, and the added friction could possibly be a deterrent for purchasers with giant portfolios of purposes.
Right now we introduced the Porting Assistant for .NET, a brand new instrument that helps prospects analyze and port their .NET Framework purposes to .NET Core working on Linux. The Porting Assistant for .NET assesses each the appliance supply code and the total tree of public API and NuGet package deal dependencies to determine these incompatible with .NET Core and guides builders to suitable replacements when out there. The suggestion engine for API and package deal replacements is designed to enhance over time because the assistant learns extra concerning the utilization patterns and frequency of lacking packages and APIs.
The Porting Assistant for .NET differs from different instruments in that it is ready to assess the total tree of package deal dependencies, not simply incompatible APIs. It additionally makes use of resolution recordsdata as the start line, which makes it simpler to evaluate monolithic options containing giant numbers of tasks, as an alternative of getting to research and mixture data on particular person binaries. These and different talents provides builders a bounce begin within the porting course of.
Analyzing and porting an utility
Getting began with porting purposes utilizing the Porting Assistant for .NET is straightforward, with simply a few conditions. First, I would like to put in the .NET Core 3.1 SDK. Secondly I would like a credential profile (suitable with the AWS Command Line Interface (CLI), though the CLI will not be used or required). The credential profile is used to gather compatibility data on the general public APIs and packages (from NuGet and core Microsoft packages) utilized in your utility and public NuGet packages that it references. With these conditions taken care of, I download and run the installer for the assistant.
With the assistant put in, I try my utility supply code and launch the Porting Assistant for .NET from the Begin menu. If I’ve beforehand assessed some options, I can view and open these from the Assessed options display screen, enabling me to select up the place I left off. Or I can choose Get began, as I’ll do right here, from the house web page to start assessing my utility’s resolution file.
I’m requested to pick the credential profile I wish to use, and right here I also can elect to opt-in to share my telemetry information. Sharing this information helps to additional enhance on suggestion accuracy for all customers as time goes on, and is helpful in figuring out points, so we hope you think about opting-in.
I click on Subsequent, browse to pick the answer file that I would like, after which click on Assess to start the evaluation. For this publish I’m going to make use of the open supply NopCommerce challenge.
When evaluation is full I’m proven the general outcomes – the variety of incompatible packages the appliance is determined by, APIs it makes use of which can be incompatible, and an general Portability rating. This rating is an estimation of the eﬀort required to port the appliance to .NET Core, based mostly on the variety of incompatible APIs it makes use of. If I’m engaged on porting a number of purposes I can use this to determine and prioritize the purposes I wish to begin on first.
Let’s dig into the evaluation overview to see what was found. Clicking on the answer identify takes me to a extra detailed dashboard and right here I can see the tasks that make up the appliance within the resolution file, and for every the numbers of incompatible package deal and API dependencies, together with the portability rating for every specific challenge. The present port standing of every challenge can also be listed, if I’ve already begun porting the appliance and have reopened the evaluation.
Notice that with no challenge chosen within the Initiatives tab the info proven within the Mission references, NuGet packages, APIs, and Supply recordsdata tabs is solution-wide, however I can scope the info if I want by first deciding on a challenge.
The Mission references tab reveals me a graphical view of the package deal dependencies and I can see the place nearly all of the dependencies are consumed, on this case the Npp.Core, Npp.Companies, and Npp.Internet.Framework tasks. This view may also help me determine the place I would wish to begin first, in order to get probably the most ‘bang for my buck’ once I start. I also can choose tasks to see the particular dependencies extra clearly.
The NuGet packages tab provides me a take a look at the suitable and incompatible dependencies, and instructed replacements if out there. The APIs tab lists the incompatible APIs, what package deal they’re in, and what number of occasions they’re referenced. Supply recordsdata lists the entire supply recordsdata making up the tasks within the utility, with a sign of what number of incompatible API calls may be present in every file. Deciding on a supply file opens a view displaying me the place the incompatible APIs are getting used and instructed package deal variations to improve to, in the event that they exist, to resolve the difficulty. If there isn’t a instructed substitute by merely updating to a distinct package deal model then I have to crack open a supply editor and replace the code to make use of a distinct API or method. Right here I’m trying on the report for DependencyRegistrar.cs, that exists within the Nop.Internet challenge, and makes use of the Autofac NuGet package deal.
Let’s begin porting the appliance, beginning with the Nop.Core challenge. First, I navigate again to the Initiatives tab, choose the challenge, after which click on Port challenge. Throughout porting the instrument will assist me replace challenge references to NuGet packages, and in addition updates the challenge recordsdata themselves to the newer .NET Core codecs. I’ve the choice of both making a replica of the appliance’s resolution file, challenge recordsdata, and supply recordsdata, or I can have the adjustments made in-place. Right here I’ve elected to make a replica.
Clicking Save copies the appliance supply code to the chosen location, and opens the Port tasks view the place I can set the brand new goal framework model (on this case netcoreapp3.1), and the checklist of NuGet dependencies for the challenge that I have to improve. For every incompatible package deal the Porting Assistant for .NET provides me an inventory of attainable model upgrades and for every model, I’m proven the variety of incompatible APIs that can both stay, or will moreover turn out to be incompatible. For the package deal I chosen right here there’s no distinction however for instances the place later variations probably improve the variety of incompatible APIs that I might then have to manually repair up within the supply code, this indication helps me to make a trade-off determination round whether or not to improve to the most recent variations of a package deal, or stick with an older one.
As soon as I choose a model, the Deprecated API calls subject alongside the package deal will give me a reminder of what I would like to repair up in a code editor. Clicking on the worth summarizes the deprecated calls.
I proceed with this course of for every package deal dependency and once I’m prepared, click on Port to have the references up to date. Utilizing my IDE, I can then go into the supply recordsdata and work on changing the incompatible API calls utilizing the Porting Assistant for .NET‘s supply file and deprecated API checklist views as a reference, and observe the same course of for the opposite tasks in my utility.
Bettering the suggestion engine
The suggestion engine behind the Porting Assistant for .NET is designed to be taught and provides improved outcomes over time, as prospects opt-in to sharing their telemetry. The information fashions behind the engine, that are the results of analyzing a whole lot of 1000’s of distinctive packages with thousands and thousands of package deal variations, can be found on GitHub. We hope that you simply’ll think about serving to enhance accuracy and completeness of the outcomes by contributing your information. The user guide provides extra particulars on how the info is used.
The Porting Assistant for .NET is free to make use of and is offered now.