Erstellen eines Softwareentwicklungskits

Gilt für:yes Visual Studio noVisual Studio für Mac noVisual Studio Code

Ein Software Development Kit (SDK) ist eine Sammlung von APIs, auf die Sie als einzelnes Element in Visual Studio verweisen können. Im Dialogfeld "Referenz-Manager " sind alle SDKs aufgeführt, die für das Projekt relevant sind. Wenn Sie einem Projekt ein SDK hinzufügen, sind die APIs in Visual Studio verfügbar.

Es gibt zwei Arten von SDKs:

  • Plattform-SDKs sind obligatorische Komponenten für die Entwicklung von Apps für eine Plattform. Beispielsweise ist das Windows 8.1 SDK erforderlich, um Windows 8.x Store-Apps zu entwickeln.

  • Erweiterungs-SDKs sind optionale Komponenten, die eine Plattform erweitern, aber für die Entwicklung von Apps für diese Plattform nicht obligatorisch sind.

In den folgenden Abschnitten werden die allgemeine Infrastruktur von SDKs und das Erstellen eines Plattform-SDK und eines Erweiterungs-SDK beschrieben.

Plattform-SDKs

Plattform-SDKs sind erforderlich, um Apps für eine Plattform zu entwickeln. Beispielsweise ist das Windows 8.1 SDK erforderlich, um Apps für Windows 8.1 zu entwickeln.

Installation

Alle Plattform-SDKs werden unter HKLM\Software\Microsoft\Microsoft\Microsoft SDKs\[TPI]\v[TPV]\@InstallationFolder = [SDK-Stamm] installiert. Dementsprechend wird das Windows 8.1 SDK unter HKLM\Software\Microsoft\Microsoft\Microsoft SDKs\Windows\v8.1 installiert.

Layout

Plattform-SDKs weisen das folgende Layout auf:

\[InstallationFolder root]
            SDKManifest.xml
            \References
                  \[config]
                        \[arch]
            \DesignTime
                  \[config]
                        \[arch]
Node BESCHREIBUNG
Ordner "Verweise" Enthält Binärdateien, die APIs enthalten, die codiert werden können. Dazu können Windows-Metadatendateien (WinMD)-Dateien oder Assemblys gehören.
DesignTime-Ordner Enthält Dateien, die nur zur Vorausführung/Debugzeit benötigt werden. Dazu gehören XML-Dokumente, Bibliotheken, Header, Toolbox-Entwurfszeit-Binärdateien, MSBuild-Artefakte usw.

XML-Dokumente würden idealerweise im Ordner \DesignTime platziert, xml-Dokumente für Verweise werden jedoch weiterhin neben der Referenzdatei in Visual Studio platziert. Beispielsweise lautet das XML-Dokument für einen Verweis\References\[config]\[arch]\sample.dll\References\[config]\[arch]\sample.xml, und die lokalisierte Version dieses Dokuments lautet \References\[config]\[arch]\[locale]\sample.xml.
Konfigurationsordner Es gibt nur drei Ordner: Debuggen, Einzelhandel und CommonConfiguration. SDK-Autoren können ihre Dateien unter CommonConfiguration platzieren, wenn dieselbe Gruppe von SDK-Dateien verwendet werden soll, unabhängig von der Konfiguration, auf die der SDK-Consumer ausgerichtet ist.
Architekturordner Jeder unterstützte Architekturordner kann vorhanden sein. Visual Studio unterstützt die folgenden Architekturen: x86, x64, ARM und neutral. Hinweis: Win32 ordnet x86 zu, und AnyCPU-Karten sind neutral.

MSBuild sucht nur unter \CommonConfiguration\neutral für Plattform-SDKs.
SDKManifest.xml In dieser Datei wird beschrieben, wie Visual Studio das SDK nutzen soll. Schauen Sie sich das SDK-Manifest für Windows 8.1 an:

<FileList DisplayName = "Windows" PlatformIdentity = "Windows, version=8.1" TargetFramework = ".NET for Windows Store apps, version=v4.5.1; .NET Framework, version=v4.5.1" MinVSVersion = "14.0"> <File Reference = "Windows.winmd"> <ToolboxItems VSCategory = "Toolbox.Default" /> </File> </FileList>

Displayname: Der Wert, den der Objektbrowser in der Liste "Durchsuchen" anzeigt.

