Cet article a fait l'objet d'une traduction automatique.

Composants Windows Runtime

Composants Windows Runtime dans un environnement .NET

Jeremy Likness

Télécharger l'exemple de code

Le nouveau type de programme, appelé un app Store Windows — optimisé pour fonctionner sur des appareils Windows 8 — a un défaut Découvre avec une fenêtre plein écran et sans chrome distrayant, donc le contenu est le point focal.Apps Store Windows prend en charge des mises en page fluides qui s'adaptent et s'adapter à une variété de tailles d'écran et résolutions.Ils fournissent une expérience tactile en premier, tout en offrant un support complet pour la souris et le clavier traditionnel.

Apps Store Windows exécutent sur un nouvel ensemble d'API appelé Windows Runtime (WinRT).Le Runtime Windows expose les composants qui sont générés dans le cadre du système d'exploitation Windows 8 ainsi que des composants tiers, que vous pouvez développer vous-même.Bien que certains composants d'exécution principaux Windows sont accessibles à partir des applications de bureau, composants d'exécution Windows tiers ne sont plus disponibles dans l'environnement Windows 8.WinRT types sont décrits à l'aide de fichiers de métadonnées WinRT qui portent l'extension .winmd.Ces fichiers sont encodés à l'aide de la même norme l'utilise Microsoft .NET Framework pour fournir des définitions de métadonnées et la sémantique des classes, ECMA-335 (voir bit.ly/sLILI).

Vous pouvez naviguer rapidement vers les définitions de type sur une machine Windows 8 en modifiant le répertoire qui contient les fichiers système de Windows (généralement c:\windows\system32).Un dossier dans cette direc­tory appelé WinMetadata contient toutes les définitions de type.Vous pouvez utiliser l'utilitaire ILDasm.exe pour explorer les types.Ouvrez une invite de commandes Visual Studio 2012, accédez au dossier c:\windows\system32\WinMetadata et tapez ce qui suit dans la ligne de commande :

Ildasm.exe windows.web.winmd

Vous devriez voir un résultat similaire à celui Figure 1. Vous pouvez utiliser l'utilitaire ILDasm.exe pour inspecter tous les espaces de noms et de types définis pour ce composant particulier de Runtime Windows.

Inspecting WinRT Types
Figure 1 inspection WinRT Types

Ce qui est intéressant à noter est qu'il n'y a pas de code contenus dans le fichier ; uniquement les informations de métadonnées sont disponibles. Le composant fait partie du système d'exploitation sous-jacent. Il est fort probable, écrit à l'aide de code natif. Une fonctionnalité unique appelée projection langue permet aux composants d'exécution Windows (natif et managé) accessibles à partir de n'importe quel langage qui prend en charge le développement d'applications Windows Store.

Projection et cartographie

Nombreux langages, notamment c#, Visual Basic, C++ et JavaScript, ont été mis à jour avec Windows 8 pour prendre en charge la projection de la langue. Cela permet aux composants d'exécution Windows d'accéder de façon naturelle à l'aide de plusieurs langues. Projection gère exposer un type WinRT comme un objet ou une classe qui est le langage utilisé pour développer le app Store Windows natif. Le code suivant accède à un composant d'exécution native Windows directement depuis un app Store Windows construit à l'aide de c# :

var ui = new CameraCaptureUI();

Le CameraCaptureUI est un composant d'exécution de Windows. Le composant n'est pas un type managé c#, mais il est facilement accessible et référencé à partir du code c# comme s'il s'agissait. C'est parce que le Common Language Runtime génère automatiquement un Runtime Callable Wrapper (RCW) pour le composant d'exécution de Windows à l'aide de ses métadonnées et les causes qu'il apparaisse comme un type CLR natif au code managé. Pour plus d'informations sur ceci, consultez l'article de MSDN Library, « Runtime Callable Wrapper, » à bit.ly/PTiAly. Le wrapper RCW rend facile et simple d'interagir avec ces composants. L’inverse est également vrai. Projection active qu'un composant Runtime Windows créé avec du code managé à être référencé comme un C++ de type de code natif et comme un objet JavaScript à partir de projets HTML/JavaScript.

