.NET Portability Analyzer


    .NET Portability Analyzer это совсем не новое приложение, которое, по причине появления .NET Standard должно бы стать интересным для разработчиков. Портируемость кода ускоряет работу команд в разы. Если вам интересно узнать насколько переносим на другую платформу ваш код, то вы можете использовать .NET Portability Analyzer, который доступен в виде расширения для Visual Studio и в виде отдельного консольного приложения.

    .NET Portability Analyzer актуален для разработчиков .NET, .NET Core, UWP, Xamarin и Mono.
    Далее предлагаю вашему вниманию факты и описание процесса использования.

    Приложение было создано интерном Microsoft по имени Charles Lowell еще в 2014-ом году.
    Сейчас это open source проект, к которому подключены многие разработчики. Ссылка на репозиторий проекта: dotnet-apiport

    Консольное приложение


    Консольное приложение можно скачать по ссылке: releases
    Последний пре-релиз был 24 ноября 2015, но введя в консоли (cmd или PowerShell) команду

    ApiPort.exe listTargets

    Получим список вполне себе актуальных платформ. Консольное приложение фактически является оберткой, которая обращается к веб-сервису. Звездочка рядом с версией платформы указывает, что именно эта версия будет использована по умолчанию. Справка доступна при вызове приложения без параметров. Самая простая команда для анализа директории с проектом это:

    ApiPort.exe analyze -f ProjectFolder

    В этом случае директория ProjectFolder должна располагаться в той же папке, что и ApiPort.exe
    Вместо директории можно указать файл.



    По умолчанию анализ происходит относительно следующих платформ: .NET Core App, .NET Framework, .NET Standard. Можно указать конкретную платформу (или платформы через запятую):

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

    Результат сохраняется в файл формата xlsx. Формат Excel является форматом по умолчанию. Еще доступна выгрузка в формате HTML и JSON. С помощью параметров -r HTML и –r JSON соответственно.

    Альтернативно можно указать параметры, создав файл с наименованием unity.config и разместив его в той же папке, что и ApiPort. Содержимое файла задающего JSON в качестве формата отчета такое:

    <?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>
    

    После создания файла unity.config и запуска утилиты получим отчет уже в формате JSON.

    Если вы хотите запустить утилиту в режиме offline, то вам необходимо скачать или склонировать репозиторий dotnet-apiport. После чего построить проект с помощью build.cmd, который находится в корневой директории проекта (построение в Visual Studio не создаст для вас утилиту с актуальными библиотеками для автономной работы). После построения (которое длится несколько минут) в директории bin\release\ApiPort.Offline вы сможете найти файл ApiPort.exe – это будет версия для offline работы.

    В качестве анализа отчета давайте лучше рассмотрим формат Excel, как самый наглядный. Первая страница файла показывает сводку по совместимости namespace-ов в процентах. При этом на версии разбиения нет.



    Перейдя на вторую закладку в Excel, получим более полезные подробности. Вот, скажем, список неподдерживаемого в .NET Core и даже список рекомендаций (в данном случае не особо полезных – удалите, вот и вся рекомендация).



    На третьей закладке расположены сборки, на которые есть ссылки, но которые расположены где-то в недоступном месте. Например, в GAC.

    Расширение Visual Studio


    Расширение для Visual Studio имеет название .NET Portability Analyzer
    Оно было обновлено последний раз относительно недавно 05.09.2016. Кроме того оно гораздо более юзабильное чем консольное приложение. Если у вас есть исходный код проекта, то вам определенно лучше использовать расширение для VS.

    После установки расширения в Visual Studio необходимо произвести настройку интересующих вас платформ (targets). Сделать это можно, выбрав пункт .NET Portability Analyzer, в меню СервисПараметры.



    Есть 2 способа использовать это расширение:

    1. Из меню Analyze выбрать пункт Analyze Assembly Portability… В этом случае вы сможете выбрать ранее скомпилированный файл.

    2. Анализируется непосредственно проект. Правой кнопкой мыши вызывается контекстное меню на открытом в VS проекте, выбирается пункт Analyze и далее Analyze Assembly Portability… Но этот способ лучше первого тем, что в списке сообщений панели «Список ошибок» будут отображены все сообщения о несовместимости. И вы сможете, двойным кликом перейти к строке кода, в которой обнаружена несовместимость.



    На данном скриншоте отображены сообщения о том, что код await необходимо исправить. У Xamarin есть небольшое отличие о котором вы можете прочитать здесь: Async Support Overview

    Отчет будет выглядеть таким образом:



    Пара ссылок:
    » На MSDN есть перевод статьи: Кросс-платформенная .NET Framework
    » Кроме этого есть старенький англоязычный мануал, который все еще актуален: Leveraging existing code across .NET platforms
    • +24
    • 8,1k
    • 7
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 7
      +4
      всегда думал, что «портативный» — это небольшой, переносной, малогабаритный… то, о чём идёт речь в статье, наверное лучше называть портабельный… хоть и прямая калька с английского, но гораздо точнее смысл передаёт.
      Ну или переносимый, тоже вариант.
        +2
        «Переносимый» это называется по-русски
          0
          Портируемый, если быть точным
          0
          Я правильно понимаю, что PInvoke он анализировать не умеет?
            0
            А в каких случаях PInvoke будет переносимым?
              0
              Во-первых эта тулза показывает не обязательно .Net Core, но так же и переносимость между например 4.6 и 4.5.
              Во-вторых PInvoke будет переносимым когда импортируется своя либа, скомпилированная под разные таргеты. DllImport это ведь не обязательно вызов Win32-методов.
            0
            Ситуации на КДПВ не должно (было) произойти вообще: решение должно (было) быть принято при дропе поддержки версии 3.5.
            P.S. Зашел сюда только оставить этот комментарий.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.