ライブラリ プロジェクトを NuGet パッケージに変換し、内部の NuGet フィードでホストしています。これはうまく機能しており、開発者がヘルパー クラスを再作成して「車輪の再発明」を行う必要がなくなりました。もう 1 つの大きなプラスは、他のチームが私たちのプロジェクトから「リリースされた」ライブラリを使用できるようになったことです。基本的に、これまでのところ大きな勝利です。
私たちが直面している唯一の問題は、ローカル ビルドです。私たちがやりたいことは、ビルドを NuGet フィードにプッシュする前に、使用するプロジェクトでライブラリをテストすることです。これらのライブラリを使用しているプロジェクトがローカル フィードを使用するようにセットアップされているため、問題が発生しています (ビルド サーバーでパッケージを復元すると、メイン トランクが最新の「リリースされた」ライブラリでビルドできるようになります)。
ローカル リポジトリからローカル ビルドを取得する方法はありますか? ローカル パッケージ ファイルを作成するライブラリのビルド後のタスクに取り組み始めました。NuGet.config を使用すると、特定のリポジトリをマスクしてから、ビルド サーバー上の構成ファイルをマスクできるはずです。私の理論では、ローカル ビルドを使用する場合はローカル リポジトリを取得し、ビルド サーバーではフィードを使用する必要があります。
これは可能ですか?これを行う方法を文書化した人は他にいますか?
ローカル パッケージの作成に使用しているビルド後のタスクは次のとおりです。
<PropertyGroup>
<PackOutputDir>$([System.IO.Path]::Combine($(SolutionDir), "..\Prerelease"))</PackOutputDir>
<BuildSpecCommand>$(NuGetCommand) spec $(ProjectFileName) -force -NonInteractive -Verbosity detailed</BuildSpecCommand>
<PackCommand>$(NuGetCommand) pack $(ProjectFileName) -OutputDirectory "$(PackOutputDir)"</PackCommand>
</PropertyGroup>
<Target Name="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<Exec Command="$(BuildSpecCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
<Exec Command="$(PackCommand)" LogStandardErrorAsError="true" Condition=" '$(OS)' == 'Windows_NT' " />
</Target>
この NuGet.config をチーム プロジェクトのルートに配置しました。このファイルはビルド サーバーでクロークされます。
<configuration>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="TestSource" value="Source\Prerelease" />
</packageSources>
<disabledPackageSources>
<add key="LocalNuGetFeed" value="LocalNuGetFeed" />
</disabledPackageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
ビルド サーバーの階層で取得する必要があるフォルダーに配置した NuGet.config を次に示します。
<configuration>
<packageSources>
<add key="NuGet official package source" value="https://nuget.org/api/v2/" />
<add key="LocalNuGetFeed" value="http://team2:12345/nuget" />
</packageSources>
<disabledPackageSources>
</disabledPackageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
更新 提供された回答に基づいて、nuget.targets ファイルを変更しました。理想的には、これはやりたくありませんが、これが私が達成したいことを達成するための最良の方法である場合は、このタイプの編集で問題ありません。
<ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' == 'Release'">
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="http://team2:12345/nuget/" />
</ItemGroup>
<ItemGroup Condition=" '$(PackageSources)' == '' And '$Configuration' != 'Release'">
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="C:\temp\NuGet\Prerelease" />
</ItemGroup>
ここでの考え方は、以前に投稿したライブラリ プロジェクトのビルド タスクを使用して、それらのパッケージがディスク上の一時フォルダーに出力されるようにすることです。すぐ上のコードは、開発者がローカル マシンで作業している間、すぐにライブラリの更新に変更を加える必要があるプロジェクトの nuget.targets ファイルにある必要がありますが、ビルド サーバーはローカル フィードとしか通信しません。チーム構築プロセス。
これは正しいです?
別のアイデア... 同僚とこれについて話し合った後、実際により効果的な別の解決策を思いつきました。AvalonDock プロジェクトでモデル化することにしました。ソースをダウンロードしてそのプロジェクトのソリューションを開くと、UI コントロールを構築するためのコードが表示されるだけでなく、そのコントロールのすべての機能を使用するサンプル プロジェクトも表示されます。
彼の考えは、コードが単なる C# ライブラリである私たちのライブラリ プロジェクトでは、単体テストがあらゆる問題をカバーするのに十分効果的であるべきだというものでした。また、これらのライブラリをプッシュするビルドはゲートされます。つまり、ビルド (およびテスト) が完了した場合にのみチェックインが適用されます。
UI コントロールについては、上記の AvalonDock の例を参照してください。すべてのコントロールを利用したプロジェクトを含めると、ほとんどの問題が軽減されます。UI コントロールの単体テストは制限されているため、コードをコミットしてビルド プロセスを開始する前に、テスト プロジェクト内のコントロールをチェックする責任は依然として開発者にあります。
このアプローチの一般的な意見は何ですか?