Tworzenie zestawu programistycznego
Zestaw SDK (Software Development Kit) to kolekcja interfejsów API, do których można się odwoływać jako pojedynczy element w programie Visual Studio. Okno dialogowe Menedżer odwołań zawiera listę wszystkich zestawów SDK, które są istotne dla projektu. Po dodaniu zestawu SDK do projektu interfejsy API są dostępne w programie Visual Studio.
Istnieją dwa typy zestawów SDK:
Zestawy SDK platformy to obowiązkowe składniki do tworzenia aplikacji dla platformy. Na przykład zestaw SDK systemu Windows 8.1 jest wymagany do tworzenia aplikacji ze Sklepu Windows 8.x.
Zestawy SDK rozszerzeń to opcjonalne składniki, które rozszerzają platformę, ale nie są obowiązkowe do tworzenia aplikacji dla tej platformy.
W poniższych sekcjach opisano ogólną infrastrukturę zestawów SDK oraz sposób tworzenia zestawu SDK platformy i zestawu SDK rozszerzenia.
Zestawy SDK platformy
Zestawy SDK platformy są wymagane do tworzenia aplikacji dla platformy. Na przykład zestaw SDK systemu Windows 8.1 jest wymagany do tworzenia aplikacji dla systemu Windows 8.1.
Instalacja
Wszystkie zestawy SDK platformy zostaną zainstalowane w folderze HKLM\Software\Microsoft\Microsoft SDKs\[TPI]\v[TPV]\@InstallationFolder = [katalog główny zestawu SDK]. W związku z tym zestaw SDK systemu Windows 8.1 jest instalowany w folderze HKLM\Software\Microsoft\Microsoft SDKs\Windows\v8.1.
Układ
Zestawy SDK platformy mają następujący układ:
\[InstallationFolder root]
SDKManifest.xml
\References
\[config]
\[arch]
\DesignTime
\[config]
\[arch]
Węzeł | opis |
---|---|
Folder odwołania | Zawiera pliki binarne zawierające interfejsy API, względem których można kodować. Mogą to być pliki lub zestawy metadanych systemu Windows (WinMD). |
Folder DesignTime | Zawiera pliki, które są potrzebne tylko w czasie przed uruchomieniem/debugowaniem. Mogą to być dokumenty XML, biblioteki, nagłówki, pliki binarne czasu projektowania przybornika, artefakty MSBuild itd. Dokumenty XML najlepiej umieścić w folderze \DesignTime , ale dokumenty XML dla odwołań będą nadal umieszczane wraz z plikiem referencyjnym w programie Visual Studio. Na przykład dokument XML dla odwołania\References\[config]\[arch]\sample.dll będzie \References\[config]\[arch]\sample.xml, a zlokalizowana wersja tego dokumentu będzie \References\[config]\[arch]\[locale]\sample.xml. |
Folder konfiguracji | Mogą istnieć tylko trzy foldery: Debugowanie, Sprzedaż detaliczna i CommonConfiguration. Autorzy zestawu SDK mogą umieścić swoje pliki w obszarze CommonConfiguration , jeśli powinien być używany ten sam zestaw plików zestawu SDK, niezależnie od konfiguracji, dla którego będzie przeznaczony użytkownik zestawu SDK. |
Folder architektury | Każdy obsługiwany folder architektury może istnieć. Program Visual Studio obsługuje następujące architektury: x86, x64, ARM i neutralne. Uwaga: Win32 mapuje na x86 i AnyCPU mapuje na neutralne. Program MSBuild wygląda tylko w obszarze \CommonConfiguration\neutral dla zestawów SDK platformy. |
Sdkmanifest.xml | W tym pliku opisano sposób korzystania z zestawu SDK przez program Visual Studio. Zapoznaj się z manifestem zestawu SDK dla systemu Windows 8.1:<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: wartość wyświetlana przez przeglądarkę obiektów na liście Przeglądaj. PlatformIdentity: istnienie tego atrybutu informuje program Visual Studio i program MSBuild, że zestaw SDK jest zestawem SDK platformy i że odwołania dodane z niego nie powinny być kopiowane lokalnie. TargetFramework: ten atrybut jest używany przez program Visual Studio w celu zapewnienia, że tylko projekty przeznaczone dla tych samych struktur, co określone w wartości tego atrybutu, mogą korzystać z zestawu SDK. MinVSVersion: ten atrybut jest używany przez program Visual Studio do korzystania tylko z zestawów SDK, które mają do niego zastosowanie. Odwołanie: ten atrybut musi być określony tylko dla tych odwołań, które zawierają kontrolki. Aby uzyskać informacje o sposobie określania, czy odwołanie zawiera kontrolki, zobacz poniżej. |
Zestawy SDK rozszerzeń
W poniższych sekcjach opisano, co należy zrobić, aby wdrożyć zestaw SDK rozszerzenia.
Instalacja
Zestawy SDK rozszerzeń można zainstalować dla określonego użytkownika lub dla wszystkich użytkowników bez określania klucza rejestru. Aby zainstalować zestaw SDK dla wszystkich użytkowników, użyj następującej ścieżki:
%Program Files%\Microsoft SDKs<target platform>\v<version number>\ExtensionSDKs
W przypadku instalacji specyficznej dla użytkownika użyj następującej ścieżki:
%USERPROFILE%\AppData\Local\Microsoft SDKs<target platform>\v<version number>\ExtensionSDKs
Jeśli chcesz użyć innej lokalizacji, musisz wykonać jedną z dwóch czynności:
Określ go w kluczu rejestru:
HKLM\Software\Microsoft\Microsoft SDKs<target platform>\v<version number>\ExtensionSDKs<SDKName><SDKVersion>\
i dodaj podklucz (Domyślny), który ma wartość
<path to SDK><SDKName><SDKVersion>
.Dodaj właściwość
SDKReferenceDirectoryRoot
MSBuild do pliku projektu. Wartość tej właściwości to rozdzielana średnikami lista katalogów, w których znajdują się zestawy SDK rozszerzeń, do których chcesz się odwoływać.
Układ instalacji
Zestawy SDK rozszerzeń mają następujący układ instalacji:
\<ExtensionSDKs root>
\<SDKName>
\<SDKVersion>
SDKManifest.xml
\References
\<config>
\<arch>
\Redist
\<config>
\<arch>
\DesignTime
\<config>
\<arch>
\<SDKName>\<SDKVersion>: nazwa i wersja zestawu SDK rozszerzenia pochodzą z odpowiednich nazw folderów w ścieżce do katalogu głównego zestawu SDK. Program MSBuild używa tej tożsamości do znalezienia zestawu SDK na dysku, a program Visual Studio wyświetla tę tożsamość w oknie Właściwości i oknie dialogowym Menedżer odwołań.
Folder odwołania: pliki binarne zawierające interfejsy API. Mogą to być pliki lub zestawy metadanych systemu Windows (WinMD).
Folder redist : pliki wymagane do środowiska uruchomieniowego/debugowania i powinny zostać spakowane w ramach aplikacji użytkownika. Wszystkie pliki binarne powinny zostać umieszczone poniżej \redist\<config>\<arch>, a nazwy binarne powinny mieć następujący format, aby zapewnić unikatowość: ]<company.<>produkt>.<cel>.<rozszerzenie>. Na przykład *Microsoft.Cpp.Build.dll. Wszystkie pliki o nazwach, które mogą zderzać się z nazwami plików z innych zestawów SDK (na przykład javascript, css, pri, xaml, png i jpg) powinny zostać umieszczone poniżej \redist\<config>\arch>\<<sdkname>* z wyjątkiem plików skojarzonych z kontrolkami XAML. Te pliki należy umieścić poniżej *\redist\<config>\<arch>\<componentname>\.
Folder DesignTime : pliki, które są potrzebne tylko w czasie przed uruchomieniem/debugowaniem i nie powinny być pakowane w ramach aplikacji użytkownika. Mogą to być dokumenty XML, biblioteki, nagłówki, pliki binarne czasu projektowania przybornika, artefakty MSBuild itd. Każdy zestaw SDK przeznaczony do użycia przez projekt natywny musi mieć plik SDKName.props . Poniżej przedstawiono przykładowy plik tego typu.
<?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>
Dokumenty referencyjne XML są umieszczane wraz z plikiem referencyjnym. Na przykład dokument referencyjny XML dla zestawu \References\<config>\><sample.dll to \References\<config>\arch>\<sample.xml, a zlokalizowana wersja tego dokumentu to \References\<config>\arch>\<<locale>\sample.xml.
Folder konfiguracji : trzy podfoldery: Debugowanie, Sprzedaż detaliczna i CommonConfiguration. Autorzy zestawu SDK mogą umieszczać swoje pliki w obszarze CommonConfiguration , gdy powinien być używany ten sam zestaw plików zestawu SDK, niezależnie od konfiguracji przeznaczonej dla użytkownika zestawu SDK.
Folder architektury : obsługiwane są następujące architektury: x86, x64, ARM, neutralne. Win32 mapuje na x86 i AnyCPU mapuje na neutralne.
Sdkmanifest.xml
W pliku SDKManifest.xml opisano sposób korzystania z zestawu SDK przez program Visual Studio. Poniżej przedstawiono przykład:
<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>
Poniższa lista zawiera elementy pliku:
DisplayName: wartość wyświetlana w Menedżerze odwołań, Eksplorator rozwiązań, Przeglądarka obiektów i inne lokalizacje w interfejsie użytkownika programu Visual Studio.
ProductFamilyName: ogólna nazwa produktu ZESTAWU SDK. Na przykład zestaw SDK biblioteki systemu Windows dla języka JavaScript (WinJS) nosi nazwę "Microsoft.WinJS.1.0" i "Microsoft.WinJS.2.0", która należy do tej samej rodziny produktów SDK", "Microsoft.WinJS". Ten atrybut umożliwia programom Visual Studio i MSBuild nawiązywanie tego połączenia. Jeśli ten atrybut nie istnieje, nazwa zestawu SDK jest używana jako nazwa rodziny produktów.
FrameworkIdentity: określa zależność od co najmniej jednej biblioteki składników systemu Windows. Wartość tego atrybutu jest umieszczana w manifeście aplikacji zużywającej. Ten atrybut ma zastosowanie tylko do bibliotek składników systemu Windows.
TargetFramework: określa zestawy SDK, które są dostępne w Menedżerze odwołań i przyborniku. Jest to rozdzielana średnikami lista obiektów docelowych, na przykład ".NET Framework, version=v2.0; .NET Framework, version=v4.5.1". Jeśli określono kilka wersji tej samej platformy docelowej, Menedżer odwołań używa najniższej określonej wersji do celów filtrowania. Jeśli na przykład określono program ".NET Framework, version=v2.0; .NET Framework, version=v4.5.1", Menedżer odwołań użyje programu ".NET Framework, version=v2.0". Jeśli określony profil platformy docelowej zostanie określony, tylko ten profil będzie używany przez Menedżera odwołań do celów filtrowania. Na przykład po określeniu parametru "Silverlight, version=v4.0, profile=Windows Telefon" menedżer odwołań filtruje tylko w profilu systemu Windows Telefon; projekt przeznaczony dla pełnej struktury Silverlight 4.0 nie widzi zestawu SDK w Menedżerze odwołań.
MinVSVersion: minimalna wersja programu Visual Studio.
MaxPlatformVerson: Maksymalna wersja platformy docelowej powinna służyć do określania wersji platformy, w których zestaw SDK rozszerzenia nie będzie działać. Na przykład pakiet środowiska uruchomieniowego Microsoft Visual C++ w wersji 11.0 powinien być przywoływalny tylko przez projekty systemu Windows 8. W związku z tym maxplatformVersion projektu Systemu Windows 8 jest 8.0. Oznacza to, że Menedżer odwołań filtruje pakiet środowiska uruchomieniowego Programu Microsoft Visual C++ dla projektu systemu Windows 8.1, a program MSBuild zgłasza błąd, gdy projekt systemu Windows 8.1 odwołuje się do niego. Uwaga: ten element jest obsługiwany w programie Visual Studio 2013.
AppliesTo: określa zestawy SDK, które są dostępne w Menedżerze odwołań, określając odpowiednie typy projektów programu Visual Studio. Rozpoznawane są dziewięć wartości: WindowsAppContainer, VisualC, VB, CSharp, WindowsXAML, JavaScript, Managed i Native. Autor zestawu SDK może używać elementów i ("+") lub ("|"), a nie ("!") operatory określające dokładnie zakres typów projektów, które mają zastosowanie do zestawu SDK.
Aplikacja WindowsAppContainer identyfikuje projekty dla aplikacji ze Sklepu Windows 8.x.
SupportPrefer32Bit: Obsługiwane wartości to "True" i "False". Wartość domyślna to "True". Jeśli wartość jest ustawiona na wartość "Fałsz", program MSBuild zwraca błąd dla projektów sklepu Windows 8.x (lub ostrzeżenie dla projektów klasycznych), jeśli projekt odwołujący się do zestawu SDK ma włączoną opcję Prefer32Bit. Aby uzyskać więcej informacji na temat Prefer32Bit, zobacz Stronę kompilacji, Projekt Projektant (C#) lub Stronę kompilowania, Project Projektant (Visual Basic).
SupportedArchitectures: rozdzielana średnikami lista architektur obsługiwanych przez zestaw SDK. Program MSBuild wyświetla ostrzeżenie, jeśli docelowa architektura zestawu SDK w projekcie zużywanym nie jest obsługiwana. Jeśli ten atrybut nie zostanie określony, program MSBuild nigdy nie wyświetla tego typu ostrzeżenia.
SupportsMultipleVersions: jeśli ten atrybut ma wartość Błąd lub Ostrzeżenie, program MSBuild wskazuje, że ten sam projekt nie może odwoływać się do wielu wersji tej samej rodziny zestawów SDK. Jeśli ten atrybut nie istnieje lub jest ustawiony na Wartość Zezwalaj, program MSBuild nie wyświetla tego typu błędu ani ostrzeżenia.
AppX: określa ścieżkę do pakietów aplikacji dla biblioteki składników systemu Windows na dysku. Ta wartość jest przekazywana do składnika rejestracji biblioteki składników systemu Windows podczas lokalnego debugowania. Konwencja nazewnictwa nazwy pliku to <Company>.<Produkt>.<Architektura>.<Konfiguracja>.<Wersja>.appx. Konfiguracja i architektura są opcjonalne w nazwie atrybutu i wartości atrybutu, jeśli nie mają zastosowania do biblioteki składników systemu Windows. Ta wartość ma zastosowanie tylko do bibliotek składników systemu Windows.
CopyRedistToSubDirectory: określa, gdzie pliki w folderze \redist powinny być kopiowane względem katalogu głównego pakietu aplikacji (czyli lokalizacji pakietu wybranej w kreatorze tworzenia pakietu aplikacji) i katalogu głównego układu środowiska uruchomieniowego. Domyślną lokalizacją jest katalog główny pakietu aplikacji i układ F5 .
DependsOn: lista tożsamości zestawu SDK, które definiują zestawy SDK, od których zależy ten zestaw SDK. Ten atrybut jest wyświetlany w okienku szczegółów Menedżera odwołań.
Więcej informacji: adres URL strony internetowej, która zawiera pomoc i więcej informacji. Ta wartość jest używana w linku Więcej informacji w okienku po prawej stronie Menedżera odwołań.
Typ rejestracji: określa rejestrację winMD w manifeście aplikacji i jest wymagany dla natywnej usługi WinMD, która ma odpowiednik biblioteki DLL implementacji.
Odwołanie do pliku: określone tylko dla tych odwołań, które zawierają kontrolki lub są natywnymi identyfikatorami WinMD. Aby uzyskać informacje o sposobie określania, czy odwołanie zawiera kontrolki, zobacz Określanie lokalizacji elementów przybornika poniżej.
Określanie lokalizacji elementów przybornika
Element ToolBoxItems schematu SDKManifest.xml określa nazwy kontrolek, zestawy źródłowe i nazwy kart przybornika elementów przybornika w zestawach SDK platformy i rozszerzenia. W poniższych przykładach przedstawiono różne scenariusze. Dotyczy to odwołań winMD lub DLL.
Należy pamiętać, że w programie Visual Studio 2019 i starszych wersjach zamiast wyświetlania listy nazw kontrolek przybornika w manifeście program Visual Studio dynamicznie wyliczał typy kontrolek w zestawach zestawu SDK. Począwszy od programu Visual Studio 2022, nie jest to już obsługiwane; Elementy przybornika muszą być jawnie wymienione w SDKManifest.xml.
Umieść kontrolki w kategorii domyślnej przybornika.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory = "Toolbox.Default"> <Item Type = "Namespace.ControlName1" /> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>
Umieść kontrolki pod określoną nazwą kategorii.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory= "MyCategoryName"> <Item Type = "Namespace.ControlName1" /> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>
Umieść kontrolki w określonych nazwach kategorii.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory = "Graph"> <Item Type = "Namespace.ControlName1" /> </ToolboxItems> <ToolboxItems VSCategory = "Data"> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>
Umieść kontrolki w różnych nazwach kategorii w programie Blend i programie 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>
Wyliczanie określonych kontrolek inaczej w programie Blend i Visual Studio.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory = "Graph"> <Item Type = "Namespace.ControlName1" /> </ToolboxItems> <ToolboxItems BlendCategory = "Controls/sample/Graph"> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>
Wyliczanie określonych kontrolek i umieszczanie ich w wspólnej ścieżce programu Visual Studio lub tylko w grupie Wszystkie kontrolki.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory = "Toolbox.Common"> <Item Type = "Namespace.ControlName1" /> </ToolboxItems> <ToolboxItems VSCategory = "Toolbox.All"> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>
Wyliczanie określonych kontrolek i pokazywanie tylko określonego zestawu w elematach ChooseItems bez ich używania w przyborniku.
<File Reference = "sample.winmd"> <ToolboxItems VSCategory = "Toolbox.ChooseItemsOnly"> <Item Type = "Namespace.ControlName1" /> <Item Type = "Namespace.ControlName2" /> </ToolboxItems> </File>