2014-04-30 10 views
6

Unsere Pakete nupkg enthalten mehrere Versionen derselben DLL (x86, x64, AnyCPU) und in den csproj-Dateien verwende ich bedingte Referenzen, um abhängig vom aktuellen Plattformsatz eine bestimmte DLL auszuwählen. Als Ergebnis habe ich mehrere Referenzen auf die gleiche Bibliothek (nur verschiedene Plattform-Kompilierung).NuGet Update und bedingte Referenzen

hier ist ein Fragment meiner csproj Datei:

<Reference Include="xxxx" Condition="'$(Platform)'=='x86'">    
    <HintPath>..\..\packages\xxxx.2.7.0.1093\lib\net45\x86\xxxx.dll</HintPath> 
</Reference> 
<Reference Include="xxxx" Condition="'$(Platform)'=='x64'"> 
    <HintPath>..\..\packages\xxxx.2.7.0.1093\lib\net45\x64\xxxx.dll</HintPath> 
</Reference> 
<Reference Include="xxxx" Condition="'$(Platform)'=='AnyCPU'"> 
    <HintPath>..\..\packages\xxxx.2.7.0.1093\lib\net45\AnyCPU\xxxx.dll</HintPath> 
</Reference> 

Diese Konstruktion funktioniert sehr gut in beiden MSBuild und in Visual Studio.

Leider nach Nuget Update die csproj Referenzen werden durcheinander gebracht. Hier ist das Ergebnis:

<Reference Include="xxxx" Condition="'$(Platform)'=='x86'"> 
    <HintPath>..\..\packages\xxxx.2.7.0.1093\lib\net45\x86\xxxx.dll</HintPath> 
</Reference> 
<Reference Include="xxxx" Condition="'$(Platform)'=='x64'"> 
    <HintPath>..\..\packages\xxxx.2.7.0.1093\lib\net45\x64\xxxx.dll</HintPath> 
</Reference> 
<Reference Include="xxxx"> 
    <HintPath>..\..\packages\xxxx.2.7.0.1094\lib\net45\x86\xxxx.dll</HintPath> 
</Reference> 

So wie sieht nur eine Referenz aktualisiert wurde und ... die Zustand Abschnitt fallen gelassen wurde, sowie die erste DLL auf der Liste verwendet wurde.

Nicht was ich erwartet hatte. Irgendwelche Ideen, wie man dieses Problem am besten umgehen kann? Jeder, der Bedingungsreferenzen in Ihren csprojs mit nugget verwendet? Jeder Rat würde sehr geschätzt werden!

+0

Nuget macht Voodoo zu den .csproj Referenzen. Das obige ist ein weiterer Grund, warum ich nugget-Pakete auf einer SOLUTION-Ebene hätte ... und versionslos sein wollen. Und lassen Sie mich die Versionierung mit den Build-Nummernbereichen steuern. Ich komme aus einer Java/Efeu-Welt, die es Ihnen erlaubt, binäre Abhängigkeiten auf Lösungsebene zu behandeln. Ich glaube nicht, dass Sie eine Lösung finden, aber hoffentlich irre ich mich und jemand wird hereinspielen. – granadaCoder

+0

Danke, ich fürchte, Sie haben recht und der Ansatz, den wir in Erwägung ziehen, ist, die csproj-Dateien selbst zu aktualisieren Teil des MSBuild-Ziels "nugget-update". Ich hatte gehofft, dass jemand einen besseren Weg kennen würde:/ Abhängigkeiten auf Lösungsebene machen Sinn, besonders in einer Situation, in der es eine schlechte Idee ist, zwei verschiedene Versionen derselben DLL in einer Anwendung zu beziehen. Mit Abhängigkeiten auf Projektebene ist es ziemlich einfach. –

+0

Ich "bekomme", dass Abhängigkeiten auf Projektebene entstehen können ... aber das Abhängigkeitsmanagement auf Lösungsebene scheint mir viel mehr Mainstream zu sein, und Abhängigkeiten auf Projektebene sind eher Randfälle. Ich bin mir nicht sicher, warum nugget das Boot vermisst hat ... aber ich bin auch nicht das schärfste Messer in der Schublade. – granadaCoder

Antwort

3

Mit Nuget können Sie eine .targets-Datei bereitstellen, die automatisch in Ihrem Projekt enthalten ist (siehe Nuget docs). Sie können die bedingten Verweise in die Datei für benutzerdefinierte Ziele aufnehmen und die DLLs im Ordner "tools" des Pakets bereitstellen, damit sie nicht automatisch von Nuget als Verweise hinzugefügt werden.

Nehmen wir an, Ihr Paket heißt "PackageWithConditionalReferences". Die Ordnerstruktur Ihres nuget Paket wird erstellt aus könnte wie folgt aussehen:

tools 
    lib\net45\x86\xxxx.dll 
    lib\net45\x64\xxxx.dll 
    lib\net45\AnyCPU\xxxx.dll 
build 
    PackageWithConditionalReferences.targets 

wo PackageWithConditionalReferences.targets Inhalt hat:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup>  
    <MyLibDir>$(MSBuildThisFileDirectory)..\tools\net45</MyLibDir> 
    </PropertyGroup> 

    <ItemGroup> 
    <Reference Include="xxxx", Condition="'$(Platform)' == 'x64'"> 
     <SpecificVersion>False</SpecificVersion> 
     <HintPath>$(MyLibDir)\x64\xxxx.dll</HintPath> 
     <Private>True</Private> 
    </Reference> 
    <Reference Include="xxxx", Condition="'$(Platform)' == 'x86'"> 
     <SpecificVersion>False</SpecificVersion> 
     <HintPath>$(MyLibDir)\x86\xxxx.dll</HintPath> 
     <Private>True</Private> 
    </Reference> 
    <Reference Include="xxxx", Condition="'$(Platform)' == 'AnyCPU'"> 
     <SpecificVersion>False</SpecificVersion> 
     <HintPath>$(MyLibDir)\AnyCPU\xxxx.dll</HintPath> 
     <Private>True</Private> 
    </Reference> 
    </ItemGroup> 

</Project> 

Stellen Sie sicher, Ihre .targets Datei mit dem Namen wird gern das Paket. Nach der Installation des Pakets ist ein Neustart von VisualStudio erforderlich, damit die Referenzen sichtbar werden (getestet mit VisualStudio 2015).