Criando um Kit de desenvolvimento de Software

 

Para obter a documentação mais recente do Visual Studio 2017 RC, consulte a documentação do Visual Studio 2017 RC.

Um software development kit (SDK) é um conjunto de APIs que você pode referenciar como um único item no Visual Studio. O Gerenciador de referências caixa de diálogo lista todos os SDKs que são relevantes para o projeto. Quando você adiciona um SDK a um projeto, as APIs estão disponíveis no Visual Studio.

Há dois tipos de SDKs:

  • Plataforma SDKs são componentes obrigatórios para o desenvolvimento de aplicativos para uma plataforma. Por exemplo, o Windows 8.1 SDK é necessário desenvolver Windows Store 8.x aplicativos.

  • SDKs de extensão são componentes opcionais que estendem uma plataforma, mas não são obrigatórios para desenvolver aplicativos para a plataforma.

As seções a seguir descrevem a infra-estrutura geral de como criar uma plataforma SDK e SDKs e um SDK de extensão.

Plataforma SDKs são necessários para desenvolver aplicativos para uma plataforma. Por exemplo, o Windows 8.1 SDK é necessário para desenvolver aplicativos para Windows 8.1.

Instalação

Todos os SDKs de plataforma serão instalado em HKLM\Software\Microsoft\Microsoft SDKs\\v [TPI] [TPV]\@InstallationFolder = [raiz do SDK]. Da mesma forma, o Windows 8.1 SDK está instalado em HKLM\Software\Microsoft\Microsoft SDKs\Windows\v8.1.

Layout

Plataforma SDKs terá o seguinte layout:

\[InstallationFolder root]  
            SDKManifest.xml  
            \References  
                  \[config]  
                        \[arch]  
            \DesignTime  
                  \[config]  
                        \[arch]  

Descrição
Pasta ReferênciasContém os binários que contêm APIs que podem ser codificados em. Eles pode incluir arquivos de metadados do Windows (WinMD) ou assemblies.
Pasta de DesignTimeContém arquivos que são necessários apenas em tempo de pré-execução/depuração. Eles podem incluir documentos XML, bibliotecas, cabeçalhos, binários em tempo de design de ferramentas, MSBuild artefatos e assim por diante

Documentos XML seriam, o ideal são colocados na pasta \DesignTime, mas os documentos XML para referências continuarão a ser posicionados junto com o arquivo de referência no Visual Studio. Por exemplo, o documento XML para uma referência \References\[configuração]\[arch]\sample.dll será \References\[configuração]\[arch]\sample.xml e a versão localizada desse documento será \References\[configuração]\[arch]\[locale]\sample.xml.
Pasta de configuraçãoPode haver apenas três pastas: debug, varejo e CommonConfiguration. Os autores do SDK podem colocar seus arquivos em CommonConfiguration se o mesmo conjunto de arquivos do SDK deve ser consumido, independentemente da configuração que o consumidor do SDK têm como destino.
Pasta de arquiteturaPode existir qualquer pasta de arquitetura com suporte. O Visual Studio suporta as seguintes arquiteturas: x86, x64, ARM e neutro. Observação: O Win32 mapeia para x86 e AnyCPU mapeia para neutro.

MSBuild procura apenas sob \CommonConfiguration\neutral SDKs da plataforma.
SdkmanifestEste arquivo descreve como o Visual Studio deve consumir o SDK. Examinar o manifesto do SDK para 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: o valor que o Pesquisador de objetos exibe na lista de pesquisa.

 PlatformIdentity: a existência desse atributo informa ao Visual Studio e o MSBuild que o SDK é uma plataforma SDK e que as referências adicionadas dele não devem ser copiadas localmente.

 TargetFramework: esse atributo é usado pelo Visual Studio para garantir que somente projetos destinados as mesmas estruturas conforme especificado no valor desse atributo pode consumir o SDK.

 MinVSVersion: esse atributo é usado pelo Visual Studio para consumir apenas os SDKs que se aplicam a ele.

 Referência: esse atributo deve ser especificado para apenas essas referências que contêm controles. Para obter informações sobre como especificar se uma referência contém controles, consulte abaixo.