PlatformIdentity: Das Vorhandensein dieses Attributs weist Visual Studio und MSBuild darauf hin, dass es sich bei dem SDK um ein Plattform-SDK handelt und dass die darin hinzugefügten Verweise nicht lokal kopiert werden sollten.

TargetFramework: Dieses Attribut wird von Visual Studio verwendet, um sicherzustellen, dass nur Projekte, die auf dieselben Frameworks abzielen, wie im Wert dieses Attributs angegeben, das SDK nutzen können.

MinVSVersion: Dieses Attribut wird von Visual Studio verwendet, um nur die SDKs zu nutzen, die darauf angewendet werden.

Verweis: Dieses Attribut muss nur für diese Verweise angegeben werden, die Steuerelemente enthalten. Informationen zum Angeben, ob ein Verweis Steuerelemente enthält, finden Sie unten.

Erweiterungs-SDKs

In den folgenden Abschnitten wird beschrieben, was Sie tun müssen, um ein Erweiterungs-SDK bereitzustellen.

Installation

Erweiterungs-SDKs können für einen bestimmten Benutzer oder für alle Benutzer installiert werden, ohne einen Registrierungsschlüssel anzugeben. Um ein SDK für alle Benutzer zu installieren, verwenden Sie den folgenden Pfad:

%Programme%\Microsoft SDKs<Zielplattform>\v<Plattformnummer>\ExtensionSDKs

Verwenden Sie für eine benutzerspezifische Installation den folgenden Pfad:

%USERPROFILE%\AppData\Local\Microsoft SDKs-Zielplattform<\v<Plattformversionsnummer>>\ExtensionSDKs

Wenn Sie einen anderen Standort verwenden möchten, müssen Sie eine von zwei Dingen ausführen:

  1. Geben Sie ihn in einem Registrierungsschlüssel an:

    HKLM\Software\Microsoft\Microsoft SDKs<Zielplattform>\v<Plattformversionsnummer>\ExtensionSDKs<SDKName><SDKVersion>\

    und fügen Sie einen (Standard)-Unterschlüssel hinzu, der einen Wert hat <path to SDK><SDKName><SDKVersion>.

  2. Fügen Sie der Projektdatei die MSBuild-Eigenschaft SDKReferenceDirectoryRoot hinzu. Der Wert dieser Eigenschaft ist eine durch Semikolon getrennte Liste von Verzeichnissen, in denen sich die Erweiterungs-SDKs befinden, auf die Sie verweisen möchten.

Installationslayout

Erweiterungs-SDKs weisen das folgende Installationslayout auf:

