49

クラス ライブラリを構築していて、それを NuGet パッケージとして展開します。これにより、追加先のプロジェクトの .NET Framework バージョンに基づいて、参照として追加するさまざまなアセンブリを選択できます。これは非常に優れた機能ですが、私が疑問に思っているのは、単一のクラス ライブラリ プロジェクトを作成して、.NET フレームワークの複数のバージョンに対してビルドできるかどうかということです。

私はむしろ避けたい：

MyLibrary40.dllとMyLibrary45.dll

可能であれば、2 つのプロジェクトで多くのコードを共有する必要があるためです。4.5 バージョンasyncでは、4.5 の機能である機能が提供されます。

これに対する最善のアプローチを知っている人はいますか？複数のビルド構成を使用できますか? それとも、別のプロジェクト ルートをたどる必要がありますか?

C++ で作業していた場合#if、1 つの構成でのみサポートされている関数の周りに複数の構成とブロックを使用する可能性がありますが、これにより、同じ名前で異なることを行う 2 つのアセンブリが作成されるのではないかと心配しています。

前もって感謝します！

4

4 に答える 4

17

.csproj簡単な方法は、同じフォルダーに別のファイルを追加し、別のフレームワーク バージョンをビルドするように構成することです。これにより、両方のプロジェクトが基本的に同じフォルダー構造のビューであるため、ファイルへのリンクを追加する必要がなくなります。

次の構造があるとします。

- MyLibrary\
  - MyLibrary.sln
  - MyLibrary\
    - MyLibrary.csproj
    - Program.cs

同じフォルダーに複製MyLibrary.csprojし、編集していくつか変更します。

  • <ProjectGuid>この要素の値の新しい GUID を作成するだけです
  • <TargetFrameworkVersion>ここで代替バージョンを指定します。例:v4.5またはv3.5
  • <OutputPath>(デバッグおよびリリースの場合) これを や などの一意のパスに設定してbin\Debug\net45、bin\Debug\net45各プロジェクトの出力が一意の場所に配置されるようにします。

また、並列ビルド中に<PropertyGroup>2 つのプロジェクトがフォルダー内で衝突しないように、無条件要素に新しい要素を追加する必要があります。objこれは重要であり、奇妙な競合状態のバグから保護します。

<PropertyGroup>
  <BaseIntermediateOutputPath>obj\net45\</BaseIntermediateOutputPath>

最後に、この新しいプロジェクトを既存のソリューションに追加します。

NET35このアプローチは、やなどのコンパイル スイッチの定義、および/ディレクティブNET45の使用と連携して機能します。#if NET35#endif

この手法を使用する 2 つのオープン ソース プロジェクトは、MetadataExtractorとNetMQです。困ったときに参考にできます。

于 2015-08-09T22:25:20.327 に答える
5

私が知っている古い質問であり、これは当時は適切な答えではありませんでした...しかし、共有プロジェクトを使用できるようになりました。これは、各ファイルを個別に追加するのではなく、プロジェクトをリンクとして追加することと論理的に同じです。

于 2015-09-08T14:26:41.653 に答える