As seções a seguir descrevem o que você precisa fazer para implantar um SDK de extensão.

Instalação

SDKs de extensão podem ser instalados para um usuário específico ou para todos os usuários sem especificar uma chave do registro. Para instalar um SDK para todos os usuários, use o seguinte caminho:

%Program Files%\Microsoft SDKs\<target platform>\v<platform version number>\ExtensionSDKs

Para uma instalação específica do usuário, use o seguinte caminho:

%USERPROFILE%\AppData\Local\Microsoft SDKs\<target platform>\v<platform version number>\ExtensionSDKs

Se você quiser usar um local diferente, você deve fazer uma das duas coisas:

  1. Especificá-lo em uma chave do registro:

    HKLM\Software\Microsoft\Microsoft SDKs\<target platform>\v<platform version number>\ExtensionSDKs\<SDKName>\<SDKVersion>\

    e adicione uma subchave (padrão) que tem um valor de <path to SDK><SDKName><SDKVersion>.

  2. Adicione a propriedade MSBuild SDKReferenceDirectoryRoot ao arquivo de projeto. O valor dessa propriedade é uma lista de dois-pontos delimitada semi de diretórios em que residem os SDKs de extensão que você deseja fazer referência.

Layout de instalação

SDKs de extensão têm o seguinte layout de instalação:

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

  1. \< SDKName>\< SDKVersion>: o nome e a versão da extensão do SDK é derivado dos nomes da pasta correspondente no caminho para a raiz do SDK. O MSBuild usa essa identidade para encontrar o SDK no disco e o Visual Studio exibe essa identidade no propriedades janela e Gerenciador de referências caixa de diálogo.

  2. Pasta de referências: os binários que contêm as APIs. Esses podem ser arquivos de metadados do Windows (WinMD) ou assemblies.

  3. Pasta Redist: os arquivos que são necessários para o tempo de execução/depuração e devem são empacotados como parte do aplicativo do usuário. Todos os binários devem ser colocados sob \redist\< config>\< arch>, e os nomes de binários devem ter o seguinte formato para garantir a exclusividade: < empresa>. < produto>. < finalidade>. < extensão>. Por exemplo, Microsoft.Cpp.Build.dll. Todos os arquivos com nomes que entrem em conflito com nomes de arquivo de outros SDKs (por exemplo, arquivos javascript, css, pri, xaml, png e jpg) devem ser colocados sob \redist\< config>\< arch>\< sdkname>\ exceto os arquivos que estão associados com XAML controla. Esses arquivos devem ser colocados sob \redist\< config>\< arch>\< componentname>\.

  4. Pasta DesignTime: os arquivos que são necessários em apenas pré-execução/depuração tempo e não deve ser empacotados como parte do aplicativo do usuário. Esses podem ser documentos XML, bibliotecas, cabeçalhos, binários em tempo de design de ferramentas, MSBuild artefatos e assim por diante. Qualquer SDK que é destinado para consumo por um projeto nativo deve ter uma SDKNamearquivo. Props. O exemplo a seguir mostra um exemplo desse tipo de arquivo.

    <?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>  
    
    
    

    Documentos de referência XML são colocados junto com o arquivo de referência. Por exemplo, o documento de referência XML para o \References\< config>\< arch>\sample.dll assembly é \References\< config>\< arch>\sample.xml, e a versão localizada desse documento é \References\< config>\< arch>\< localidade>\sample.xml.

  5. Pasta de configuração: três subpastas: Debug, varejo e CommonConfiguration. Os autores do SDK podem colocar seus arquivos em CommonConfiguration quando o mesmo conjunto de arquivos do SDK deve ser consumido, independentemente da configuração direcionada pelo consumidor do SDK.

  6. Pasta de arquitetura: há suporte para as seguintes arquiteturas: x86, x64, ARM, neutro. Win32 mapeia para x86 e AnyCPU mapeia para neutro.

Sdkmanifest

