.NET Portability Analyzer

The .NET Portability Analyzer is not a new application at all, which, due to the advent of .NET Standard, should be interesting for developers. Portability code speeds up the work of teams at times. If you are interested in knowing how much your code is portable to another platform, then you can use the .NET Portability Analyzer, which is available as an extension for Visual Studio and as a separate console application.



The .NET Portability Analyzer is relevant for .NET, .NET Core, UWP, Xamarin and Mono developers.

Further I bring to your attention the facts and description of the process of use.



The application was created by a Microsoft intern by the name of Charles Lowell back in the 2014th year.

Now it is an open source project to which many developers are connected. Link to the project repository: dotnet-apiport

Console application

The console application can be downloaded from the link: releases

The last pre-release was November 24, 2015, but typing in the console (cmd or PowerShell) command

')

ApiPort.exe listTargets 

We get a list of quite current platforms. The console application is actually a wrapper that accesses the web service. An asterisk next to the platform version indicates that this version will be used by default. Help is available when the application is invoked without parameters. The simplest command to analyze a project directory is:

 ApiPort.exe analyze -f ProjectFolder 

In this case, the ProjectFolder directory should be located in the same folder as ApiPort.exe

Instead of a directory, you can specify a file.







By default, the analysis occurs on the following platforms: .NET Core App, .NET Framework, .NET Standard. You can specify a specific platform (or platforms separated by commas):

 ApiPort.exe analyze -f ProjectFolder -t ".NET Core, Version 1.1" 

The result is saved to the xlsx file. Excel format is the default format. Another available download in HTML and JSON. Using the -r HTML and –r JSON parameters, respectively.



Alternatively, you can specify the parameters by creating a file named unity.config and placing it in the same folder as ApiPort. The contents of the file specifying the JSON as the report format is:

 <?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/> </configSections> <unity xmlns="http://schemas.microsoft.com/practices/2010/unity"> <typeAliases> <typeAlias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager, Microsoft.Practices.Unity" /> <typeAlias alias="IApiPortService" type="Microsoft.Fx.Portability.IApiPortService, Microsoft.Fx.Portability" /> <typeAlias alias="FileOutputApiPortService" type="ApiPort.FileOutputApiPortService, ApiPort" /> </typeAliases> <container> <register type="IApiPortService" mapTo="FileOutputApiPortService" > <lifetime type="singleton" /> </register> <instance name="DefaultOutputFormat" value="json" /> </container> </unity> </configuration> 

After creating the unity.config file and running the utility, we will get the report in JSON format.



If you want to run the utility in offline mode, then you need to download or clone the dotnet-apiport repository . After that, build a project using build.cmd , which is located in the project root directory (building in Visual Studio will not create a utility for you with actual libraries for offline work). After building (which lasts a few minutes) in the bin \ release \ ApiPort.Offline directory you can find the ApiPort.exe file - this will be the version for offline work.



As an analysis report, let's better consider the format of Excel, as the most obvious. The first page of the file shows a summary of the compatibility of namespaces in percent. In this case, there is no splitting on the version.







Turning to the second tab in Excel, we get more useful details. Here, for example, a list of unsupported in .NET Core and even a list of recommendations (in this case not very useful - delete, that's the whole recommendation).







The third tab contains the assemblies for which there are links, but which are located somewhere in an inaccessible place. For example, in the GAC.

Visual Studio Extension

The extension for Visual Studio is called .NET Portability Analyzer

It was last updated relatively recently 09/05/2016. In addition, it is much more usable than a console application. If you have the source code of the project, then you definitely should use the VS extension.



After installing the extension in Visual Studio, you need to configure the platforms that interest you (targets). This can be done by selecting the .NET Portability Analyzer, in the Tools - Options menu.







There are 2 ways to use this extension:



1. From the Analyze menu, select Analyze Assembly Portability ... In this case, you can select a previously compiled file.



2. The project is analyzed directly. Right-click the context menu on an open project in VS, select Analyze and then Analyze Assembly Portability ... But this method is better than the first one in that the list of messages in the Error List panel displays all incompatibility messages. And you can double click to go to the line of code in which an incompatibility is found.







This screenshot shows messages that the await code needs to be fixed. Xamarin has a slight difference about which you can read here: Async Support Overview



The report will look like this:







A couple of links:

"On MSDN there is a translation of the article: Cross-platform .NET Framework

"In addition, there is an old English-language manual, which is still relevant: Leveraging existing code across .NET platforms