\<ExtensionSDKs root>
           \<SDKName>
                 \<SDKVersion>
                        SDKManifest.xml
                        \References
                              \<config>
                                    \<arch>
                        \Redist
                              \<config>
                                    \<arch>
                        \DesignTime
                               \<config>
                                     \<arch>

  1. \<SDKName>\<SDKVersion>: Der Name und die Version des Erweiterungs-SDK wird von den entsprechenden Ordnernamen im Pfad zum SDK-Stamm abgeleitet. MSBuild verwendet diese Identität, um das SDK auf dem Datenträger zu finden, und Visual Studio zeigt diese Identität im Dialogfeld Eigenschaften und Referenz-Manager an.

  2. Referenzordner : Die Binärdateien, die die APIs enthalten. Dies kann Windows-Metadatendateien (WinMD)-Dateien oder Assemblys sein.

  3. Ordner "Redist ": Die Dateien, die zur Laufzeit/Debugging erforderlich sind, und sollten als Teil der Anwendung des Benutzers verpackt werden. Alle Binärdateien sollten unter \redist\<config>\<arch> platziert werden, und die binären Namen sollten das folgende Format aufweisen, um die Eindeutigkeit zu gewährleisten: ]<company>.< Produkt>.< Zweck>.< Erweiterung>. Beispiel: *Microsoft.Cpp.Build.dll. Alle Dateien mit Namen, die mit Dateinamen aus anderen SDKs (z. B. javascript, css, pri, xaml, png, png und jpg-Dateien) kollidieren können, sollten unter \redist\<config>\<arch>\<sdkname>* platziert werden, außer für die Dateien, die xaml-Steuerelementen zugeordnet sind. Diese Dateien sollten unter *\redist\<config>\arch>\<<componentname>\platziert werden.

  4. DesignTime-Ordner : Die Dateien, die nur zur Vorausführung/Debugging erforderlich sind, und sollten nicht als Teil der Anwendung des Benutzers verpackt werden. Dies könnte XML-Dokumente, Bibliotheken, Header, Toolbox-Entwurfszeit-Binärdateien, MSBuild-Artefakte usw. sein. Jedes SDK, das für den Verbrauch durch ein systemeigenes Projekt vorgesehen ist, muss über eine SDKName.props-Datei verfügen. Im Folgenden finden Sie ein Beispiel für diesen Dateityp.

    <?xml version="1.0" encoding="utf-8"?>
    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <ExecutablePath>C:\Temp\ExecutablePath;$(ExecutablePath)</ExecutablePath>
        <IncludePath>$(FrameworkSDKRoot)\..\v8.1\ExtensionSDKs\cppimagingsdk\1.0\DesignTime\CommonConfiguration\Neutral\include;$(IncludePath)</IncludePath>
        <AssemblyReferencePath>C:\Temp\AssemblyReferencePath;(AssemblyReferencePath)</AssemblyReferencePath>
        <LibraryPath>$(FrameworkSDKRoot)\..\v8.1\ExtensionSDKs\cppimagingsdk\1.0\DesignTime\Debug\ARM;$(LibraryPath)</LibraryPath>
        <SourcePath>C:\Temp\SourcePath\X64;$(SourcePath)</SourcePath>
        <ExcludePath>C:\Temp\ExcludePath\X64;$(ExcludePath)</ExcludePath>
        <_PropertySheetDisplayName>DevILSDK, 1.0</_PropertySheetDisplayName>
      </PropertyGroup>
    </Project>
    
    

    XML-Referenzdokumente werden neben der Referenzdatei platziert. Das XML-Referenzdokument für die Assembly \References\<config>\<arch>\sample.dll ist beispielsweise \References\<config>\<arch>\sample.xml, und die lokalisierte Version dieses Dokuments lautet \References\<config>\arch>\<<locale>\sample.xml.

  5. Konfigurationsordner : drei Unterordner: Debuggen, Einzelhandel und CommonConfiguration. SDK-Autoren können ihre Dateien unter CommonConfiguration platzieren, wenn dieselbe Gruppe von SDK-Dateien verwendet werden soll, unabhängig von der Konfiguration, die vom SDK-Verbraucher bestimmt ist.

  6. Architekturordner : Die folgenden Architekturen werden unterstützt: x86, x64, ARM, neutral. Win32 ordnet x86 zu, und AnyCPU ist neutral.

SDKManifest.xml

Die SDKManifest.xml Datei beschreibt, wie Visual Studio das SDK nutzen soll. Es folgt ein Beispiel:

<FileList DisplayName = "My SDK"
          ProductFamilyName = "My SDKs"
          TargetFramework = ".NETCore, version=v4.5.1; .NETFramework, version=v4.5.1"
          MinVSVersion = "14.0"
          MaxPlatformVersion = "8.1"
          AppliesTo = "WindowsAppContainer + WindowsXAML"
          SupportPrefer32Bit = "True"
          SupportedArchitectures = "x86;x64;ARM"
          SupportsMultipleVersions = "Error"
          CopyRedistToSubDirectory = "."
          DependsOn = "SDKB, version=2.0"
          MoreInfo = "https://msdn.microsoft.com/MySDK">
  <File Reference = "MySDK.Sprint.winmd" Implementation = "XNASprintImpl.dll">
    <Registration Type = "Flipper" Implementation = "XNASprintFlipperImpl.dll" />
    <Registration Type = "Flexer" Implementation = "XNASprintFlexerImpl.dll" />
    <ToolboxItems VSCategory = "Toolbox.Default" />
  </File>
</FileList>