Este arquivo descreve como o Visual Studio deve consumir o SDK. Confira o exemplo abaixo.

<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 = “http://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>  

A lista a seguir fornece os elementos do arquivo.

  1. DisplayName: o valor que aparece no Gerenciador de referências, Gerenciador de soluções, pesquisador de objetos e outros locais na interface do usuário para o Visual Studio.

  2. ProductFamilyName: Geral SDK nome do produto. Por exemplo, o Windows Library para JavaScript (WinJS) SDK é chamado "Microsoft.WinJS.1.0" e "Microsoft.WinJS.2.0", que pertencem à mesma família da família de produtos do SDK, "Microsoft". Este atributo permite que o Visual Studio e o MSBuild fazer a conexão. Se esse atributo não existir, o nome do SDK é usado como o nome da família de produtos.

  3. FrameworkIdentity: especifica uma dependência em uma ou mais bibliotecas de componentes Windows que o valor desse atributo é colocado no manifesto do aplicativo de consumo. Esse atributo é aplicável somente a bibliotecas de componentes do Windows.

  4. TargetFramework: especifica os SDKs estão disponíveis no Gerenciador de referências e a caixa de ferramentas. Isso é uma lista delimitada por ponto e vírgula de identificadores do framework de destino, por exemplo "do .NET Framework, version = v 2.0; .NET Framework, versão = v4.5.1". Se várias versões da mesma estrutura de destino for especificadas, o Gerenciador de referência usa a versão especificada mais baixa para fins de filtragem. Por exemplo, se ".NET Framework, versão = v 2.0; .NET Framework, versão = v4.5.1" for especificado, usará o Gerenciador de referência "do .NET Framework, versão = v 2.0". Se um perfil do framework de destino específico for especificado, somente esse perfil será usado o pelo Gerenciador de referência para fins de filtragem. Por exemplo, quando "Silverlight, versão = v 4.0, perfil = WindowsPhone" for especificado, o Gerenciador de referência filtra somente o perfil do Windows Phone; um projeto voltado para o Silverlight 4.0 Framework completo não vê o SDK no Gerenciador de referências.

  5. MinVSVersion: o Visual Studio versão mínima.

  6. MaxPlatformVerson: A versão da plataforma de destino máximo deve ser usada para especificar as versões da plataforma na qual o SDK de extensão não funcionará. Por exemplo, a v 11.0 pacote de tempo de execução do Microsoft Visual C++ deve ser referenciado apenas por projetos do Windows 8. Portanto, MaxPlatformVersion do projeto Windows 8 é 8.0. Isso significa que o Gerenciador de referências filtra pacote de tempo de execução do Microsoft Visual C++ para um projeto do Windows 8.1 e MSBuild gera um erro quando uma Windows 8.1 projeto faz referência a ele. Observação: este elemento tem suporte a partir do Visual Studio 2013.

  7. AppliesTo: especifica os SDKs estão disponíveis no Gerenciador de referências, especificando os tipos de projeto do Visual Studio aplicáveis. Nove valores são reconhecidos: WindowsAppContainer, VisualC, VB, CSharp, WindowsXAML, JavaScript, gerenciado e nativo. O autor do SDK pode usar e ("+'), ou ("|"), não ("! ") operadores para especificar exatamente o escopo dos tipos de projeto que se aplicam ao SDK.

    WindowsAppContainer identifica projetos para Windows Store 8.x aplicativos.

  8. SupportPrefer32Bit: Valores com suporte são "True" e "False". O padrão é "True". Se o valor é definido como "False", o MSBuild retorna um erro para Windows Store 8.x projetos (ou um aviso para projetos de desktop) se o projeto que referencia o SDK tem Prefer32Bit habilitado. Para obter mais informações sobre Prefer32Bit, consulte página de compilação, Project Designer (c#) ou página de compilação, Project Designer (Visual Basic).

  9. SupportedArchitectures: um ponto e vírgula lista delimitada por arquiteturas que o SDK oferece suporte. MSBuild exibirá um aviso se a arquitetura do SDK do destino no projeto consumidor não tem suporte. Se esse atributo não for especificado, o MSBuild nunca exibe esse tipo de aviso.

  10. SupportsMultipleVersions: se esse atributo for definido como erro ou Aviso, MSBuild indica que o mesmo projeto não pode fazer referência a várias versões da mesma família de SDK. Se esse atributo não existe ou está definido como Permitir, MSBuild não exibe este tipo de erro ou aviso.

  11. AppX: Especifica o caminho para os pacotes de aplicativos para a biblioteca de componentes do Windows no disco. Esse valor é passado para o componente de registro da biblioteca de componente do Windows durante a depuração local. A convenção de nomenclatura para o nome do arquivo é < empresa>. < produto>. < arquitetura>. < configuração>. < versão>. AppX. Configuração e arquitetura são opcionais no nome do atributo e o valor do atributo se eles não se aplicam à biblioteca de componente do Windows. Esse valor é aplicável somente a bibliotecas de componentes do Windows.

  12. CopyRedistToSubDirectory: especifica onde os arquivos na pasta \redist devem ser copiados relativo à raiz do pacote de aplicativo (ou seja, o pacote local escolhido no Assistente para criar o pacote de aplicativo) e a raiz de layout de tempo de execução. O local padrão é a raiz do pacote de aplicativo e o layout de F5.

  13. DependsOn: Uma lista de identidades SDK que definem os SDKs do qual depende desse SDK. Esse atributo é exibido no painel de detalhes do Gerenciador de referência.

  14. Mais informações: a URL para a página da web que fornece ajuda e mais informações. Esse valor é usado no link mais informações no painel à direita do Gerenciador de referência.

  15. Tipo de registro: Especifica o registro de WinMD no manifesto do aplicativo e é necessário para o WinMD nativo, que tem uma implementação de contraparte DLL.

  16. Referência de arquivo: especificado para somente as referências que contém controles ou WinMDs nativo. Para obter informações sobre como especificar se uma referência contém controles, consulte especificando o local de itens de caixa de ferramentas abaixo.

O elemento ToolBoxItems do esquema Sdkmanifest Especifica a categoria e o local dos itens de caixa de ferramentas na plataforma e SDKs de extensão. Os exemplos a seguir mostram como especificar locais diferentes. Isso é aplicável às referências WinMD ou DLL.

  1. Coloque controles na categoria de ferramentas padrão.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory = “Toolbox.Default”/>       
    </File>  
    
    
  2. Coloque controles em nome de uma categoria específica.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory= “MyCategoryName”/>  
    </File>  
    
    
  3. Coloque controles em nomes de categoria específica.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory = “Graph”>  
        <ToolboxItems/>  
        <ToolboxItems VSCategory = “Data”>  
        <ToolboxItems />  
    </File>  
    
    
  4. Coloque controles em nomes de categoria diferente no Blend e o 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”>   
        <ToolboxItems />  
    </File>  
    
    
  5. Enumere controles específicos diferente no Blend e o Visual Studio.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory = “Graph”>  
        <ToolboxItems/>  
        <ToolboxItems BlendCategory = “Controls/sample/Graph”>  
        <ToolboxItems/>  
    </File>  
    
    
  6. Enumerar controles específicos e colocá-los no caminho comum do Visual Studio ou apenas no grupo de todos os controles.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory = “Toolbox.Common”>  
        <ToolboxItems />  
        <ToolboxItems VSCategory = “Toolbox.All”>  
        <ToolboxItems />  
    </File>  
    
    
  7. Enumerar controles específicos e mostram apenas um conjunto específico de ChooseItems sem eles sendo na caixa de ferramentas.

    <File Reference = “sample.winmd”>  
        <ToolboxItems VSCategory = “Toolbox.ChooseItemsOnly”>  
        <ToolboxItems />  
    </File>  
    
    

Passo a passo: Criando um SDK usando C++
Passo a passo: Criando um SDK usando c# ou Visual Basic
Gerenciando referências em um projeto

Mostrar: