Standardmäßige und benutzerdefinierte Toolsetkonfigurationen

Aktualisiert: November 2007

MSBuild 3.5 umfasst zwei vordefinierte Toolsets. Toolsets stellen einen Satz mit Aufgaben, Zielen und Befehlszeilentools dar, die Sie zum Erstellen eines Projekts verwenden können. Sie können außerdem eigene, benutzerdefinierte Toolsets erstellen.

Hinweis:

Es wird empfohlen, dass Sie Festlegen einer bestimmten .NET Framework-Version als Ziel mit MSBuild lesen, um ein besseres Verständnis von Toolsets, Zielframeworks und Toolsversionen zu erlangen, bevor Sie fortfahren.

Typen von Toolsets

Beim Definieren eines benutzerdefinierten Toolsets wird der Wert des Verzeichnisses, auf das $(MSBuildToolsPath) verweist, ebenfalls definiert. Sie können $(MSBuildToolsPath) daher in einer Projektdatei zum Importieren von Aufgaben und Zielen verwenden, anstatt die Aufgaben- und Zielwerte in der Projektdatei hart codieren zu müssen. Auf diese Weise können Sie Toolsets entweder in der Registrierung oder in einer Konfigurationsdatei global definieren, damit Sie Builds auf Entwicklerdesktops oder in Build-Laborszenarien erstellen können.

Durch die Verwendung von Toolsets können Sie MSBuild anweisen, bestimmte .NET Framework-Versionen als Ziel zu verwenden. Dies bedeutet, dass Sie ein Projekt erstellen können, das nur mit Visual Studio 2008 verwendet werden kann, und dass Sie Visual Studio 2005-Projekte auch in Visual Studio 2008 erstellen können.

Visual Studio 2008 umfasst zwei "standardmäßige" Toolsets. Für ein Toolset, das bereits in MSBuild 2.0 in Visual Studio 2005 enthalten war, ist .NET Framework 2.0 als Ziel festgelegt. Für das andere Toolset, das in MSBuild 3.5 enthalten ist, kann .NET Framework 2.0, .NET Framework 3.0 und .NET Framework 3.5 als Ziel festgelegt werden.

Standard-Toolsetkonfigurationen

MSBuild 3.5 umfasst die folgenden Standardtoolsets:

ToolsVersion

MSBuildToolsPath oder MSBuildBinPath

2.0

<Windows-Installationspfad>\Microsoft.Net\Framework\v2.0.50727\

3.5

<Windows-Installationspfad>\Microsoft.NET\Framework\v3.5.20223\

Die Standardtoolsets sind überall auf dem Computer verfügbar, wenn Sie MSBuild.exe ausführen oder eine Instanz des MSBuild-Moduls erstellen, es sei denn, die Informationen im Toolset werden in der MSBuild.exe.config-Datei oder einer hostspezifischen Konfigurationsdatei überschrieben.

Der ToolsVersion-Wert, der als Attribut im Projekttag der Projektdatei angegeben ist, legt fest, welches Toolset von einem mit Visual Studio generierten Projekt verwendet wird. Die Toolsversion ist sozusagen der "Name" eines Toolsets. Wenn keine Toolsversion im Projekt angegeben ist, wird eine standardmäßige Toolsversion verwendet. Für MSBuild 3.5 ist der Standard-Toolsversionswert auf 2.0 festgelegt. Dies bedeutet, dass Projekte, die ohne eine bestimmte Toolsversion erstellt werden, das 2.0-Toolset verwenden, das in Visual Studio 2005 enthalten ist. Visual Studio 2008-Projekte erstellen alle Projekte automatisch mit dem Toolsversionswert 3.5. Da diese Version ein neues Toolset verwendet, können alle drei .NET Framework-Versionen als Ziel festgelegt werden.

Informationen zum Standardtoolset sind in den folgenden Registrierungsschlüsseln definiert:

Registrierungshive

Zeichenfolgen-Schlüsselname

Zeichenfolgen-Schlüsselwert

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\3.5\

DefaultToolsVersion

2.0

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0\

ToolsPath

.NET Framework 2.0-Installationspfad

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5\

ToolsPath

.NET Framework 3.5-Installationspfad

DefaultToolsVersion gibt an, welches Toolset beim Erstellen eines Projekts verwendet werden soll, wenn kein Toolset angegeben ist. So lautet der DefaultToolsVersion-Wert für MSBuild in Visual Studio 2008 zum Beispiel 2.0. Der Wert für DefaultToolsVersion kann in hostspezifischen Konfigurationsdateien überschrieben werden. Die anderen Werte definieren die Installationspfade für die .NET Framework-Versionen.

Hinweis:

Es wird empfohlen, dass Sie diese Einstellungen nur dann ändern, wenn dies unbedingt notwendig ist. Sie können jedoch auch eigene Einstellungen hinzufügen und computerübergreifende benutzerdefinierte Toolsetdefinitionen festlegen, wie im nächsten Abschnitt beschrieben.