Types fondamentaux apparaissent automatiquement sous forme de types c#. Le Runtime Windows comporte un type de valeur ELEMENT_TYPE_STRING qui apparaît dans le code .NET en tant qu'objet String. Le scalaire ELEMENT_TYPE_I4 apparaît en tant que Int32. Le CLR va aussi prendre certains types de WinRT et carte qu'ils apparaissent dans le code comme leurs équivalents .NET. Par exemple, le type WinRT pour une collection de taille fixe est IVector <T>, mais ce type apparaîtra automatiquement comme un IList <T> dans le code .NET. Un HRESULT WinRT apparaît dans le .NET Framework comme un type d'Exception. Le Common Language Runtime doit marshaler automatiquement ces types entre les représentations managées et natives. Certains types, tels que les cours d'eau, peuvent être convertis explicitement en utilisant un ensemble de méthodes d'extension fournie par le CLR. Pour une liste complète des types mappés dans ce mode, consultez la rubrique MSDN Dev Center, « Types .NET Framework mappages de WinRT, » à bit.ly/PECJ1W.

Ces fonctionnalités intégrées permettent aux développeurs de créer leurs propres composants d'exécution Windows à l'aide de code managé avec c# et Visual Basic. Visual Studio 2012 fournit un modèle pour créer des composants d'exécution Windows de Visual Basic, c# et C++. Ces composants peuvent être consommés et appelées à partir de n'importe quel autre langage qui prend en charge l'exécution de Windows, y compris de JavaScript. Pour cette raison, vous devez suivre certaines règles spécifiques pour créer un composant d'exécution de Windows en c#.

Les règles du jeu

En général, les règles pour la création de types WinRT en c# se rapportent à tous les types visibles publiquement et votre composant fournit des membres. Les restrictions existent parce que le composant d'exécution de Windows doivent être lié par le système de type WinRT. L'ensemble des règles est répertoriée dans la rubrique MSDN Dev Center, "création Windows Runtime composants dans c# et Visual Basic," à bit.ly/OWDe2A. Les champs, les paramètres et les valeurs de retour qui vous exposez doivent tous être WinRT types (c'est bien d'exposer des types .NET sont automatiquement mappés aux types de WinRT). Vous pouvez créer vos propres types de WinRT pour exposer ces types, a fourni à son tour, suivre le même ensemble de règles.

Une autre restriction est que toute les classes publiques ou vous exposer des interfaces ne peuvent être génériques ou implémenter n'importe quelle interface non-WinRT. Ils ne doivent pas dériver de types non-WinRT. L'espace de noms racine pour les composants d'exécution Windows doit correspondre au nom de l'assembly, qui à son tour ne peut pas commencer par « Windows ». Structures publiques sont également restreints uniquement avoir des champs publics qui sont des types valeur. Polymorphisme n'est pas disponible pour les types WinRT, et le plus proche vous pouvez venir implémente WinRT interfaces ; comme sealed, vous devez déclarer toutes les classes qui sont exposés publiquement par votre composant d'exécution de Windows.

Ces restrictions pourraient être raison d'envisager une approche alternative à l'intégration de composants au sein de vos applications, en particulier si vous faites affaire avec du code hérité qui exigerait la refactorisation de changement significatif. J'aborderai plus tard des approches alternatives possibles. Les restrictions sont importantes pour s'assurer que les composants d'exécution Windows peut fonctionner correctement dans l'environnement WinRT et peut être référencés et appelées à partir de tous les environnements linguistiques, y compris C++ et JavaScript.

Le générateur miniature

Une application simple va vous montrer comment créer un composant d'exécution managé Windows avec c# et le consommer d'un app Store Windows construit avec c#, JavaScript ou C++. Le composant accepte une référence à un fichier image transmise par l'interface WinRT IStorageFile. Ensuite, il crée une miniature de 100 x 100 pixels de l'image et enregistre dans le stockage local de l'app Store de Windows. Enfin, elle retourne un URI qui pointe vers la vignette. Les étapes comprennent :

  1. Créer la solution dans Visual Studio 2012.
  2. Générez le composant d'exécution de Windows.
  3. Créer le projet spécifique au langage c#, JavaScript ou C++.
  4. Référencer le composant d'exécution de Windows.
  5. Configurer l'interface utilisateur pour chaque projet, pour permettre à l'utilisateur de choisir une image.
  6. Afficher l'image.
  7. Appeler le composant d'exécution de Windows.
  8. Afficher la miniature.

Créer la Solution et projet

