1. ホーム
  2. 質問と答え
  3. VS 2017は.Netコアを含む混合ソリューションをどのように構築してテストするのですか

VS 2017は.Netコアを含む混合ソリューションをどのように構築してテストするのですか

2017-03-13 8 views
2

dotnet sdk 1.1とVisualにアップグレードした後、コマンドラインからテストするのに問題がある平均以上の複雑な（疑わしい）スタジオ2017.VS 2017は.Netコアを含む混合ソリューションをどのように構築してテストするのですか

これは、VS2015で動作していましたが、dotnet sdk 1.0.0-preview2-003131でビルドされ、VS 2015とbuildserverのコマンドラインの両方でビルドされて実行されます。

しかし、私は、セットアップの概要を説明するにはVS 2017に

をアップグレードした後、いくつかの問題が発生しました。 私は（現実の生活の中でより多くのプロジェクト）

MySolution.sln

  • FoundationClasses（x86の、.NET Frameworkの4.5、csproj（レガシー）
  • ビジネスロジック（x86のを大まかに以下のようにレイアウトされたソリューションを持っています、.NET Frameworkの4.5、csproj（legcay）
    • 参照・ファウンデーション・クラス
  • WEBAPI（DOTNET C鉱石WEBAPI、net451、x86の（ランタイム（win8-x86の、win10-x86の）
  • TestProject（DOTNETコア、net451、x86の）
    • 参照は、これがあったVS 2015年

をWEBAPI restore.dgとproject.fragment.lock.jsonをGitに保存して作業を行いました。その後、dotnet restoreを実行し、その後にdotnet buildとdotnet testを実行することができました。

VS 2017にアップグレードした後は、Visual Studioからビルドして実行するとすべて正常に動作します。 （マイグレーションは、基礎プロジェクトへの参照にいくつかの問題を抱えていましたが、それらを削除して、移行後に読み込み、すべて正常でした）。

'dotnet restore mySolution.sln'は問題ありません。これはWebApiとTestProjectのパッケージを正しくプレビュービットに反して正しく復元します。私は復元ファイルとフラグメントファイルを手伝っていました。

しかし、「dotnet build MySolution.sln -f net452 -r win10-x86」を実行すると、ビルドエラーが発生します。

「dotnet msbuild MySolution.sln -f net452 -r win10-x86」を実行すると動作します。

これは、アウトラインのようなソリューションでCLIツールから構築する正しい方法ですか？

ビルドとリストアでは、CLIとVS 2017の両方で動作させることができます。同じ結果が得られます。

しかし、テストのために、整合性が停止します。

Visual Studioのテストエクスプローラでテストを実行できます。 Unittestsは正常に動作し、緑色です。しかし、Microsoft.Extensions.DependencyInjection.Abstractions 1.0.0と1.1.0の参照の不一致で、TestServerの起動が失敗する統合テストが行​​われました。

したがって、テストチェーンの中にはアセンブリの1.0.0が必要ですが、1.1のみです。デバッグディレクトリに0があります。

これはアセンブリのリダイレクトによって解決できますが、かなりの数のアセンブリが間違っているかミスマッチしているようです。

私が 'dotnet test --no-build TestProject/TestProject.csproj'を実行すると、テストはすべて緑色で問題はありません。

だから、優れた質問：

  • 混合溶液を構築するための正しい方法 'DOTNETのMSBuildの' か？
  • 私はそれがコンパイルに失敗し--no-構築せずに「DOTNETテスト」を実行した場合 - 私のテストに基づいて矛盾は何ですか
    • （MSBuildのではない）「DOTNETのビルド」のようなエラーで - どのように私は実行することができますVSと同じで、VSと同じです（VS2017で1.0.0の範囲でアセンブリが必要なものが望ましい）。

私は完全に説明することができたが

シナリオを理解するために詳細が必要な場合は、私にお知らせください。

よろしく アンダース

出典

2017-03-13 ankhansen

答えて

6

[OK]を、いくつかのハード思考の後に/掘り時間は私は適切な解決策を見つけたと思います。

ここに参考にしてください。

DOTNETのCLIの問題への相互参照：https://github.com/dotnet/cli/issues/6032

私は純4.5に構築し、既存のレガシー・ソリューションを持っている、x86の、のは

oldsolution.slnそれを呼びましょう、私はいくつかを含む新しいソリューションを持っていますoldsolution.sln、およびいくつかの新しいdotnetコアプロジェクトから、という名前のプロジェクトをmySolution.slnと呼ぶことができます。

新しいソリューションはまた、ビルの.Net 4.5

のためのx86に構築する必要があります

ここに把握するために重要なことは、Visual Studio 2017を構築するには、インストールフォルダ内のMSBuild.exeを使用していることです。 dotnet msbuildは、dotnet sdkフォルダのアセンブリを使用します。そしてこれらは同一ではありません。

Visual Studioのようにビルドするには、使用する適切なmsbuild実行可能ファイルを見つける必要があります。

Visual Studioチームは、ビルドスクリプトで使用するツール（https://www.nuget.org/packages/vswhere）を開発しました。

