Este artigo foi traduzido por máquina.
Componentes de Tempo de Execução do Windows
Componentes do Tempo de Execução do Windows no mundo do .NET
O novo tipo de programa conhecido como Windows Store app — otimizado para rodar em dispositivos Windows 8 — tem um padrão ver com uma janela de tela cheia e nenhuma distração cromo, para que o conteúdo é o ponto focal. Apps da loja do Windows oferecem suporte a layouts fluidos que se adaptar e dimensionado para uma variedade de tamanhos de tela e resoluções. Eles fornecem uma experiência de primeiro toque, proporcionando suporte completo para o tradicional teclado e mouse.
Executar aplicativos de armazenamento do Windows em um novo conjunto de APIs chamado o tempo de execução do Windows (WinRT). O tempo de execução do Windows expõe os componentes que são construídos como parte do sistema operacional Windows 8 juntamente com componentes de terceiros, que você pode desenvolver-se. Embora alguns componentes de tempo de execução do Windows core são acessíveis a partir de aplicativos de desktop, componentes de tempo de execução do Windows de terceiros apenas estão disponíveis dentro do ambiente do Windows 8. Tipos de WinRT são descritos usando arquivos de metadados WinRT que têm a extensão de .winmd. Esses arquivos são codificados usando o mesmo padrão usa a Microsoft .NET Framework para fornecer definições de metadados e semântica para classes, ECMA-335 (consulte bit.ly/sLILI).
Você pode navegar rapidamente para as definições de tipo em uma máquina Windows 8, alterar para o diretório que contém arquivos de sistema para o Windows (geralmente c:\windows\system32). Uma pasta dentro dessa directory chamado WinMetadata contém todas as definições de tipo. Você pode usar o utilitário ILDASM. exe para explorar os tipos. Abra um prompt de comando Visual Studio 2012, navegue até a pasta c:\windows\system32\WinMetadata e digite o seguinte na linha de comando:
ILDASM. exe windows.web.winmd
Você deverá ver um resultado semelhante ao Figura 1. Você pode usar o utilitário ILDASM. exe para inspecionar todos os namespaces e tipos definidos para que determinado componente de tempo de execução do Windows.
.png)
Figura 1 WinRT tipos de inspeção
É interessante notar que não há nenhum código contido dentro do arquivo; apenas informações de metadados estão disponíveis. O componente é parte do sistema operacional subjacente. É mais provável escrito usando código nativo. Uma característica única chamada projeção da língua permite que componentes de tempo de execução Windows (nativo e gerenciado) ser acessado a partir de qualquer linguagem que suporta o desenvolvimento de app Store do Windows.
Projeção e mapeamento
Muitas linguagens, como c#, Visual Basic, C++ e JavaScript, foram atualizadas com o Windows 8 para suportar a projeção de língua. Isso permite que os componentes de tempo de execução Windows ser acessado de forma natural usando vários idiomas. Projeção manipula expondo um tipo WinRT como um objeto ou uma classe que é nativo para o idioma que está sendo usado para desenvolver o app Store do Windows. O código a seguir acessa um componente de tempo de execução do Windows nativo diretamente de uma app Store do Windows construído usando c#:
var ui = new CameraCaptureUI();
O CameraCaptureUI é um componente de tempo de execução do Windows. O componente não é um tipo gerenciado c#, mas pode ser facilmente acessado e referenciada a partir de dentro do código c# como se fosse. Isto é porque o CLR gera automaticamente um Runtime Callable Wrapper (RCW) para o componente de tempo de execução do Windows usando seus metadados e faz com que ele apareça como um tipo nativo de CLR para código gerenciado. Para saber mais sobre este assunto, consulte o artigo da biblioteca MSDN, "Runtime Callable Wrapper" em bit.ly/PTiAly. O RCW torna fácil e simples de interagir com esses componentes. O inverso também é verdadeiro. Permite projeção que um componente de tempo de execução do Windows criado com código gerenciado a ser referenciado como um C++ tipo de código nativo e como um objeto de JavaScript a partir de projetos HTML/JavaScript.
Tipos fundamentais aparecem automaticamente como tipos de c#. O tempo de execução do Windows tem um tipo ELEMENT_TYPE_STRING que aparece no código .NET como um String objeto. A scalar ELEMENT_TYPE_I4 aparece como um Int32. O CLR também tomar certos tipos de WinRT e mapeá-los para aparecer no código como seus equivalentes em .NET. Por exemplo, o tipo de WinRT para uma coleção de tamanho fixo é IVector <T>, mas este tipo automaticamente aparecerá como um IList <T> no código do .NET. Um HRESULT WinRT aparece no .NET Framework como um tipo de exceção. O CLR será automaticamente empacotar esses tipos entre as representações gerenciados e nativos. Alguns tipos, como córregos, podem ser convertidos explicitamente usando um conjunto de métodos de extensão fornecido pelo CLR. Para uma lista completa dos tipos que são mapeados, desta forma, consulte o tópico do MSDN Dev Center, ".NET Framework mapeamentos do WinRT tipos," em bit.ly/PECJ1W.
Estes recursos incorporados permitem aos desenvolvedores criar seus próprios componentes de tempo de execução do Windows usando código gerenciado com c# e Visual Basic. Visual Studio 2012 fornece um modelo para criar componentes de tempo de execução do Windows do Visual Basic, c# e C++. Esses componentes podem ser consumidos e chamados a partir de qualquer outra linguagem que suporta o Windows Runtime, incluindo JavaScript. Por esse motivo, você deve seguir algumas regras específicas para criar um componente de tempo de execução do Windows em c#.
Jogar pelas regras
Em geral, as regras para a criação de tipos de WinRT em c# referem-se a qualquer publicamente visível tipos e membros de que seu componente fornece. As restrições existem porque o componente de tempo de execução do Windows deve ser vinculado pelo sistema de tipo WinRT. O conjunto completo de regras está listado no tópico "Criando Windows Runtime componentes em c# e Visual Basic," MSDN Dev Center em bit.ly/OWDe2A. Os campos, parâmetros e valores de retorno que você exponha deve ser WinRT tipos (ele é bom para expor tipos .NET automaticamente mapeados para tipos de WinRT). Você pode criar seus próprios tipos de WinRT para expor esses tipos, desde que por sua vez, siga o mesmo conjunto de regras.
Outra restrição é que qualquer públicas classes ou interfaces que você expor não podem ser genérico ou implementar qualquer interface não WinRT. Eles não devem derivar de tipos de não-WinRT. O namespace raiz para componentes de tempo de execução do Windows deve coincidir com o nome do assembly, que por sua vez, não é possível iniciar com "Windows". Estruturas públicas também são restritas apenas ter campos públicos que são tipos de valor. Polimorfismo não está disponível para tipos WinRT e o mais próximo que você pode vir é implementar interfaces WinRT; você deve declarar como sealed quaisquer classes que são expostos publicamente pelo seu componente de tempo de execução do Windows.
Essas restrições podem ser motivo para considerar uma abordagem alternativa para integração de componentes dentro de seus aplicativos, especialmente se você está lidando com código legado que exigiria a refatoração significativa. Vou discutir possíveis métodos alternativos mais tarde. As restrições são importantes para garantir que os componentes de tempo de execução do Windows podem funcionar adequadamente dentro do ambiente do WinRT e pode ser referenciados e chamados de todos os ambientes da linguagem, incluindo C++ e JavaScript.
O gerador de Thumbnail
Um aplicativo simples irá demonstrar como criar um componente de tempo de execução gerenciado do Windows com c# e consumi-lo de uma app Store Windows construído com c#, JavaScript ou C++. O componente aceita uma referência a um arquivo de imagem passada pela interface WinRT IStorageFile. Ele cria uma miniatura de 100 x 100 pixels da imagem e salva em armazenamento local na app Store do Windows. Finalmente, ele retorna um URI que aponta para a miniatura. As etapas envolvidas incluem:
- Crie a solução no Visual Studio de 2012.
- Construa o componente de tempo de execução do Windows.
- Crie o projeto específico do idioma em c#, JavaScript ou C++.
- Referência do componente de tempo de execução do Windows.
- Configure a interface do usuário para cada projeto para permitir que o usuário escolher uma imagem.
- Exiba a imagem.
- Chame o componente de tempo de execução do Windows.
- Exiba a miniatura.
Criar o projeto e solução
De dentro Visual Studio 2012, você começa especificando o idioma de sua escolha (no caso, c#) e escolher os modelos de app Store do Windows. Um modelo existe especificamente para a geração de componentes de tempo de execução do Windows. Selecionei este modelo e criou um componente chamado ThumbnailLibrary com uma solução de mesmo nome, como mostrado na Figura 2.
.png)
Figura 2 Criando o projeto de componente de tempo de execução do Windows
Para este exemplo, criei uma classe única, chamada ThumbnailMaker. Um método particular retorna uma tarefa para gerar assincronamente a miniatura:
private static async Task<Uri> GenerateThumbnail(IStorageFile file)
{
}
O primeiro passo dentro do método é abrir o arquivo de armazenamento e usar o WinRT BitmapDecoder para decodificar o fluxo de imagem:
using (var fileStream = await file.OpenReadAsync())
{
var decoder = await BitmapDecoder.CreateAsync(fileStream);
}
Em seguida, um arquivo é criado no armazenamento local para o app segurar a miniatura. Ele será chamado de "miniatura", com a mesma extensão de arquivo de origem. A opção para gerar um nome exclusivo irá garantir que várias miniaturas podem ser geradas sem substituir operações anteriores:
var thumbFile = await ApplicationData.Current.LocalFolder.CreateFileAsync(
string.Format("thumbnail{0}", file.FileType),
CreationCollisionOption.GenerateUniqueName);
Um codificador é criado a partir do fluxo decodificado. Ele simplesmente dimensiona o bitmap para 100x100 pixels e, em seguida, grava-lo no sistema de arquivos:
using (var outputStream =
await thumbFile.OpenAsync(FileAccessMode.ReadWrite))
{
var encoder = await BitmapEncoder.CreateForTranscodingAsync(
outputStream,
decoder);
encoder.BitmapTransform.ScaledHeight = 100;
encoder.BitmapTransform.ScaledWidth = 100;
await encoder.FlushAsync();
}
O último passo é construir uma URL que aponta para o arquivo. O prefixo ms-appdata especial é usado para fazer referência os arquivos no armazenamento local. Para saber mais sobre como conteúdo de referência usando URIs, leia o tópico do MSDN Dev Center, "Como a referência conteúdo" em bit.ly/SS711o. Embora o tópico é para HTML e JavaScript, a Convenção usada para acessar recursos é a mesma independentemente de qual opção de linguagem você está usando:
const string URI_LOCAL = "ms-appdata:///Local/{0}";
var storageUrl = string.Format(URI_LOCAL, thumbFile.Name);
return new Uri(storageUrl, UriKind.Absolute);
Componentes de tempo de execução do Windows escrito em c# pode usar qualquer funcionalidade do .NET que é permitida para o perfil de app Store do Windows. Como mencionado anteriormente, no entanto, interfaces e tipos públicos devem apenas expor tipos WinRT. Porque a tarefa não é um tipo de WinRT válido, o método público para o componente deve expor o WinRT IAsyncOperation <T> tipo em vez disso. Felizmente, um método de extensão existe para converter facilmente o tipo de tarefa de .NET para o tipo de WinRT IAsyncOperation, como mostrado aqui:
public IAsyncOperation<Uri> GenerateThumbnailAsync(IStorageFile file)
{
return GenerateThumbnail(file).AsAsyncOperation();
}
Com o componente agora completa, você pode compilar para torná-lo pronto para o consumo de armazenamento Windows apps.
Sob o capô: Metadados
Construir o componente de tempo de execução do Windows e, em seguida, navegue até o diretório de saída clicando no nome do projeto no Solution Explorer e escolha "Abrir a pasta no Windows Explorer." Quando você navegar para o subdiretório bin/Debug, você encontrará que um arquivo de metadados tem sido gerado para o componente chamado ThumbnailLibary.winmd. Se você abrir o arquivo com o ildasm. exe, você verá que uma interface foi gerada para o componente com um tipo de retorno:
Windows.Foundation.IAsyncOperation <Windows.Foundation.Uri>
Esses são os tipos de WinRT que foram mapeados para o componente. É possível também inspecionar os metadados e ver como o CLR WinRT tipos de projetos. Abra o mesmo arquivo de metadados com a extensão/projeto especial como este:
/Project ILDASM. exe ThumbnailLibrary.winmd
O tipo de retorno agora aparece como:
Windows.Foundation.IAsyncOperation <System.Uri>
Observe que a versão do WinRT do URI é projectada para o equivalente de .NET. A assinatura do método expõe todos os tipos de WinRT válido para Windows Store apps para consumir, mas de código gerenciado tipos serão exibidos como classes .NET. Você pode usar a extensão/projeto para inspecionar como projeção afetará a assinatura dos componentes de tempo de execução do Windows gerenciado e não gerenciado.
Consumir de c#
Consumir o componente de c# deve parecer familiar, porque ele não é diferente de fazer referência a uma biblioteca de classe. Observe que não há nenhuma razão para criar um componente de tempo de execução do Windows se o seu único alvo é outro código gerenciado. Você simplesmente referenciar o projeto WinRT e, em seguida, consumir as classes como se fosse de uma biblioteca de classe c# comum. No código de exemplo, o projeto CSharpThumbnails tem uma referência para o ThumbnailLibrary. O XAML para a página principal define um botão para o usuário escolher uma fotografia e contém duas imagens para hospedar a imagem original e a versão miniatura. Figura 3 mostra a marcação básica do XAML.
Figura 3 XAML para App Store Windows construído com c#
<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
</Grid.RowDefinitions>
<TextBlock
Text="Tap the button below to choose an image to generate a thumbnail."
Style="{StaticResource BodyTextStyle}"
Margin="12"/>
<Button Content="Pick Image" Grid.Row="1" Margin="12"
Click="Button_Click_1"/>
<TextBlock Text="Thumbnail:" Style="{StaticResource BodyTextStyle}"
Grid.Row="2" Margin="12"/>
<Image x:Name="ThumbnailImage" HorizontalAlignment="Left" Stretch="None"
Grid.Row="3" Margin="12"/>
<TextBlock Text="Source Image:" Style="{StaticResource BodyTextStyle}"
Grid.Row="4" Margin="12"/>
<Image x:Name="SourceImage" HorizontalAlignment="Left" Stretch="None"
Grid.Row="5" Margin="12"/>
</Grid>
O code-behind cria uma instância do componente WinRT FileOpenPicker e configura-lo para procurar imagens:
var openPicker = new FileOpenPicker
{
ViewMode = PickerViewMode.Thumbnail,
SuggestedStartLocation = PickerLocationId.PicturesLibrary
};
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");
openPicker.FileTypeFilter.Add(".png");
O selecionador é chamado e uma simples caixa de diálogo será exibida se não arquivos válidos são encontrados:
var file = await openPicker.PickSingleFileAsync();
if (file == null)
{
var dialog = new MessageDialog("No image was selected.");
await dialog.ShowAsync();
return;
}
A imagem de origem é então fios para exibição. O arquivo é passado para o componente de tempo de execução do Windows para gerar um thumbnail e URI passado para trás é usado para definir a imagem em miniatura para exibir:
using (var fileStream = await file.OpenReadAsync())
{
SourceImage.Source = LoadBitmap(fileStream);
var maker = new ThumbnailMaker();
var stream = RandomAccessStreamReference
.CreateFromUri(await maker.GenerateThumbnailAsync(file));
var bitmapImage = new BitmapImage();
bitmapImage.SetSource(await stream.OpenReadAsync());
ThumbnailImage.Source = bitmapImage;
}
Figura 4 mostra o resultado de executar isso contra uma foto que tirei de uma abóbora que esculpido.
.png)
Figura 4 App Store Windows miniatura construído usando c#
Consumir de JavaScript
Ao contrário de regulares c# classe bibliotecas, componentes de tempo de execução do Windows podem ser chamados de qualquer linguagem com suporte para a criação de apps da loja do Windows (núcleo componentes de tempo de execução do Windows que fazem parte do sistema operacional podem ser chamados de aplicativos de desktop também). Para ver isso em ação, você pode criar a miniatura app usando HTML e JavaScript. Este projeto é chamado JavaScriptThumbnails no download de código de exemplo que acompanha. O primeiro passo é criar um aplicativo vazio usando o modelo de armazenamento do Windows em branco para aplicativos criados usando JavaScript. Uma vez que o modelo foi criado, você pode usar a marcação HTML simples para definir a página usando o arquivo default. html existente:
<p>Tap the button below to choose an image to generate a thumbnail.</p>
<button id="pick">Pick Image</button>
<br/><br/>
<p>Thumbnail:</p>
<img id="thumbnail" src="images/logo.png" alt="Thumbnail"/>
<p>Source Image:</p>
<img id="sourceImage" src="images/logo.png" alt="Image"/>
Em seguida, adicione uma referência ao projeto WinRT (ThumbnailLibrary) como você faria para um projeto c# regular. Construa o projeto de modo que você pode usar o IntelliSense para o componente recentemente referenciado. Você pode referenciar o código-fonte do projeto ver o JavaScript equivalente para abrir o seletor de arquivo e selecionar a imagem. Para criar uma instância do componente de tempo de execução gerenciado do Windows, gerar o thumbnail e exibi-lo para o usuário, use o seguinte JavaScript:
var thumb = new ThumbnailLibrary.ThumbnailMaker();
thumb.generateThumbnailAsync(file).then(function (fileUrl) {
var thumbImage = document.getElementById("thumbnail");
thumbImage.src = fileUrl.rawUri;
thumbImage.alt = thumbImage.src;
});
Como você pode ver, a chamada da API é quase idêntica ao usado no projeto c#. Projeção alterado automaticamente a assinatura do método de caso de Pascal para camel case (a chamada para gerar o thumbnail começa com um caractere minúsculo, como é o costume comum em código JavaScript), e uma biblioteca especial chamada "promessas" é usada para manipular a natureza assíncrona do código usando uma instrução, em seguida, ou feita. Você pode aprender mais sobre promessas lendo o tópico do MSDN Dev Center, "Quickstart: Usando promessas,"em bit.ly/OeWQCQ. A tag de imagem suporta URLs fora da caixa, então o URL passado volta do componente de tempo de execução do Windows é simplesmente definir diretamente para o atributo src da imagem.
Uma ressalva importante para o uso de componentes gerenciados em código JavaScript é que você não pode depurar JavaScript e código gerenciado ao mesmo tempo. Se você precisar depurar seu componente, clique no projeto e escolha a aba de depuração e, em seguida, selecione uma opção de depuração que inclui código gerenciado. Isso é mostrado no Figura 5.
.png)
Figura 5 definindo as opções de depuração para um projeto de JavaScript
Consumir de C++
Você também pode consumir gerenciado Windows componentes de tempo de execução de projetos nativos. C++ compartilha o mesmo motor de renderização como c#, assim o projeto CPlusPlusThumbnails tem o mesmo XAML como o projeto de CSharpThumbnails. O code-behind é diferente porque o projeto usa a opção de linguagem C++ nativa. C++ usa uma biblioteca de simultaneidade especial para lidar com operações assíncronas. Você pode aprender mais sobre esta biblioteca lendo o tópico do MSDN Dev Center, "Assíncrono de programação em C++," em bit.ly/MUEqnR. O código resultante é semelhante as promessas que você viu nas versões do JavaScript:
ThumbnailMaker^ maker = ref new ThumbnailMaker();
create_task(maker->GenerateThumbnailAsync(file)).then([this](Uri^ uri)
{
RandomAccessStreamReference^ thumbnailStream =
RandomAccessStreamReference::CreateFromUri(uri);
create_task(thumbnailStream->OpenReadAsync()).then([this](
IRandomAccessStream^ imageStream) {
auto image = ref new BitmapImage();
image->SetSource((IRandomAccessStream^)imageStream);
ThumbnailImage->Source = image;
});
});
Quando você executa o aplicativo, você encontrará que parece e se comporta exatamente como a versão de c#.
Entender o custo
Criar componentes de tempo de execução do Windows usando linguagens gerenciadas é um recurso poderoso. Esta característica têm um custo, e é importante entender o custo quando você está usando em projetos. Apps da loja do Windows construídos usando código nativo não exigem que o CLR executar. Esses aplicativos podem executar diretamente no ambiente do Windows 8. Da mesma forma, aplicativos desenvolvidos usando JavaScript também não exigem uma dependência no CLR. Eles contam com o motor de renderização Trident e Chakra JavaScript engine (os mesmos motores que conduzem do Internet Explorer 10) para processar HTML e CSS e interpretar o código JavaScript. Apps da loja do Windows construídos com JavaScript podem chamar componentes de tempo de execução nativa do Windows diretamente, mas quando chamam os componentes de tempo de execução gerenciados do Windows, eles assumem uma dependência para o CLR.
O código escrito para o componente de tempo de execução gerenciado do Windows será compilado just-in-time (JIT) quando ele é acessado pela primeira pelo compilador JIT do CLR. Isto pode causar algum tempo de atraso na primeira ele é acessado. Um serviço de pré-compilação chamado NGen alças compilar módulos instalados no dispositivo, mas pode demorar até um dia inteiro eventualmente compilar todos os módulos em um pacote, uma vez que foi instalado. O CLR também gerencia a memória, realizando a coleta de lixo. O coletor de lixo (GC) pilha se divide em três gerações e recolhe apenas partes da pilha usando um algoritmo criado para otimizar o desempenho.
O GC pode pausar seu aplicativo enquanto ele está executando o trabalho. Isso muitas vezes só apresenta um ligeiro atraso que não é reconhecível para o usuário final, e mais intensas operações de coleta de lixo muitas vezes podem ser executado em segundo plano. Se você tem uma pilha grande o suficiente (quando a parte gerenciada do seu código faz referência a centenas de megabytes ou mais objetos de memória), coleta de lixo pode pausar o app tempo suficiente para o usuário perceber a falta de capacidade de resposta.
A maioria destas considerações já está em vigor quando você estiver criando um aplicativo de armazenamento do Windows gerenciado. Código gerenciado adicionar novas preocupações quando ele está adicionando um app Store Windows construído com C++ ou JavaScript. É importante reconhecer que seu aplicativo irá consumir CPU adicional e gerenciado de memória quando você introduzir componentes. Pode também levar um hit de desempenho reconhecível, dependendo do componente (embora muitos apps assumir referências gerenciadas sem nenhum impacto perceptível). A vantagem é que você não precisa se preocupar com o gerenciamento de memória-se e, é claro, você pode aproveitar as habilidades e código herdado.
Alternativas para projetos gerenciados
Se você estiver criando aplicativos Windows Store usando código gerenciado (c# ou Visual Basic), você tem várias alternativas para criar componentes de tempo de execução do Windows que não tem as mesmas restrições. Você pode facilmente criar componentes reutilizáveis usando uma biblioteca de classe c# simples. Se a biblioteca de classe é criada para apps da loja do Windows, você pode referenciar o projeto de seu próprio app Store do Windows. A criação de uma biblioteca de classe também remove as restrições de ter que expor somente os tipos de WinRT e não ser capaz de usar os recursos que não fazem parte do sistema de tipo WinRT, tais como genéricos.
Outra alternativa a considerar é a biblioteca de classe portátil (PCL). Este é um tipo especial de biblioteca de classes que pode ser referenciado a partir de uma variedade de plataformas sem recompilar. Use esta opção se você tem o código que você deseja compartilhar entre outras plataformas, como Windows Presentation Foundation, Silverlight e Windows Phone — e sua app Store do Windows. Você pode aprender mais sobre o PCL por ler a minha série de blog de três partes, "Entendendo o portátil biblioteca por perseguir ICommand," em bit.ly/pclasslib.
Quando seu componente inclui mais do que apenas o código, você pode considerar criando um SDK de extensão. Esta é uma forma especial de SDK que Visual Studio 2012 pode tratar como um único item. O pacote pode incluir o código-fonte, bens, arquivos e até mesmo binários, incluindo componentes de tempo de execução do Windows. Você também pode criar extensões de tempo de design para torná-lo mais fácil de consumir e usar seu componente de dentro de Visual Studio de 2012. SDKs de extensão não podem ser postados para o armazenamento do Windows porque eles não são auto-suficientes apps. Você pode aprender mais sobre extensão SDKs lendo o artigo da biblioteca MSDN, "como: Criar um Kit de desenvolvimento de Software,"em bit.ly/L9Ognt.
Quando criar componentes de tempo de execução gerenciado do Windows
Com tantas alternativas possíveis, nunca faz sentido criar componentes de tempo de execução do Windows usando código gerenciado? Sim, mas considere as seguintes perguntas. A primeira pergunta a fazer é se você precisa de seus componentes para ser referenciado a partir Windows Store apps escritos usando JavaScript ou código nativo usando C++. Se isso não for o caso, não há nenhuma razão para usar um componente de tempo de execução do Windows quando outras opções e bibliotecas de classe funcionará em vez disso. Se este for o caso, você deve criar um componente de tempo de execução do Windows para ser consumíveis de todas as opções de idioma disponíveis.
A próxima pergunta é se você deve criar seu componente em C++ ou usar o código gerenciado. Há um número de razões para usar o código gerenciado. Uma razão pode ser que sua equipe é mais experiente em c# ou Visual Basic do que em C++ e pode aproveitar habilidades existentes para construir os componentes. Outra razão pode ser que você tenha escritos em uma linguagem gerenciada que será mais fácil, a porta se você mantiver a mesma seleção de idioma de algoritmos existentes. Há algumas tarefas que podem ser mais fácil de escrever e manter usando linguagens gerenciadas e bibliotecas de classe em vez de usar o código nativo, e equipes que são usados para o desenvolvimento em linguagens gerenciadas será muito mais produtivas.
Resumindo, neste artigo que você aprendeu que você pode criar componentes reutilizáveis de tempo de execução Windows usando gerenciado código de Visual Basic e c#. Esses componentes podem ser facilmente referenciados e consumidos de armazenamento Windows aplicativos escritos em qualquer linguagem, incluindo JavaScript e C++. Embora seja importante compreender as regras para a criação de componentes de tempo de execução do Windows e o impacto da escolha de usar código gerenciado, esta opção fornece uma oportunidade única para usar a linguagem de sua escolha e aproveitar o código existente para criar componentes que podem ser consumidos por todos os apps da loja do Windows.
Jeremy Likness *é consultor principal da Wintellect LLC em Atlanta. Ele é MVP Silverlight da Microsoft três anos e autor de vários livros, incluindo o próximo "Building Windows 8 aplicações com c# e XAML" (Addison-Wesley Professional, 2012). Saiba mais em linha em bit.ly/win8design e siga o seu blog em csharperimage.jeremylikness.com. *
Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Layla Driscoll, Shawn Farkas, John Garland, Jeff Prosise e Jeffrey Richter