De dans Visual Studio 2012, vous commencez en spécifiant la langue de votre choix (dans ce cas, C#) et en choisissant les modèles d'app Store Windows. Il existe un modèle spécifiquement pour générer des composants d'exécution de Windows. J'ai choisi ce modèle et créé un composant appelé ThumbnailLibrary avec une solution du même nom, comme indiqué dans Figure 2.

Creating the Windows Runtime Component Project
Figure 2 création du projet de composant d'exécution de Windows

Pour cet exemple, j'ai créé une classe simple appelée ThumbnailMaker. Une méthode privée renvoie une tâche pour générer asynchrone la miniature :

private static async Task<Uri> GenerateThumbnail(IStorageFile file)
{
}

La première étape dans la méthode consiste à ouvrir le fichier de stockage et utilisez le WinRT BitmapDecoder pour décoder le flux de l'image :

using (var fileStream = await file.OpenReadAsync())
{
  var decoder = await BitmapDecoder.CreateAsync(fileStream);
}

Ensuite, un fichier est créé dans le stockage local pour le $ $ etAPP de tenir la miniature. Il sera nommé « thumbnail », avec la même extension que le fichier source. L'option pour générer un nom unique feront en sorte que plusieurs vignettes peuvent être générés sans remplacer les opérations précédentes.

var thumbFile = await ApplicationData.Current.LocalFolder.CreateFileAsync(
  string.Format("thumbnail{0}", file.FileType),
  CreationCollisionOption.GenerateUniqueName);

Un encodeur est créé à partir du flux décodé. Il met simplement à l'échelle l'image bitmap à 100 x 100 pixels et puis l'écrit dans le système de fichiers :

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();
}

La dernière étape consiste à construire une URL qui pointe vers le fichier. Le préfixe ms-appdata spécial est utilisé pour référencer les fichiers dans le stockage local. Pour en savoir plus sur la façon d'utiliser des URI, lisez la rubrique MSDN Dev Center, « Comment au contenu de référence, » le contenu de référence à bit.ly/SS711o. Bien que le sujet est pour HTML et JavaScript, la convention utilisée pour accéder à des ressources est la même peu importe quelle option de langue que vous utilisez :

const string URI_LOCAL = "ms-appdata:///Local/{0}";
var storageUrl = string.Format(URI_LOCAL, thumbFile.Name);
return new Uri(storageUrl, UriKind.Absolute);

Composants d'exécution Windows écrit en c# peut utiliser toutes les fonctionnalités .NET qui sont autorisée pour le profil de app Store Windows. Comme mentionné précédemment, toutefois, interfaces et types publics doivent seulement exposer WinRT types. Parce que la tâche n'est pas un type WinRT valide, la méthode publique pour le composant doit exposer le WinRT IAsyncOperation <T> Tapez à la place. Heureusement, une méthode d'extension existe pour convertir facilement le type de tâche .NET WinRT IAsyncOperation type, comme illustré ici :

public IAsyncOperation<Uri> GenerateThumbnailAsync(IStorageFile file)
{
  return GenerateThumbnail(file).AsAsyncOperation();            
}

Avec le composant maintenant terminée, vous pouvez compiler il pour le rendre prêt à la consommation depuis Windows Store apps.

Sous le capot : Métadonnées

Générer le composant d'exécution de Windows et puis naviguez vers le répertoire de sortie en un clic-droit sur le nom du projet dans l'Explorateur de solutions et en choisissant « Ouvrir le dossier dans l'Explorateur Windows. » Lorsque vous accédez au sous-répertoire bin/Debug, vous trouverez qu'un fichier de métadonnées a été généré pour le composant nommé ThumbnailLibary.winmd. Si vous ouvrez le fichier avec ILDasm.exe, vous verrez qu'une interface a été générée pour le composant avec un type de retour :

Windows.Foundation.IAsyncOperation <Windows.Foundation.Uri>

Ceux sont les types de WinRT mappés pour le composant. On peut également inspecter les métadonnées et voir comment le Common Language Runtime projets WinRT types. Ouvrir le même fichier de métadonnées avec l'extension /project spécial comme ceci :

Ildasm.exe /project ThumbnailLibrary.winmd

Le type de retour apparaît maintenant comme suit :

Windows.Foundation.IAsyncOperation <System.Uri>

Notez que la version WinRT de l'URI est projetée à l'équivalent .NET. La signature de méthode expose tous les types de WinRT valides pour Windows Store apps à consommer, mais à partir de code managé, les types apparaîtront sous forme de classes .NET. Vous pouvez utiliser l'extension /project pour examiner comment la projection affectera la signature des composants d'exécution Windows managées et non managées.