Benutzerdefinierte Toolsetdefinitionen

Wenn ein Standardtoolset die Buildanforderungen nicht erfüllt, können Sie ein benutzerdefiniertes Toolset erstellen. Möglicherweise arbeiten Sie z. B. mit einem Build-Laborszenario, in dem Sie über ein separates Buildsystem zum Erstellen von Visual C++-Projekten verfügen müssen. Indem Sie ein benutzerdefiniertes Toolset verwenden, können Sie dem ToolsVersion-Attribut benutzerdefinierte Werte zuweisen, wenn Sie Projekte erstellen oder MSBuild.exe ausführen. Hierdurch können Sie auch die $(MSBuildToolsPath)-Eigenschaft zum Importieren von TARGETS-Dateien aus diesem Verzeichnis verwenden. (Alternativ können Sie auch Umgebungsvariablen verwenden, wenn Sie kein separates Toolset definieren möchten.)

Legen Sie das benutzerdefinierte Toolset in der Konfigurationsdatei für MSBuild.exe fest (oder für einen benutzerdefinierten Host von MSBuild, wenn Sie über ein separates Tool verfügen, das das MSBuild-Modul hostet). Die Konfigurationsdatei für MSBuild.exe kann zum Beispiel die folgende Toolsetdefinition enthalten:

<msbuildToolsets default="3.0">
   <toolset toolsVersion="4.0">
      <property name="MSBuildToolsPath" 
        value="C:\Windows\Microsoft .NET\Framework\v3.0" />
   </toolset>
</msbuildToolsets>

<msbuildToolsets> ist ein benutzerdefinierter .NET-Konfigurationsabschnitt, der auch wie folgt in der Konfigurationsdatei definiert werden muss:

<configSections>
   <section name="msbuildToolsets"       
       Type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, 
       Microsoft.Build.Engine, Version=3.5.0.0, Culture=neutral, 
       PublicKeyToken=b03f5f7f11d50a3a"
   </section>
</configSections>
Hinweis:

Das configSections-Tag muss das erste Tag unter dem Konfigurationstag sein, damit es ordnungsgemäß gelesen werden kann.

ToolsetConfigurationSection ist ein benutzerdefinierter Konfigurationsabschnitt, der von jedem Host für die benutzerdefinierte Konfiguration verwendet werden kann. Wenn Sie ein benutzerdefiniertes Toolset verwenden, muss ein Host keine Aktionen durchführen, um das Buildmodul zu initialisieren, sondern nur die Einträge in der Konfigurationsdatei zur Verfügung stellen. Indem Sie Einträge in der Registrierung definieren, können Sie computerübergreifende Toolsets angeben, die für MSBuild.exe, Visual Studio und alle Hosts von MSBuild angewendet werden können.

Hinweis:

Wenn in einer Konfigurationsdatei die Einstellungen für eine Toolsversion definiert werden, die bereits in der Registrierung definiert sind, werden diese beiden Definitionen nicht zusammengeführt. Die Definition in der Konfigurationsdatei hat Priorität, und die Einstellungen in der Registrierung für diese Toolsversion werden ignoriert.

Die folgenden Eigenschaften sind für den Wert der Toolsversion, die in Projekten verwendet wird, spezifisch:

  • $(MSBuildBinPath) - MSBuildBinPath ist auf den ToolsPath-Wert festgelegt, der entweder in der Registrierung oder in der Konfigurationsdatei festgelegt ist, in der die Toolsversion definiert ist. Die $(MSBuildToolsPath)-Einstellung in der Registrierung oder Konfigurationsdatei gibt den Speicherort des Toolsets an. In der Projektdatei wird dies der $(MSBuildBinPath)-Eigenschaft sowie der $(MSBuildToolsPath)-Eigenschaft zugeordnet.

  • $(MSBuildToolsPath) - Diese reservierte Eigenschaft wird von der MSBuildToolsPath-Eigenschaft bereitgestellt, die in der Konfigurationsdatei festgelegt ist. (Diese Eigenschaft ersetzt $(MSBuildBinPath). $(MSBuildBinPath) steht aus Kompatibilitätsgründen weiterhin zur Verfügung.)

Sie können auch benutzerdefinierte, Toolsversion-spezifische Eigenschaften zur Konfigurationsdatei hinzufügen, indem Sie die gleiche Syntax verwenden wie zum Hinzufügen der MSBuildToolsPath-Eigenschaft. Diese benutzerdefinierten Eigenschaften stehen der Projektdatei zur Verfügung, indem der gleiche Name wie der des in der Konfigurationsdatei angegebenen Werts verwendet wird.

Siehe auch

Konzepte

Weiterführende MSBuild-Konzepte