Die folgende Liste enthält die Elemente der Datei:

  1. DisplayName: Der Wert, der im Referenz-Manager, Projektmappen-Explorer, Objektbrowser und anderen Speicherorten auf der Benutzeroberfläche für Visual Studio angezeigt wird.

  2. ProductFamilyName: Der gesamte SDK-Produktname. Das Windows Library for JavaScript (WinJS) SDK heißt beispielsweise "Microsoft.WinJS.1.0" und "Microsoft.WinJS.2.0", die zur gleichen Familie von SDK-Produkten gehören, "Microsoft.WinJS". Mit diesem Attribut kann Visual Studio und MSBuild diese Verbindung herstellen. Wenn dieses Attribut nicht vorhanden ist, wird der SDK-Name als Produktfamilienname verwendet.

  3. FrameworkIdentity: Gibt eine Abhängigkeit von einer oder mehreren Windows-Komponentenbibliotheken an. Der Wert dieses Attributs wird im Manifest der verbrauchenden App eingefügt. Dieses Attribut gilt nur für Windows-Komponentenbibliotheken.

  4. TargetFramework: Gibt die SDKs an, die im Referenz-Manager und in der Toolbox verfügbar sind. Dies ist eine durch Semikolon getrennte Liste von Zielframework-Monikern, z. B. ".NET Framework, version=v2.0; .NET Framework, version=v4.5.1". Wenn mehrere Versionen desselben Zielframeworks angegeben sind, verwendet der Referenz-Manager die niedrigste angegebene Version für Filterzwecke. Wenn beispielsweise ".NET Framework, version=v2.0; .NET Framework, version=v4.5.1" angegeben ist, verwendet Reference Manager ".NET Framework, version=v2.0". Wenn ein bestimmtes Zielframeworkprofil angegeben wird, wird nur dieses Profil vom Referenz-Manager für Filterzwecke verwendet. Wenn beispielsweise "Silverlight, version=v4.0, profile=WindowsPhone" angegeben ist, filtert der Referenz-Manager nur im Windows Phone-Profil; Ein Projekt, das auf das vollständige Silverlight 4.0 Framework ausgerichtet ist, wird das SDK im Referenz-Manager nicht angezeigt.

  5. MinVSVersion: Die mindeste Visual Studio-Version.

  6. MaxPlatformVerson: Die maximale Zielplattformversion sollte verwendet werden, um die Plattformversionen anzugeben, auf denen Ihr Extension SDK nicht funktioniert. Das Microsoft Visual C++-Runtime-Paket v11.0 sollte beispielsweise nur von Windows 8-Projekten referenziert werden. Daher ist die MaxPlatformVersion des Windows 8-Projekts 8.0. Dies bedeutet, dass der Referenz-Manager das Microsoft Visual C++-Runtime-Paket für ein Windows 8.1-Projekt ausfiltert, und MSBuild löst einen Fehler aus, wenn ein Windows 8.1-Projekt darauf verweist. Hinweis: Dieses Element wird ab Visual Studio 2013 unterstützt.

  7. AppliesTo: Gibt die SDKs an, die im Referenz-Manager verfügbar sind, indem sie die entsprechenden Visual Studio-Projekttypen angeben. Neun Werte werden erkannt: WindowsAppContainer, VisualC, VB, CSharp, WindowsXAML, JavaScript, Managed und Native. Der SDK-Autor kann und ("+'") oder ("|"), nicht ("!") Operatoren, um genau den Bereich der Projekttypen anzugeben, die für das SDK gelten.

    WindowsAppContainer identifiziert Projekte für Windows 8.x Store-Apps.

  8. SupportPrefer32Bit: Unterstützte Werte sind "True" und "False". Der Standardwert ist "True". Wenn der Wert auf "False" festgelegt ist, gibt MSBuild einen Fehler für Windows 8.x Store-Projekte (oder eine Warnung für Desktopprojekte) zurück, wenn das Projekt, das auf das SDK verweist, prefer32Bit aktiviert ist. Weitere Informationen zu Prefer32Bit finden Sie unter Buildseite, Project Designer (C#) oder Kompilierungsseite, Project Designer (Visual Basic).

  9. SupportedArchitectures: Eine durch Semikolon getrennte Liste von Architekturen, die das SDK unterstützt. MSBuild zeigt eine Warnung an, wenn die zielorientierte SDK-Architektur im verbrauchenden Projekt nicht unterstützt wird. Wenn dieses Attribut nicht angegeben ist, zeigt MSBuild niemals diesen Warnungstyp an.

  10. SupportsMultipleVersions: Wenn dieses Attribut auf Fehler oder Warnung festgelegt ist, gibt MSBuild an, dass dasselbe Projekt nicht auf mehrere Versionen derselben SDK-Familie verweisen kann. Wenn dieses Attribut nicht vorhanden ist oder auf "Zulassen" festgelegt ist, zeigt MSBuild diesen Fehler- oder Warnungstyp nicht an.

  11. AppX: Gibt den Pfad zu den App-Paketen für die Windows-Komponentenbibliothek auf dem Datenträger an. Dieser Wert wird während des lokalen Debuggens an die Registrierungskomponente der Windows-Komponentenbibliothek übergeben. Die Benennungskonvention für den Dateinamen lautet <"Company>".< Produkt>.< Architektur>.< Konfiguration>.< Version.appx>. Konfiguration und Architektur sind optional im Attributnamen und dem Attributwert, wenn sie nicht auf die Windows-Komponentenbibliothek angewendet werden. Dieser Wert gilt nur für Windows-Komponentenbibliotheken.

  12. CopyRedistToSubDirectory: Gibt an, wo die Dateien im Ordner \redist relativ zum App-Paketstamm kopiert werden sollen (das heißt, der im Assistenten zum Erstellen von App-Paketen ausgewählte Paketspeicherort) und das Laufzeitlayoutstamm. Der Standardspeicherort ist das Stammverzeichnis des App-Pakets und des F5-Layouts .

  13. DependsOn: Eine Liste der SDK-Identitäten, die die SDKs definieren, von denen dieses SDK abhängt. Dieses Attribut wird im Detailbereich des Referenz-Managers angezeigt.

  14. MoreInfo: Die URL zur Webseite, die Hilfe und weitere Informationen bereitstellt. Dieser Wert wird im rechten Bereich des Referenz-Managers im Link "Weitere Informationen" verwendet.

  15. Registrierungstyp: Gibt die WinMD-Registrierung im App-Manifest an und ist für systemeigene WinMD erforderlich, die über eine Gegenimplementierungs-DLL verfügt.

  16. Dateireferenz: Nur für diese Verweise angegeben, die Steuerelemente enthalten oder systemeigene WinMDs sind. Informationen zum Angeben, ob ein Verweis Steuerelemente enthält, finden Sie unter Angeben des Speicherorts der Toolboxelemente unten.

Angeben der Position von Toolboxelementen

Das ToolBoxItems-Element des SDKManifest.xml-Schemas gibt die Steuerelementnamen, Quellassemblys und Toolboxregisternamen von Toolboxelementen in Plattform- und Erweiterungs-SDKs an. Die folgenden Beispiele zeigen verschiedene Szenarien. Dies gilt entweder für WinMD- oder DLL-Verweise.

Beachten Sie, dass Visual Studio 2019 und früher anstelle der Auflistung von Toolbox-Steuerelementnamen im Manifest visual Studio dynamisch die Steuerelementtypen in den Assemblys des SDK aufzählt. Ab Visual Studio 2022 wird dies nicht mehr unterstützt; Toolboxelemente müssen in SDKManifest.xmlexplizit aufgeführt werden.

  1. Platzieren Sie Steuerelemente in der Standardkategorie der Toolbox.

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Toolbox.Default">
        <Item Type = "Namespace.ControlName1" />
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  2. Platzieren Sie Steuerelemente unter einem bestimmten Kategorienamen.

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory= "MyCategoryName">
        <Item Type = "Namespace.ControlName1" />
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  3. Platzieren Sie Steuerelemente unter bestimmten Kategorienamen.

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Graph">
        <Item Type = "Namespace.ControlName1" />
      </ToolboxItems>
      <ToolboxItems VSCategory = "Data">
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  4. Platzieren Sie Steuerelemente unter verschiedenen Kategorienamen in Blend und Visual Studio.

    // Blend accepts a slightly different structure for the category name because it allows a path rather than a single category.
    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Graph" BlendCategory = "Controls/sample/Graph">
        <Item Type = "Namespace.ControlName1" />
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  5. Aufzählen bestimmter Steuerelemente in Blend und Visual Studio unterschiedlich.

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Graph">
        <Item Type = "Namespace.ControlName1" />
      </ToolboxItems>
      <ToolboxItems BlendCategory = "Controls/sample/Graph">
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  6. Enumerieren Sie bestimmte Steuerelemente, und platzieren Sie sie unter dem allgemeinen Visual Studio-Pfad oder nur in der Gruppe "Alle Steuerelemente".

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Toolbox.Common">
        <Item Type = "Namespace.ControlName1" />
      </ToolboxItems>
      <ToolboxItems VSCategory = "Toolbox.All">
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    
  7. Enumerieren Sie bestimmte Steuerelemente, und zeigen Sie nur einen bestimmten Satz in ChooseItems an, ohne dass sie in der Toolbox enthalten sind.

    <File Reference = "sample.winmd">
      <ToolboxItems VSCategory = "Toolbox.ChooseItemsOnly">
        <Item Type = "Namespace.ControlName1" />
        <Item Type = "Namespace.ControlName2" />
      </ToolboxItems>
    </File>
    

Weitere Informationen