Zbuduj dla .NET 4 i .NET 4.5 - co z odwołanymi pakietami NuGet?

Question

Mam skrypt, który buduje projekt, wyprowadzając zespoły .NET 4.0.

Projekt obejmuje NLog z NuGet. Więc odniesienie w pliku projektu wygląda następująco:

<Reference Include="NLog"> 
    <HintPath>..\packages\NLog.2.0.1.2\lib\NLog\net40\NLog.dll</HintPath> 
</Reference> 

A moja packages.config wygląda następująco:

<packages> 
    <package id="NLog" version="2.0.1.2" targetFramework="net40" /> 
</packages> 

Projekt ten ma być opublikowany na Nuget, a teraz chcę zaktualizować skrypt budujący, więc buduje także zestawy .NET 4.5.

Teraz wiem, że mogę przekazać /p:TargetFrameworkVersion="4.5" do msbuild i mieć go docelowego .NET 4.5 - ale nadal będzie budować againt z .NET 4.0 NLog montażu.

Jak mogę ją skompilować przy użyciu poprawnej wersji zależności NuGet dla docelowej struktury?

Answer 1

To samo wymaganie pojawiło się jakiś czas temu i nie znalazłem "czystego" rozwiązania NuGet. I wątpię, czy tak jest. Wydawało się, że jedyną opcją jest utrzymywanie różnych plików projektu (lub ich części) - zdecydowanie nie do przejścia dla masowych baz kodów.

To, co zrobiłem, było po prostu celem 4.5 we wszystkich projektach i ma raczej prosty skrypt msbuild, który tworzy kopie projektów i ich konfigurację NuGet do celowania w inne wersje .Net. Zasadniczo po prostu wylicza wszystkie pliki .csproj, szuka/zamienia z ciągów net45 ->net40 i zapisuje je pod inną nazwą. Idem dla plików config/targets/solution pakietu.

Oto prawie pełna cel MSBuild:

<Target Name="MakeNet40Projects"> 
    <ItemGroup> 
    <SourceProjs Include="$(MyProjectDir)*\*\*.csproj" Exclude="$(MyProjectDir)\*\*\*.Net40.csproj"/> 
     ... 
    <SourceConfigs Include="$(MyProjectDir)*\*\packages.config"/> 
     ... 
    <DestProjs Include="%(SourceProjs.RootDir)%(SourceProjs.Directory)%(SourceProjs.FileName).Net40.csproj"/> 
    <DestConfigs Include="%(SourceConfigs.RootDir)%(SourceConfigs.Directory)%(SourceConfigs.FileName).Net40.config"/> 
    </ItemGroup> 
    <PropertyGroup> 
    <OldPackages>packages.config</OldPackages> 
    <NewPackages>packages.Net40.config</NewPackages> 
    <OldTargets>NuGet.targets</OldTargets> 
    <NewTargets>NuGet.Net40.targets</NewTargets> 
    <OldProj>\.csproj</OldProj> 
    <NewProj>.Net40.csproj</NewProj> 
    </PropertyGroup> 

    <Copy SourceFiles="@(SourceProjs)" DestinationFiles="@(DestProjs)"/> 
    <FileUpdate Files="@(DestProjs)" Regex="[Nn][Ee][Tt]45" ReplacementText="net40" Encoding="utf-8"/> 
    <FileUpdate Files="@(DestProjs)" Regex="$(OldPackages)" ReplacementText="$(NewPackages)" Encoding="utf-8"/> 
    <FileUpdate Files="@(DestProjs)" Regex="$(OldTargets)" ReplacementText="$(NewTargets)" Encoding="utf-8"/> 
    <FileUpdate Files="@(DestProjs)" Regex="$(OldProj)" ReplacementText="$(NewProj)" Encoding="utf-8"/> 

    <Copy SourceFiles="@(SourceConfigs)" DestinationFiles="@(DestConfigs)"/> 
    <FileUpdate Files="@(DestConfigs)" Regex="[Nn][Ee][Tt]45" ReplacementText="net40" Encoding="utf-8"/> 

    <Copy SourceFiles="$(MsBuildThisFileDirectory)\.nuget\$(OldTargets)" DestinationFiles="$(MsBuildThisFileDirectory)\.nuget\$(NewTargets)"/> 
    <FileUpdate Files="$(MsBuildThisFileDirectory)\.nuget\$(NewTargets)" Regex="$(OldPackages)" ReplacementText="$(NewPackages)" Encoding="utf-8"/> 

    <Copy SourceFiles="$(MsBuildThisFileDirectory)\my.sln" DestinationFiles="$(MsBuildThisFileDirectory)\my.Net40.sln"/> 
    <FileUpdate Files="$(MsBuildThisFileDirectory)\my.Net40.sln" Regex="$(OldProj)" ReplacementText="$(NewProj)" Encoding="utf-8"/> 
    <FileUpdate Files="$(MsBuildThisFileDirectory)\my.Net40.sln" Regex="NuGet\.targets" ReplacementText="$(NewTargets)" Encoding="utf-8"/> 
</Target> 

Po uruchomieniu tego istnieje .Net40.csproj dla każdego projektu, .Net40.sln, a Nuget.Net40.targets dla rozwiązania i paczek. Pliki Net40.config, wszystkie gotowe do zbudowania. Jak dotąd, tak dobrze.

Mały problem jednak: packages.config jest zakodowany jako ciąg w Nuget.exe, więc nie przyjmuje packages.net40.config w jego linii poleceń. Częścią tego "algorytmu" jest decydowanie, czy ścieżka przekazana do algorytmu -install jest rzeczywistą konfiguracją pakietu, czy też identyfikatorem pakietu. Lol. I raised a question on this, ale bez odpowiedzi. W każdym razie nie planowałem pozwolić, aby to zepsuło zabawę, więc zrobiłem jednoliniową korektę w źródle, aby zaakceptować wszystko, co kończy się na .config, zbudowałem i teraz używam tego Nuget.exe.