So konfigurieren Sie eine VS2012-Lösung für x86 und x64 gleichzeitig
Wir haben ein VS2012 .NET 4-Produkt mit zwei verschiedenen SKUs A und B, die wir derzeit nur für x86 entwickeln.
Wir haben auch die üblichen Konfigurationen Debug und Release , was bedeutet, dass wir momentan 4 Konfigurationen haben.
- DebugA
- DebugB
- ReleaseA
- FreigabeB
Beim Betrachten einer der .csproj-Dateien sieht es ungefähr so aus
%Vor%Offensichtlich würde das Hinzufügen von x64 das von vier auf acht verschiedene Kombinationen verdoppeln, und VS scheint AnyPCU-Plattformkonfigurationen hinzuzufügen, wann immer es sich anfühlt. Wenn man sicherstellt, dass alle 8 in 30+ Projekten richtig konfiguriert sind, muss in VS viel herumgeklickt werden, und es ist wirklich leicht, Fehler zu machen.
Ich habe ein paar weitere SO-Fragen gelesen, in denen das Problem des Multi-Targeting gelöst ist, und einen der Vorschläge, verschiedene Referencen für verschiedene Plattformen einzubeziehen, die $ {Platform} im Reference-Pfad verwenden. Ich dachte, ich könnte etwas Ähnliches für meine Projektkonfiguration machen, also habe ich das versucht, wenn ich versuchte, Multi-Plattform zu machen:
%Vor%Was soll ich theoretisch für alle 8 verschiedenen Kombinationen mit nur zwei Blöcken bekommen? Aber wenn ich jetzt in VS schaue, kann ich weder xeithr x86 noch x64 als verfügbare Build-Plattformen für das Projekt sehen. Es sieht so aus, als ob die einzige Weise, in der VS die Build-Plattformen speichert, darin besteht, sie als die verrückten Bedingungen für die Eigenschaftsgruppen zu kodieren? Sag es nicht so ...
Gibt es keine Möglichkeit, eine "schön" aussehende Multi-Plattform .csproj zu erstellen, die gut mit VS funktioniert?
Könnte ich die .csprojs erstellen und dann entscheiden, sie NICHT in VS zu bearbeiten, in der Hoffnung, dass msbuild die richtigen Plattformen verwendet, obwohl VS keine Plattformen in den Eigenschaftenfenstern der einzelnen Projekte anzeigen kann?
Bearbeiten:
Es scheint, dass die Frage ein wenig verwirrend war: Um klar zu sein, möchte ich wissen, wie man die Konfiguration von Projekten und die Build-Konfiguration meiner Lösung einrichtet, beibehält und überblickt, wenn es viele Projekte und acht Kombinationen gibt Konfiguration | Plattform. Ich weiß, wie man das manuell macht, aber nicht ohne meinen Verstand zu verlieren oder einen Fehler auf einer der über 200 Eigenschaftenseiten zu machen.
3 Antworten
Wenn es Ihnen nichts ausmacht, die Projektdateien einmal manuell zu ändern, können Sie die gesamte freigegebene Konfiguration in eine Konfigurationsdatei einfügen und diese von jedem Projekt aus referenzieren. Dazu müssen Sie zunächst Ihre Konfigurationsdatei erstellen. Diese Datei ist nur eine normale MsBuild-Datei mit allen Informationen, die Sie für alle Projekte freigeben möchten (wie die Build-Konfigurationen). Die Datei wird ungefähr so aussehen:
%Vor%- Das erste
PropertyGroupdefiniert die Gesamtkonstanten, d. h. Konstanten, die von allen Projekten für alle Buildkonfigurationen verwendet werden. Wie Sie fürOutputPathsehen können, können Sie Build-Variablen wie$(Platform)und$(Configuration)verwenden, um den Speicherort der Binärdateien usw. zu bestimmen. - Das erste
PropertyGrouphat auch eine Reihe von Einstellungen, die normalerweise von Visual Studio definiert werden, z. %Code%. Technisch gesehen müssen Sie diese nicht verschieben, aber wenn Sie sie verschieben, reduziert sich die Unordnung in Ihren Projektdateien, sollten Sie sich darum kümmern. - Die folgenden Abschnitte definieren die verschiedenen Einstellungen für die verschiedenen Build-Konfigurationen.
Wenn Sie die Konfigurationsdatei definiert haben, sagen wir sie ProductVersion , dann müssen Sie Ihre Projektdateien bearbeiten. Leider müssen Sie alle Projektdateien durchgehen, aber Sie müssen dies nur einmal tun. Nachdem Sie die Konfigurationsdatei verknüpft haben, können Sie von nun an alle freigegebenen Konfigurationen ändern, indem Sie die Konfigurationsdatei ändern.
Eine normale Projektdatei sieht ungefähr so aus:
%Vor%Um die Konfigurationsdatei zu verknüpfen, müssen Sie:
- Entfernen Sie von den ersten
BaseConfigurations.targetsdie bereits in Ihrer Konfigurationsdatei definierten
-
Fügen Sie die Zeile
%Vor%PropertyGrouphinzu. Dies ist nicht erforderlich, wenn Sie nur aus Visual Studio erstellen (da Visual Studio automatisch die Variable<SolutionDir Condition="'$(SolutionDir)' == '' or '$(SolutionDir)' == '*undefined*'">$(MSBuildProjectDirectory)\..</SolutionDir>definiert), aber es ist erforderlich, wenn Sie Ihr Projekt auch über MsBuild erstellen möchten. Diese Zeile setzt auch voraus, dass sich jedes Projekt in seinem eigenen Unterverzeichnis befindet und dass die Lösungsdatei ein Verzeichnis oberhalb jeder Projektdatei ist, d. H. Ihre Struktur ist ungefähr wie folgt: -
Fügen Sie unterhalb der ersten
SolutionDirdie folgende ZeilePropertyGrouphinzu. Dies zeigt MsBuild (und damit Visual Studio) an, dass Sie die Konfigurationsdatei importieren möchten. - Entfernen Sie die Build-Konfigurationen
- Am Ende der Datei entfernen Sie die Zeile
<Import Project="$(SolutionDir)\BaseConfiguration.targets" />. Dies ist in Ihrer Konfigurationsdatei definiert und wird somit nicht mehr benötigt.
Nach all dem sollte Ihre Projektdatei ungefähr wie folgt aussehen:
%Vor%Anmerkungen:
- Wenn Sie diesem Ansatz folgen, sollte Visual Studio alle verschiedenen Buildkonfigurationen erkennen und Ihnen die Auswahl des richtigen Builds ermöglichen. Beachten Sie, dass Sie möglicherweise den Konfigurationsmanager für die Lösung aufrufen müssen, um Projekte aus einer bestimmten Lösungskonfiguration ein- oder auszuschließen.
- Wenn Sie diesem Ansatz folgen, können Sie keine der global definierten Eigenschaften über die Eigenschaftenseite eines Projekts ändern. Sie müssen die Änderung in der Konfigurationsdatei vornehmen, die dann in den Eigenschaften für jedes einzelne Projekt widergespiegelt wird.
- Wenn Sie Visual Studio 2010 oder früher verwenden, müssen Sie, wenn Sie Änderungen an der Konfigurationsdatei vornehmen, die Lösung neu laden (sofern sie geöffnet ist), da Visual Studio 2010 keine Änderungen erkennt, die Dateien enthalten. Visual Studio 2012 sollte in der Lage sein, Änderungen in Include-Dateien zu erkennen.
Sie möchten einen Stapel erstellen, in dem Sie die verschiedenen Builds auswählen können, die Sie ausführen möchten.
Sie können dies einer Tastenkombination mit Extras - & gt; Optionen - & gt; Tastatur suchen Sie dann nach Build.BatchBuild
Meiner Meinung nach ist es unklug, Plattformen und SKUs in Ihren Konfigurationsnamen zu kombinieren. In Ihrem Fall empfehle ich, nur mit Debug- und Release-Projektkonfigurationen zu arbeiten. Ihre Lösung sollte ein Projekt für SKU A und ein separates Projekt für SKU B (gemeinsame Nutzung gemeinsamer Dateien) enthalten. Jedes Projekt kann dann zusätzlich zu seinen zwei Build-Konfigurationen auf x86- und x64-Plattformen abzielen. Sie können dann so viele Lösungskonfigurationen hinzufügen, wie Sie verwalten möchten, ohne dass die einzelnen Projektkonfigurationen komplexer werden.
Tags und Links c# visual-studio msbuild