Linuxの.NET標準

Question

私は珍しいスタックでいくつかの実験を行っています。私はの.NET標準,コアと通常の.NET Frameworkプロジェクトの混合である.NETソリューションを持っています。 VS、フレームワーク、ツーリングの両方が最新のものに更新されています。

私はUbuntuの上ドッカランナーでgitlabのCIを使用したいと思います。

私は、コア/ネット標準ライブラリ（xprojs）を導入する前に、私は

MONO_IOMAP=case xbuild /t:Build /p:Configuration="Release" /p:Platform="Any CPU" ./src/CoreLibrary/CoreLibrary.sln 

を実行することで、私のソリューションを構築することができましたが、それ以来、私はインポートすることができませんでした

を得続けるが"$（VSToolsPath）\ DotNet \ Microsoft.DotNet.Props"

私のすべてのxprojのエラー。私はdotnet restoreとdotnet buildでxprojsをビルドすることができますが、残りはxbuildでのみビルドできます。今では、エラーを避けるために、Linux上にxbuild以外のものを別々にビルドできるようにするための2つのソリューションがあります。これは私ができる最高のものですか？誰かが私にこれを正しく行う方法のヒントを教えてもらえますか？

のは、私は、ソリューション内の2つのプロジェクトを持っているとしましょう、物事を単純化するために

更新：.NETコアライブラリプロジェクトは、ターゲティングnetstandard1.4（xproj）と同じ古い.NETコンソールアプリケーションターゲティング.NET Framework 4.6.1（csproj）。コンソールアプリケーションは、netstandardライブラリに依存しています。

Visual Studioから、問題なくソリューションを構築できました。両方のプロジェクトが正しく構築されています。私のWindowsマシンからは、dotnet utility toolを使ってxprojsをビルド/実行することもできます。すべて正常に動作します。

私のubuntuベースのコンテナでは、モノはソリューションをビルドすることができません。上記のエラーが表示されます（そこにはVSがインストールされていません）。私は最初に正しく動作するdotnet utility toolを使用してxprojを構築し、xprojsを含まない別のソリューションファイルを持ち、コンソールアプリケーションのみを構築してxbuildでビルドすることができます。

私の主な関心事は（これは便利な解決策ではないという事実より）VSのバグが修正されて、現時点ではcscrojsの参照をプロジェクト参照として追加することが不可能になる場合です。私のcsprojプロジェクトは分離する必要があるので、それを使用することはできません。

Answer 1

.NETおよび.NETコアツールでは、既知の問題が混在して進行中です。 xprojは、project.jsonベースのプロジェクトのmsbuild-wrapperで、Visual Studioや他のプロジェクトタイプと連携して動作します。ターゲットはグローバルMSBuildの場所にインストールされ、Visual Studioの.NET Core Toolingインストーラーにのみ含まれます。

次のオプションがあります。DOTNETのCLIの

1. preview2/preview2.1のバージョンの.NET「完全」フレームワークのためのライブラリやコンソールアプリケーションを構築する方法を知っています。また、linuxとunix上のmonoについて知っていて、環境変数（DOTNET_REFERENCE_ASSEMBLIES_PATH）を持っていますので、xbuildの参照アセンブリが見つからない場合はどこにあるかを知ることができます。

   これは、フルフレームワークをターゲットにしたプロジェクトであっても、すべてのプロジェクトをproject.jsonベースにすることができることを意味します。 dependenciesセクションの解像度がproject.jsonの場合、project.jsonベースのプロジェクトは同じフォルダまたは指定されたプロジェクトの場所のglobal.jsonにあります。

   すべてのプロジェクトがライブラリとコンソールアプリケーションだけである限り、これはLinuxとMacですべてをビルドすることができます。ただし、dotnetツールはソリューションファイルについて認識していないため、プロジェクトごとに1つずつ、dotnet buildコールが複数必要になります。対照的に、dotnet restoreはフォルダ内のすべてのプロジェクトを検索し（またはglobal.json > projects afaikと解釈して）、すべて復元します。

2. 最新のmsbuildバージョンは.NETコアについて認識しており、.NETコアをターゲットとするcsprojをビルドできます。しかし、それはほとんど知られていない/使用され、おそらくすぐに現在の形式で消え去るcsprojとproject.jsonの混合物です。短いguide on how to make it work with visual studioしかありません。あなたはそれをフランケン - ビルドしようとする可能性がありますが、それはおそらくうまくいかないでしょう。

3. .NET Coreツールは、とにかくmsbuildに移行しています。これは、すべてのターゲット/プロパティファイルを持っている限り、.sln、.csproj、さらにはカスタムmsbuildプロジェクトを完全にサポートすることを意味します。 MSBuildターゲットは、すべてのC＃プロジェクトタイプのグローバルにインストールされたmsbuildターゲットを置き換えるNuGetパッケージ（​​）を介して配布されます。 dotnet sdkには、msbuildのxplatビルドが組み込まれています。このプロジェクトはNuGet経由でターゲット定義を提供します。現時点では、これらのターゲットは実際にモノでは動作しませんが、want to make it work with mono、または少なくともlinuxでフルフレームワーク用にビルドされています。

   .NETコアツーリングが成熟するまで少し待っていると、おそらくdotnet build your.slnになります。多分monoのxbuildも新しいmsbuildの変更を受け取ります。

4. 2段階のビルド：

   project.jsonを使用して、すべてのライブラリと.NETのコアアプリをビルドします。次に、すべてのライブラリをdotnet packを使用してNuGetパッケージとしてパッケージ化し、一時的な場所に配置します。 "古典的な" .NETプロジェクトは、NuGet経由でこれらのパッケージを参照し、NuGet.Configファイルまたは-s ../tmp-packages引数を使用してnugetに一時的なパスを追加ソースとして使用して復元できます。

   これにより、VSの両方のプロジェクトでコードを作成する可能性がなくなり、新しく追加されたメソッドが直接利用できるようになりますが、xbuildがサポートするすべてのタイプのプロジェクト（xamarin、web apps、...）を構築できます。