Consommer à partir de c#

Consommant du composant à partir de c# paraisse familier parce qu'il n'est pas différente de celle faisant référence à une bibliothèque de classes. Notez qu'il n'y a aucune raison de créer un composant d'exécution de Windows si votre seul objectif est d'autre code managé. Vous simplement faire référence au projet WinRT et consommez ensuite les classes comme vous le feriez d'une bibliothèque de classes c# ordinaire. Dans l'exemple de code, le projet CSharpThumbnails a une référence à la ThumbnailLibrary. Le code XAML de la page d'accueil définit un bouton pour l'utilisateur de choisir une photo et contient deux images pour héberger l'image originale et la version miniature. Figure 3 montre le balisage XAML base.

Figure 3 XAML pour App Store Windows construit avec 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>

Le codebehind crée une instance du composant WinRT FileOpenPicker et la configure pour parcourir les images :

var openPicker = new FileOpenPicker
{
  ViewMode = PickerViewMode.Thumbnail,
    SuggestedStartLocation = PickerLocationId.PicturesLibrary
};
openPicker.FileTypeFilter.Add(".jpg");
openPicker.FileTypeFilter.Add(".jpeg");
openPicker.FileTypeFilter.Add(".png");

Le sélecteur est appelé et une simple boîte de dialogue s'affiche si aucun fichier valide ne se trouvent :

var file = await openPicker.PickSingleFileAsync();
if (file == null)
{
  var dialog = new MessageDialog("No image was selected.");
  await dialog.ShowAsync();
  return;
}

L'image source est ensuite câblé pour l'affichage. Le fichier est transmis au composant Runtime Windows pour générer une miniature, et l'URI passé retour est utilisée pour définir l'image miniature pour afficher :

 

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;
}

Figure 4 montre le résultat de l'exécution de ce contre une photo j'ai pris une citrouille j'ai gravé.

Windows Store Thumbnail App Built Using C#
Figure 4 App Store Windows miniature construit à l'aide de c#

Consommer à partir de JavaScript

Contrairement à la régulières c# bibliothèques de classes, composants d'exécution Windows peut être appelées depuis n'importe quel langage pris en charge pour la création d'applications Windows Store (principaux composants d'exécution Windows qui font partie du système d'exploitation peut être appelées à partir des applications de bureau aussi bien). Pour voir cela en action, vous pouvez créer le miniature app à l'aide de HTML et JavaScript. Ce projet est appelé JavaScriptThumbnails dans le téléchargement de code échantillon qui l'accompagne. La première étape consiste à créer une application vide, en utilisant le modèle vierge de Windows Store pour les applications construites à l'aide de JavaScript. Une fois que le modèle a été créé, vous pouvez utiliser un balisage HTML simple pour définir la page en utilisant le fichier default.html existant :

<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"/>

Ensuite, ajoutez une référence au projet WinRT (ThumbnailLibrary) comme vous le feriez pour un projet c# ordinaire. Générez le projet afin que vous pouvez utiliser IntelliSense pour le composant nouvellement référencé. Vous pouvez référencer le code source pour le projet de voir le code JavaScript équivalent pour ouvrir le sélecteur de fichier et en sélectionnant l'image. Pour créer une instance du composant Windows Runtime managé, générer la miniature et l'afficher à l'utilisateur, utilisez le code JavaScript suivant :

var thumb = new ThumbnailLibrary.ThumbnailMaker();
thumb.generateThumbnailAsync(file).then(function (fileUrl) {
  var thumbImage = document.getElementById("thumbnail");
  thumbImage.src = fileUrl.rawUri;
  thumbImage.alt = thumbImage.src;
});

Comme vous pouvez le constater, l'appel de l'API est presque identique à celle utilisée dans le projet c#. Projection automatiquement la signature de la méthode de casse Pascal casse mixte (l'appelle pour générer la vignette commence avec un caractère en minuscule, comme c'est la convention commune dans le code JavaScript), et une bibliothèque spéciale appelée « promises » est utilisée pour gérer la nature asynchrone du code en utilisant une instruction puis ou terminée. Vous pouvez en savoir plus sur promesses en lisant la rubrique MSDN Dev Center, "Quickstart : Utilisation de promesses,"à bit.ly/OeWQCQ. La balise d'image prend en charge des URL hors de la zone, alors l'URL transmise à partir du composant d'exécution de Windows est tout simplement mis directement à l'attribut src de l'image.

