MSBUILD/csc: sauberste Art der Behandlung x64 mscorlib Warnung 1607

Question

Ich versuche VS08SP1 Standard-Projektsystem zu verwenden, um eine C# kompilieren im expliziten x64-Modus (im Gegensatz zu AnyCpu). Wenn ich explizit ein Modul als x64 markieren, erhalte ich ein:

Warnung CS1607: Generation Assembly - referenzierte Assembly ‚mscorlib.dll‘ zielt auf einen anderen Prozessor

Eine Möglichkeit, zu entfernen, die mit a /nowarn:1607. Based on my research, gibt es in der Praxis keine Probleme damit. Wenn jemand ein reales Problem, auf das er gestoßen ist, hinterfragen kann, können Sie gerne antworten.

Allerdings fühlt sich das einfach falsch an! So ein anderer Ansatz, den ich verwendet wurde, war /nostdlib+, zu tun und dann eine <Reference> mit einem fest codierten <HintPath> auf die explizit 64 Bit mscorlib hinzufügen:

<Reference Include="mscorlib"> 
    <HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath> 
</Reference> 

Das funktioniert und ist wahrscheinlich besser (es sei denn, jemand kümmert sich Gründe, darauf hinzuweisen, warum die vorherige Ansatz ist besser), aber kann jemand bestätigen, dass dies eine angemessene Sache zu tun ist, hoffentlich zitiert etwas Authorative?

Answer 1

Ich habe gefunden, indem ich das Target-Framework meines Projekts in .NET Framework 4 änderte, löschte die Warnung.

Answer 2

Ich glaube, Ihre zweite Option (expliziter Verweis mit /nostdlib+) ist besser, weil diese Warnung nicht unterdrückt wird, wenn Sie auf andere Baugruppen verweisen, die nicht auf derselben Plattform erstellt wurden.

Answer 3

In this blog ich einen Vorschlag gefunden, die zu lang ist, es zu kopieren ganz hier vorbei, aber kurz gesagt kann die Idee mit Zusammenfassung von this comment angepasst beschrieben werden:

In der Projektdatei können Sie eine benutzerdefinierte Variable definieren im Abschnitt PropertyGroup für jede Build-Konfiguration. Beispiel:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'"> 
    <MyCustomPath>C:\Windows\Microsoft.NET\Framework64</MyCustomPath> 
</PropertyGroup> 

Fügen Sie einfach einen Tag wie

<Reference Include="System.Data"> 
    <HintPath>$(MyCustomPath)</HintPath> 
</Reference> 

und dann das Makro verwenden, um die Referenzstrecke festlegen. Sie können MyCustomPath an einem anderen Speicherort für verschiedene Buildkonfigurationen (Plattform und/oder Debug/Release) definieren.
Das Problem würde nicht existieren, wenn MS dies in der VS UI unterstützen würde, aber bis dahin wird dies funktionieren. Ich verwende diese Technik, um verschiedene Versionen derselben Assemblys in meinen Debug-Release-Builds & zu referenzieren. Funktioniert super!

In der obigen Rezitation habe ich das Tag wiedergefunden, das im Quellkommentarium verloren gegangen war und den Wortlaut geändert, um etwas detaillierter zu sein.

Ein weiteres interessantes Stück aus den same blog:

Es gibt einige andere Möglichkeiten, dies zu tun, aber sie erfordern auch eine manuell die Projektdateien zu bearbeiten.Eine Möglichkeit besteht darin, Bedingungen für PropertyGroup-Abschnitte anzugeben. Diese StackOverflow Frage unterstreicht die Verwendung von Bedingungen.

Answer 4

In meinem Fall hatte ich diese Warnung, weil ich eine Mischung aus x86 und x64-Projekten in meiner Lösung hatte. Wenn ich in allen meinen Projekten x86-Buildkonfigurationen erzeuge und diese für den Build anvisiere, verschwinden die Warnungen. Wenn ich jedoch x64 insgesamt anvisieren wollte, müsste ich das Projekt (oder den obigen Ratschlag) neu erstellen, um sie für das x64-Framework zu überarbeiten.