そして、その中ですべてが機能します。 （賢明なビルド）

私のPSakeスクリプトは、ソリューションをビルドしてテストするためのものです。

Task BuildApi { 
    exec { msbuild ./oldSolution.sln /t:Rebuild /p:Configuration="Release" /p:Platform=x86 /m /verbosity:minimal /nr:false } 

    exec { dotnet restore .\mySolution.sln } 

    #Find location of VS2017 
    $VsPath = .\packages\vswhere.1.0.50\tools\vswhere.exe -latest -property installationPath 
    $msBuild17 = "$vsPath\MSBuild\15.0\Bin\MSBuild.exe" 

    exec { &$msbuild17 ./mySolution.sln /t:Build /p:Configuration=Release /p:Platform=x86 /m /verbosity:minimal /nr:false } 
} 

Task TestApi -depends BuildApi{ 
    if(!(Test-Path TestResults)) 
    { 
    mkdir TestResults 
    } 
    if(!(Test-Path TestResults/coverage)) 
    { 
    mkdir TestResults/coverage 
    } 

    $coverage = './packages/OpenCover.4.6.519/tools/OpenCover.Console.exe' 
    $target = "`"C:\Program Files (x86)\dotnet\dotnet.exe`"" 
    $filter = "`"+[WebApi]*`"" 

    #UnitTests 
    $targetargs = "`"test --no-build .\WebApi\test\WebApi.UnitTests\WebApi.UnitTests.csproj -c Release --logger `"trx;LogFileName=UnitTests.trx`"`"" 
    $output = 'TestResults/coverage/WebApi.UnitTests.Coverage.xml' 
    &$coverage -register:user -oldstyle -target:$target -targetargs:$targetargs -output:$output -filter:$filter 

    # IntegrationTests 
    $targetargs = "`"test --no-build .\Web\test\WebApi.IntegrationTests\WebApi.IntegrationTests.csproj c Release --logger `"trx;LogFileName=IntegrationTests.trx`"`"" 
    $output = 'TestResults/coverage/WebApi.IntegrationTests.Coverage.xml' 
    &$coverage -register:user -oldstyle -target:$target -targetargs:$targetargs -output:$output -filter:$filter 

    #Generate HTML report 
    $reportGenerator = "./packages/ReportGenerator.2.4.5.0/tools/ReportGenerator.exe" 
    $reportFiles = "TestResults/coverage/WebApi.UnitTests.Coverage.xml;TestResults/coverage/WebApi.IntegrationTests.Coverage.xml" 
    $targetDir = "./TestResults/coverage/WebApi" 
    &$reportGenerator -reports:$reportFiles -targetdir:$targetDir 
}

これまでのところとても良いです。

テスト

は、それから私は、カバレッジ結果をピックアップしてトラブルをOpenCoverなっていました。 xUnitのシャドウコピーがないことが判明

- このために修正が各テストプロジェクト（https://xunit.github.io/docs/configuring-with-json.html）シャドウコピーをしないのxUnitを告げる

{ 
    "shadowCopy": false 
}

でxunit.runner.jsonを配置することであり、したがって、OpenCoverすることができますテスト対象の実行ファイルと一致するPDBファイルを探します。 「何かが」のV 1.0.0バージョンを参照するためのVisual Studio内からテストを実行する最後

...

は、Microsoft.AspNetCore.TestHost.TestServerを使用してDOTNETコア・アセンブリの一部を参照するすべてのテストに失敗しましたアセンブリ - そして私のプロジェクトはv 1.1.xを参照しています。

私は、すべての失敗しているアセンブリのapp.configファイルでアセンブリのリダイレクトを行うことでこれを解決しました。古い1.0.0アセンブリを誰が使用したのか分かりませんでしたが、VS2017ビルドチェーンの何かがそのように思えました。ドットネットテストで動作しました。

ここでは、私の統合テストプロジェクトにリダイレクトされたapp.configのコピーがあります。

<?xml version="1.0" encoding="utf-8"?> 

<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">" 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.Extensions.DependencyInjection.Abstractions" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Mvc.Core" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.2.0" newVersion="1.1.2.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.Extensions.Options" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Http.Abstractions" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.StaticFiles" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.Extensions.FileProviders.Abstractions" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.Extensions.Primitives" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.0.0" newVersion="1.1.0.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Routing" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Routing.Abstractions" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Mvc.Formatters.Json" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.2.0" newVersion="1.1.2.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="Microsoft.AspNetCore.Mvc.ApiExplorer" culture="neutral" publicKeyToken="adb9793829ddae60" /> 
     <bindingRedirect oldVersion="0.0.0.0-1.1.2.0" newVersion="1.1.2.0" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
</configuration>

Phew ...それは荒々しい戦いでした。

しかし、それは価値があります。

新品の.Net Core Web Apiソリューションワークを実行している従来のx86、ネット4,5アセンブリと組み合わせたソリューション - そして私は満足しています。:-)

出典

2017-03-14 14:03:29 ankhansen

関連する問題

 関連する問題