Une importante mise en garde pour l'utilisation de composants managés dans le code JavaScript est que vous ne pouvez pas déboguer JavaScript et le code managé dans le même temps. Si vous devez déboguer votre composant, vous devez cliquez droit sur le projet et cliquez sur l'onglet Débogage et puis sélectionnez une option de débogage qui inclut du code managé. Ceci est illustrée à la Figure 5.

Setting the Debug Options for a JavaScript Project
Figure 5 Réglage des Options de débogage pour un projet de JavaScript

Consommer à partir de C++

Vous pouvez également consommer des composants d'exécution Windows managé de projets natifs. C++ partageant le même moteur de rendu dans le langage c#, donc le projet CPlusPlusThumbnails a le même XAML comme le projet CSharpThumbnails. Le codebehind est différent parce que le projet utilise l'option de langage C++ native. C++ utilise une bibliothèque spéciale d'accès concurrentiel pour gérer les opérations asynchrones. Vous pouvez en apprendre davantage sur cette bibliothèque en lisant la rubrique MSDN Dev Center, « Asynchrone de programmation en C++, » à bit.ly/MUEqnR. Le code qui en résulte ressemble aux promesses que vous avez vu dans les versions de 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;
  });
});

Lorsque vous exécutez l'application, vous verrez il ressemble et a un comportement identique à la version c#.

Comprendre les coûts

Création de composants d'exécution Windows à l'aide de langages managés est une fonctionnalité puissante. Toutefois, cette fonctionnalité vient à un coût, et il est important de comprendre le coût lorsque vous l'utilisez dans des projets. Apps Store Windows générés à l'aide de code natif ne nécessitent pas le Common Language Runtime à exécuter. Ces applications peuvent s'exécuter directement dans l'environnement Windows 8. De même, les applications développées à l'aide de JavaScript aussi ne nécessitent pas une dépendance sur le Common Language Runtime. Ils s'appuient sur le moteur de rendu Trident et le moteur JavaScript Chakra (les mêmes moteurs que Internet Explorer 10 en voiture) pour restituer le code HTML et CSS et interpréter le code JavaScript. Windows Store apps construits avec JavaScript peuvent appeler des composants d'exécution Windows natif directement, mais lorsqu'ils appellent des composants d'exécution Windows managés, ils prennent sur une dépendance dans le CLR.

Le code écrit pour le composant d'exécution managé Windows sera compilée juste-à-temps (JIT) quand il est tout d'abord accessible par le compilateur JIT du CLR. Ce paramètre peut provoquer quelque temps de retard le premier accès. Un service de précompilation appelé poignées de NGen compiler des modules installés sur le périphérique, mais il peut prendre jusqu'à une journée complète éventuellement compiler tous les modules dans un package une fois qu'il a été installé. Le CLR gère également la mémoire en effectuant l'opération garbage collection. Le garbage collector (GC) divise le tas en trois générations et recueille uniquement les parties du tas à l'aide d'un algorithme conçu pour optimiser les performances.

Le GC s'interrompe votre application alors qu'il effectue le travail. Cela introduit souvent seulement un léger retard qui n'est pas reconnaissable à l'utilisateur final, et plus intenses opérations de collecte des ordures peuvent souvent s'exécutent en arrière-plan. Si vous avez un tas assez grand (quand la partie managée du code fait référence à des centaines de mégaoctets ou plus dans les objets de mémoire), garbage collection s'interrompe le $ $ etAPP assez longtemps pour que l'utilisateur de percevoir le manque de réactivité.

La plupart de ces considérations est déjà en place lorsque vous construisez un app Store Windows managé. Le code managé ajoute des nouvelles préoccupations lorsque vous ajoutez cela à un app Store Windows construit avec C++ ou JavaScript. Il est important de reconnaître que votre application consomme des CPU supplémentaire et de mémoire lorsque vous introduisez des composants managés. Il faudrait également une baisse de performance reconnaissables, en fonction du composant (bien que de nombreuses applications prennent sur des références managées sans impact notable). L'avantage est que vous n'avez pas à vous soucier de la gestion de mémoire et, bien sûr, vous pouvez exploiter les compétences et le code hérité.

Solutions de rechange pour les projets managés

Si vous créez des applications Windows Store à l'aide de code managé (c# ou Visual Basic), vous avez plusieurs possibilités pour créer des composants d'exécution Windows qui n'ont pas les mêmes restrictions. Vous pouvez facilement créer des composants réutilisables à l'aide d'une simple bibliothèque de classes c#. Si la bibliothèque de classes est construite pour les applications Windows Store, vous pouvez référencer le projet depuis votre propre app Store Windows. La création d'une bibliothèque de classes supprime également les restrictions de devoir exposer uniquement les types de WinRT et n'étant ne pas en mesure d'utiliser des fonctionnalités qui ne font pas partie du système de type WinRT, tels que les médicaments génériques.

Une autre solution à envisager est la bibliothèque de classe Portable (PCL). Il s'agit d'un type spécial de bibliothèque de classes qui peut être référencé à partir d'une variété de plates-formes sans recompiler. Utilisez cette option si vous avez le code vous souhaitez partager entre les autres plateformes, telles que Windows Presentation Foundation et Silverlight Windows Phone — et votre app Store Windows. Vous pouvez en apprendre davantage sur le PCL en lisant ma série de trois parties blog, « Comprendre le Portable bibliothèque de Chasing ICommand, » à bit.ly/pclasslib.

Lorsque votre composant comprend plus qu'un simple code, vous pouvez envisager de créer une Extension SDK. Il s'agit d'une forme spéciale du Kit de développement logiciel Visual Studio 2012 peut traiter comme un seul élément. Le package peut inclure le code source, actifs et les fichiers binaires même, y compris les composants d'exécution Windows. Vous pouvez également créer des extensions au moment du design pour le rendre plus facile à consommer et d'utiliser votre composant à partir de Visual Studio 2012. Kits d'extension ne peuvent être validées dans le magasin Windows parce qu'ils ne sont pas autonomes apps. Vous pouvez en savoir plus sur kits d'Extension en lisant l'article de MSDN Library, « comment faire pour : Créer un Kit de développement logiciel,"à bit.ly/L9Ognt.

Quand créer des composants d'exécution Windows managé

Avec tant d'alternatives possibles, est-il toujours judicieux pour créer des composants d'exécution Windows à l'aide de code managé ? Oui, mais posez-vous les questions suivantes. La première question à poser est de savoir si vous avez besoin vos composants à être référencés à partir de Windows Store apps écrits à l'aide de JavaScript ou code natif à l'aide de C++. Si ce n'est pas le cas, il n'y a aucune raison d'utiliser un composant d'exécution de Windows, lorsque les bibliothèques de classes et d'autres options fonctionneront à la place. Si c'est le cas, vous devez créer un composant d'exécution de Windows pour être consommable à partir de toutes les options linguistiques disponibles.

La prochaine question est que vous devez créer votre composant dans C++ ou utilisent du code managé. Il y a un certain nombre de raisons d'utiliser du code managé. Une des raisons pourraient être que votre équipe a plus d'expérience en c# ou Visual Basic qu'en C++ et peut tirer parti des compétences existantes afin de créer les composants. Une autre raison pourrait être que vous avez rédigés dans un langage managé qui sera plus facile de port si vous conservez la même sélection de la langue des algorithmes existants. Il existe certaines tâches qui pourraient être plus faciles à écrire et à maintenir à l'aide de langages managés et les bibliothèques de classes au lieu d'utiliser le code natif, et les équipes qui servent au développement dans des langages managés seront beaucoup plus productifs.

Récapitulation, dans cet article, de que vous avez appris que vous pouvez créer des composants réutilisables Windows Runtime à l'aide managed code c# et Visual Basic. Ces composants peuvent être facilement référencés et consommés à partir d'applications Windows Store rédigées dans n'importe quelle langue, y compris le JavaScript et C++. Il est important de comprendre les règles de création des composants d'exécution de Windows et l'impact du choix d'utiliser du code managé, cette option offre une occasion unique d'utiliser la langue de votre choix et exploiter le code existant pour créer des composants qui peuvent être consommés par tous les apps de magasin de Windows.

Jeremy Likness  *est consultant principal pour Wintellect LLC à Atlanta. Il est MVP trois ans Microsoft Silverlight et l'auteur de plusieurs ouvrages, dont le prochain "Building Windows 8 Applications avec c# et XAML" (Addison-Wesley Professional, 2012). En savoir plus en ligne à bit.ly/win8design et suivez son blog à csharperimage.jeremylikness.com.   *

Merci aux experts techniques suivants d'avoir relu cet article : Layla Driscoll, Shawn Farkas, John Garland, Jeff Prosise et Jeffrey Richter