Transferts en arrière-plan

Utilisez l’API de transfert en arrière-plan pour copier des fichiers de manière fiable sur le réseau. L’API de transfert en arrière-plan fournit des fonctionnalités avancées de chargement et de téléchargement qui s’exécutent en arrière-plan pendant la suspension de l’application et persistent au-delà de l’arrêt de l’application. L’API surveille l’état du réseau et interrompt et reprend automatiquement les transferts lorsque la connectivité est perdue, et les transferts sont également compatibles avec Data Sense et Battery Sense, ce qui signifie que l’activité s’ajuste en fonction de votre connectivité actuelle et de l’état de la batterie de l’appareil. L’API est idéale pour charger et télécharger des fichiers volumineux à l’aide de HTTP(S). FTP est également pris en charge, mais uniquement pour les téléchargements.

Le transfert en arrière-plan s’exécute séparément de l’application appelante et est principalement conçu pour les opérations de transfert à long terme pour les ressources telles que la vidéo, la musique et les images volumineuses. Pour ces scénarios, l’utilisation du transfert en arrière-plan est essentielle, car les téléchargements continuent de progresser même lorsque l’application est suspendue.

Si vous téléchargez de petites ressources susceptibles de se terminer rapidement, vous devez utiliser les API HttpClient au lieu du transfert en arrière-plan.

Utilisation de Windows.Networking.BackgroundTransfer

Comment fonctionne la fonctionnalité de transfert en arrière-plan ?

Lorsqu’une application utilise le transfert en arrière-plan pour lancer un transfert, la requête est configurée et initialisée à l’aide d’objets de classe BackgroundDownloader ou BackgroundUploader . Chaque opération de transfert est gérée individuellement par le système et séparée de l’application appelante. Les informations de progression sont disponibles si vous souhaitez donner l’état à l’utilisateur dans l’interface utilisateur de votre application et que votre application peut suspendre, reprendre, annuler ou même lire les données pendant le transfert. La façon dont les transferts sont gérés par le système favorise l’utilisation intelligente de l’alimentation et empêche les problèmes qui peuvent survenir lorsqu’une application connectée rencontre des événements tels que la suspension de l’application, l’arrêt ou les changements soudains d’état réseau.

Lorsqu’une application est lancée, elle doit appeler AttachAsync sur tous les objets DownloadOperation et UploadOperation existants. Ne pas le faire provoquera une fuite de mémoire liée aux transferts déjà terminés et finira par rendre la fonctionnalité de transfert en arrière-plan inutilisable.

Exécution de demandes de fichiers authentifiées avec transfert en arrière-plan

Le transfert en arrière-plan fournit des méthodes qui prennent en charge les informations d’identification de serveur et de proxy de base, les cookies et l’utilisation d’en-têtes HTTP personnalisés (via SetRequestHeader) pour chaque opération de transfert.

Comment cette fonctionnalité s’adapte-t-elle aux modifications d’état réseau ou aux arrêts inattendus ?

La fonctionnalité de transfert en arrière-plan conserve une expérience cohérente pour chaque opération de transfert lorsque des modifications de l’état du réseau se produisent, en tirant intelligemment parti des informations d’état du plan de données de l’opérateur et de connectivité fournies par la fonctionnalité connectivité . Pour définir le comportement pour différents scénarios réseau, une application définit une stratégie de coût pour chaque opération à l’aide de valeurs définies par BackgroundTransferCostPolicy.

Par exemple, la stratégie de coût définie pour une opération peut indiquer que l’opération doit être suspendue automatiquement lorsque l’appareil utilise un réseau limité. Le transfert est ensuite repris automatiquement (ou redémarré) lorsqu’une connexion à un réseau « illimité » a été établie. Pour plus d’informations sur la façon dont les réseaux sont définis par coût, consultez NetworkCostType.

Bien que la fonctionnalité de transfert en arrière-plan dispose de ses propres mécanismes pour gérer les modifications d’état du réseau, il existe d’autres considérations générales en matière de connectivité pour les applications connectées au réseau. Lisez l’utilisation des informations de connexion réseau disponibles pour obtenir des informations supplémentaires.

Note Pour les applications s’exécutant sur des appareils mobiles, il existe des fonctionnalités qui permettent à l’utilisateur de surveiller et de restreindre la quantité de données transférées en fonction du type de connexion, de l’état d’itinérance et du plan de données de l’utilisateur. En raison de cela, les transferts en arrière-plan peuvent être suspendus sur le téléphone même lorsque BackgroundTransferCostPolicy indique que le transfert doit continuer.

Le tableau suivant indique quand les transferts en arrière-plan sont autorisés sur le téléphone pour chaque valeur BackgroundTransferCostPolicy , en fonction de l’état actuel du téléphone. Vous pouvez utiliser la classe ConnectionCost pour déterminer l'état actuel du téléphone.

Chargement de fichiers

Lorsque vous utilisez Background Transfer, un téléversement est représenté par un UploadOperation qui expose un certain nombre de méthodes de commande utilisées pour redémarrer ou annuler l’opération. Les événements d’application (par exemple, suspension ou arrêt) et les modifications de connectivité sont gérées automatiquement par le système par UploadOperation ; les chargements se poursuivent pendant les périodes de suspension de l’application ou suspendent et persistent au-delà de l’arrêt de l’application. En outre, la définition de la propriété CostPolicy indique si votre application démarre les chargements pendant qu’un réseau limité est utilisé pour la connectivité Internet.

Les exemples suivants vous guident tout au long de la création et de l’initialisation d’un chargement de base et expliquent comment énumérer et réintroduire les opérations persistantes à partir d’une session d’application précédente.

Chargement d’un fichier unique

La création d’un chargement commence par BackgroundUploader. Cette classe est utilisée pour fournir les méthodes qui permettent à votre application de configurer le chargement avant de créer l’opération UploadOperation résultante. L’exemple suivant montre comment procéder avec les objets Uri et StorageFile requis.

Identifier le fichier et la destination du chargement

Avant de commencer par la création d’un UploadOperation, nous devons d’abord identifier l’URI de l’emplacement à charger et le fichier qui sera chargé. Dans l’exemple suivant, la valeur uriString est remplie à l’aide d’une chaîne à partir d’une entrée d’interface utilisateur, et la valeur du fichier à l’aide de l’objet StorageFile retourné par une opération PickSingleFileAsync .

function uploadFile() {
    var filePicker = new Windows.Storage.Pickers.FileOpenPicker();
    filePicker.fileTypeFilter.replaceAll(["*"]);

    filePicker.pickSingleFileAsync().then(function (file) {
        if (!file) {
            printLog("No file selected");
            return;
        }

        var upload = new UploadOp();
        var uriString = document.getElementById("serverAddressField").value;
        upload.start(uriString, file);

        // Store the upload operation in the uploadOps array.
        uploadOperations.push(upload);
    });
}

Créer et initialiser l’opération de chargement

À l’étape précédente, les valeurs uriString et de fichier sont passées à une instance de notre exemple suivant, UploadOp, où ils sont utilisés pour configurer et démarrer la nouvelle opération de chargement. Tout d’abord, uriString est analysé pour créer l’objet Uri requis.

Ensuite, les propriétés du StorageFile (fichier) fourni sont utilisées par BackgroundUploader pour remplir l’en-tête de requête et définir la propriété SourceFile avec l’objet StorageFile . La méthode SetRequestHeader est ensuite appelée pour insérer le nom de fichier, fourni sous forme de chaîne et la propriété StorageFile.Name .

Enfin, BackgroundUploader crée UploadOperation (chargement).

function UploadOp() {
    var upload = null;
    var promise = null;

    this.start = function (uriString, file) {
        try {
        
            var uri = new Windows.Foundation.Uri(uriString);
            var uploader = new Windows.Networking.BackgroundTransfer.BackgroundUploader();

            // Set a header, so the server can save the file (this is specific to the sample server).
            uploader.setRequestHeader("Filename", file.name);

            // Create a new upload operation.
            upload = uploader.createUpload(uri, file);

            // Start the upload and persist the promise to be able to cancel the upload.
            promise = upload.startAsync().then(complete, error, progress);
        } catch (err) {
            displayError(err);
        }
    };
    // On application activation, reassign callbacks for a upload
    // operation persisted from previous application state.
    this.load = function (loadedUpload) {
        try {
            upload = loadedUpload;
            promise = upload.attachAsync().then(complete, error, progress);
        } catch (err) {
            displayError(err);
        }
    };
}

Notez les appels de méthode asynchrone définis à l’aide de promesses JavaScript. Regardez une ligne à partir du dernier exemple :

promise = upload.startAsync().then(complete, error, progress);

L’appel de méthode asynchrone est suivi d’une then instruction qui indique les méthodes, définies par l’application, qui sont appelées lorsqu’un résultat de l’appel de méthode asynchrone est retourné. Pour plus d’informations sur ce modèle de programmation, consultez Programmation asynchrone en JavaScript à l’aide de promesses.

Chargement de plusieurs fichiers

Identifier les fichiers et la destination du chargement

Dans un scénario impliquant plusieurs fichiers transférés avec un seul UploadOperation, le processus commence comme il le fait généralement en fournissant d’abord l’URI de destination requis et les informations de fichier local. Comme dans l’exemple de la section précédente, l’URI est fourni sous forme de chaîne par l’utilisateur final et FileOpenPicker peut également permettre d’indiquer des fichiers via l’interface utilisateur. Toutefois, dans ce scénario, l’application doit appeler la méthode PickMultipleFilesAsync pour activer la sélection de plusieurs fichiers via l’interface utilisateur.

function uploadFiles() {
       var filePicker = new Windows.Storage.Pickers.FileOpenPicker();
       filePicker.fileTypeFilter.replaceAll(["*"]);

       filePicker.pickMultipleFilesAsync().then(function (files) {
          if (files === 0) {
             printLog("No file selected");
                return;
          }

          var upload = new UploadOperation();
          var uriString = document.getElementById("serverAddressField").value;
          upload.startMultipart(uriString, files);

          // Persist the upload operation in the global array.
          uploadOperations.push(upload);
       });
    }

Créer des objets pour les paramètres fournis

Les deux exemples suivants utilisent du code contenu dans une méthode d’exemple unique, startMultipart, qui a été appelée à la fin de la dernière étape. Pour l’instruction, le code de la méthode qui crée un tableau d’objets BackgroundTransferContentPart a été divisé à partir du code qui crée le UploadOperation résultant.

Tout d’abord, la chaîne d’URI fournie par l’utilisateur est initialisée en tant qu’URI. Ensuite, le tableau d’objets IStorageFile (fichiers) transmis à cette méthode est itéré, chaque objet est utilisé pour créer un objet BackgroundTransferContentPart qui est ensuite placé dans le tableau contentParts .

    upload.startMultipart = function (uriString, files) {
        try {
            var uri = new Windows.Foundation.Uri(uriString);
            var uploader = new Windows.Networking.BackgroundTransfer.BackgroundUploader();

            var contentParts = [];
            files.forEach(function (file, index) {
                var part = new Windows.Networking.BackgroundTransfer.BackgroundTransferContentPart("File" + index, file.name);
                part.setFile(file);
                contentParts.push(part);
            });

Créer et initialiser l’opération de chargement en plusieurs parties

Avec notre tableau contentParts rempli avec tous les objets BackgroundTransferContentPart représentant chaque fichier IStorageFile à charger, nous sommes prêts à appeler CreateUploadAsync à l’aide de l’URI pour indiquer où la requête sera envoyée.

        // Create a new upload operation.
            uploader.createUploadAsync(uri, contentParts).then(function (uploadOperation) {

               // Start the upload and persist the promise to be able to cancel the upload.
               upload = uploadOperation;
               promise = uploadOperation.startAsync().then(complete, error, progress);
            });

         } catch (err) {
             displayError(err);
         }
     };

Redémarrage des opérations de chargement interrompues

À la fin ou à l’annulation d’un UploadOperation, toutes les ressources système associées sont publiées. Toutefois, si votre application est arrêtée avant que l’une de ces opérations puisse se produire, toutes les opérations actives sont suspendues et les ressources associées à chacune d’elles restent occupées. Si ces opérations ne sont pas énumérées et réinscrites à la prochaine session d’application, elles ne sont pas terminées et continuent d’occuper les ressources de l’appareil.

1. Avant de définir la fonction qui énumère les opérations persistantes, nous devons créer un tableau qui contiendra les objets UploadOperation qu’il retourne :

   var uploadOperations = [];
   

2. Ensuite, nous définissons la fonction qui énumère les opérations persistantes et les stocke dans notre tableau. Notez que la méthode load, appelée pour réassocier les fonctions de rappel à UploadOperation si celui-ci persiste après la fermeture de l’application, se trouve dans la classe UploadOp que nous définissons plus loin dans cette section.

   function Windows.Networking.BackgroundTransfer.BackgroundUploader.getCurrentUploadsAsync() {
       .then(function (uploads) {
           for (var i = 0; i < uploads.size; i++) {
               var upload = new UploadOp();
               upload.load(uploads[i]);
               uploadOperations.push(upload);
           }
       }
   };
   

Téléchargement de fichiers

Lors de l’utilisation du transfert en arrière-plan, chaque téléchargement existe en tant que DownloadOperation qui expose un certain nombre de méthodes de contrôle utilisées pour suspendre, reprendre, redémarrer et annuler l’opération. Les événements d’application (par exemple, suspension ou arrêt) et les modifications de connectivité sont gérées automatiquement par le système par DownloadOperation ; les téléchargements continueront pendant les périodes de suspension de l’application ou seront suspendus et persistants au-delà de l’arrêt de l’application. Pour les scénarios de réseau mobile, la définition de la propriété CostPolicy indique si votre application démarre ou continue les téléchargements pendant qu’un réseau limité est utilisé pour la connectivité Internet.

Si vous téléchargez de petites ressources susceptibles de se terminer rapidement, vous devez utiliser les API HttpClient au lieu du transfert en arrière-plan.

Les exemples suivants vous guident tout au long de la création et de l’initialisation d’un téléchargement de base, ainsi que la façon d’énumérer et de réintroduire les opérations conservées à partir d’une session d’application précédente.

Configurer et démarrer un téléchargement de fichier de transfert en arrière-plan

L’exemple suivant montre comment les chaînes représentant un URI et un nom de fichier peuvent être utilisées pour créer un objet Uri et le StorageFile qui contiendra le fichier demandé. Dans cet exemple, le nouveau fichier est automatiquement placé dans un emplacement prédéfinis. Vous pouvez également utiliser FileSavePicker pour permettre aux utilisateurs d’indiquer où enregistrer le fichier sur l’appareil. Notez que la méthode load, appelée pour réassocier les fonctions de rappel à l’objet DownloadOperation si celui-ci survit à l’arrêt de l’application, est définie dans la classe DownloadOp plus loin dans cette section.

function DownloadOp() {
    var download = null;
    var promise = null;
    var imageStream = null;

    this.start = function (uriString, fileName) {
        try {
            // Asynchronously create the file in the pictures folder.
            Windows.Storage.KnownFolders.picturesLibrary.createFileAsync(fileName, Windows.Storage.CreationCollisionOption.generateUniqueName).done(function (newFile) {
                var uri = Windows.Foundation.Uri(uriString);
                var downloader = new Windows.Networking.BackgroundTransfer.BackgroundDownloader();

                // Create a new download operation.
                download = downloader.createDownload(uri, newFile);

                // Start the download and persist the promise to be able to cancel the download.
                promise = download.startAsync().then(complete, error, progress);
            }, error);
        } catch (err) {
            displayException(err);
        }
    };
    // On application activation, reassign callbacks for a download
    // operation persisted from previous application state.
    this.load = function (loadedDownload) {
        try {
            download = loadedDownload;
            printLog("Found download: " + download.guid + " from previous application run.<br\>");
            promise = download.attachAsync().then(complete, error, progress);
        } catch (err) {
            displayException(err);
        }
    };
}

Notez les appels de méthode asynchrone définis à l’aide de promesses JavaScript. En examinant la ligne 17 de l’exemple de code précédent :

promise = download.startAsync().then(complete, error, progress);

L’appel de méthode asynchrone est suivi d’une instruction qui indique ensuite les méthodes, définies par l’application, qui sont appelées lorsqu’un résultat de l’appel de méthode asynchrone est retourné. Pour plus d’informations sur ce modèle de programmation, consultez Programmation asynchrone en JavaScript à l’aide de promesses.

Ajout de méthodes de contrôle d’opération supplémentaires

Le niveau de contrôle peut être augmenté en implémentant des méthodes DownloadOperation supplémentaires. Par exemple, l’ajout du code suivant à l’exemple ci-dessus introduit la possibilité d’annuler le téléchargement.

// Cancel download.
this.cancel = function () {
    try {
        if (promise) {
            promise.cancel();
            promise = null;
            printLog("Canceling download: " + download.guid + "<br\>");
            if (imageStream) {
                imageStream.close();
            }
        }
        else {
            printLog("Download " + download.guid + " already canceled.<br\>");
        }
    } catch (err) {
        displayException(err);
    }
};

Énumération des opérations persistantes au démarrage

À la fin ou à l’annulation d’un DownloadOperation, toutes les ressources système associées sont publiées. Toutefois, si votre application est arrêtée avant l’un de ces événements, les téléchargements s’interrompent et persistent en arrière-plan. Les exemples suivants montrent comment réintroduire des téléchargements persistants dans une nouvelle session d’application.

1. Avant de définir la fonction qui énumère les opérations persistantes, nous devons créer un tableau qui contiendra les objets DownloadOperation qu’il retourne :

   var downloadOps = [];
   

2. Ensuite, nous définissons la fonction qui énumère les opérations persistantes et les stocke dans notre tableau. Notez que la méthode de chargement appelée pour réétribuer des rappels pour un DownloadOperation persistant se trouve dans l’exemple DownloadOp que nous définissons plus loin dans cette section.

   // Enumerate outstanding downloads.
   Windows.Networking.BackgroundTransfer.BackgroundDownloader.getCurrentDownloadsAsync().done(function (downloads) {
   
       for (var i = 0; i < downloads.size; i++) {
           var download = new DownloadOp();
           download.load(downloads[i]);
           downloadOps.push(download);
       }
   });
   

3. Vous pouvez maintenant utiliser la liste renseignée pour redémarrer les opérations en attente.

Post-traitement

Une nouvelle fonctionnalité de Windows 10 est la possibilité d’exécuter du code d’application à l’achèvement d’un transfert en arrière-plan même lorsque l’application n’est pas en cours d’exécution. Par exemple, votre application peut vouloir mettre à jour une liste de films disponibles une fois qu’un film a terminé de télécharger, plutôt que d’effectuer une analyse de votre application pour les nouveaux films chaque fois qu’elle démarre. Ou votre application peut vouloir gérer un transfert de fichiers ayant échoué en réessayant à l’aide d’un autre serveur ou port. Le post-traitement est appelé pour les transferts réussis et ayant échoué. Vous pouvez donc l’utiliser pour implémenter une logique personnalisée de gestion des erreurs et de nouvelle tentative.

Le posttraitement utilise l’infrastructure de tâches en arrière-plan existante. Vous créez une tâche en arrière-plan et l’associez à vos transferts avant de démarrer les transferts. Les transferts sont ensuite exécutés en arrière-plan, et quand ils sont terminés, votre tâche en arrière-plan est appelée pour effectuer un post-traitement.

Le post-traitement utilise une nouvelle classe , BackgroundTransferCompletionGroup. Cette classe est similaire à l’élément BackgroundTransferGroup existant dans lequel elle vous permet de regrouper les transferts d’arrière-plan ensemble, mais BackgroundTransferCompletionGroup ajoute la possibilité de désigner une tâche en arrière-plan à exécuter une fois le transfert terminé.

Vous lancez un transfert en arrière-plan avec post-traitement comme suit.

1. Créez un objet BackgroundTransferCompletionGroup . Ensuite, créez un objet BackgroundTaskBuilder . Définissez la propriété Trigger de l’objet générateur sur l’objet de groupe d’achèvement et la propriété TaskEntryPoint du générateur sur le point d’entrée de la tâche en arrière-plan qui doit s’exécuter lors de l’achèvement du transfert. Enfin, appelez la méthode BackgroundTaskBuilder.Register pour inscrire votre tâche en arrière-plan. Notez que plusieurs groupes d’achèvement peuvent partager un même point d’entrée pour les tâches en arrière-plan, mais vous ne pouvez avoir qu’un seul groupe d’achèvement par enregistrement de tâche en arrière-plan.

var completionGroup = new BackgroundTransferCompletionGroup();
BackgroundTaskBuilder builder = new BackgroundTaskBuilder();

builder.Name = "MyDownloadProcessingTask";
builder.SetTrigger(completionGroup.Trigger);
builder.TaskEntryPoint = "Tasks.BackgroundDownloadProcessingTask";

BackgroundTaskRegistration downloadProcessingTask = builder.Register();

2. Ensuite, associez les transferts en arrière-plan au groupe de complétion. Une fois tous les transferts créés, activez le groupe de finalisation.

BackgroundDownloader downloader = new BackgroundDownloader(completionGroup);
DownloadOperation download = downloader.CreateDownload(uri, file);
Task<DownloadOperation> startTask = download.StartAsync().AsTask();

// App still sees the normal completion path
startTask.ContinueWith(ForegroundCompletionHandler);

// Do not enable the CompletionGroup until after all downloads are created.
downloader.CompletionGroup.Enable();

3. Le code de la tâche en arrière-plan extrait la liste des opérations à partir des détails du déclencheur, et votre code peut ensuite inspecter les détails de chaque opération et effectuer un post-traitement approprié pour chaque opération.

public class BackgroundDownloadProcessingTask : IBackgroundTask
{
    public async void Run(IBackgroundTaskInstance taskInstance)
    {
    var details = (BackgroundTransferCompletionGroupTriggerDetails)taskInstance.TriggerDetails;
    IReadOnlyList<DownloadOperation> downloads = details.Downloads;

    // Do post-processing on each finished operation in the list of downloads
    }
}

La tâche de post-traitement est une tâche en arrière-plan régulière. Il fait partie du pool de toutes les tâches en arrière-plan et est soumis à la même stratégie de gestion des ressources que toutes les tâches en arrière-plan.

Notez également que le post-traitement ne remplace pas les gestionnaires d’achèvement au premier plan. Si votre application définit un gestionnaire d’achèvement de premier plan et que votre application s’exécute lorsque le transfert de fichier se termine, votre gestionnaire d’achèvement de premier plan et votre gestionnaire d’achèvement en arrière-plan sont appelés. L’ordre dans lequel les tâches de premier plan et d’arrière-plan sont appelées n’est pas garantie. Si vous définissez les deux, vous devez vous assurer que les deux tâches fonctionnent correctement et ne s’interfèrent pas entre elles si elles s’exécutent simultanément.

Délais d’expiration des requêtes

Il existe deux scénarios de délai d’expiration de connexion principaux à prendre en compte :

• Lors de l’établissement d’une nouvelle connexion pour un transfert, la demande de connexion est abandonnée si elle n’est pas établie dans les cinq minutes.

• Une fois qu’une connexion a été établie, un message de requête HTTP qui n’a pas reçu de réponse dans les deux minutes est abandonné.

Note Dans les deux scénarios, en supposant qu’il existe une connectivité Internet, le transfert en arrière-plan effectue une nouvelle tentative de requête jusqu’à trois fois automatiquement. Si la connectivité Internet n’est pas détectée, des requêtes supplémentaires attendent qu’elle soit.

Conseils de débogage

L’arrêt d’une session de débogage dans Microsoft Visual Studio est comparable à la fermeture de votre application ; Les chargements PUT sont suspendus et les chargements POST sont arrêtés. Même lors du débogage, votre application doit énumérer, puis redémarrer ou annuler les chargements persistants. Par exemple, vous pouvez avoir que votre application annule les opérations de chargement persistantes énumérées au démarrage de l’application s’il n’y a aucun intérêt dans les opérations précédentes pour cette session de débogage.

Lors de l’énumération des téléchargements/téléversements au démarrage de l’application pendant une session de débogage, vous pouvez faire en sorte que votre application les annule si les opérations précédentes de cette session de débogage ne présentent plus d’intérêt. Notez que s’il existe Visual Studio mises à jour de projet, telles que les modifications apportées au manifeste de l’application et que l’application est désinstallée et redéployée, GetCurrentUploadsAsync ne peut pas énumérer les opérations créées à l’aide du déploiement d’application précédent.

Lorsque vous utilisez le transfert en arrière-plan pendant le développement, vous pouvez entrer dans une situation où les caches internes des opérations de transfert actives et terminées peuvent sortir de la synchronisation. Cela peut entraîner l’impossibilité de démarrer de nouvelles opérations de transfert ou d’interagir avec les opérations existantes et les objets BackgroundTransferGroup . Dans certains cas, la tentative d’interaction avec les opérations existantes peut déclencher un blocage. Ce résultat peut se produire si la propriété TransferBehavior est définie sur Parallel. Ce problème se produit uniquement dans certains scénarios pendant le développement et n’est pas applicable aux utilisateurs finaux de votre application.

Quatre scénarios utilisant Visual Studio peuvent provoquer ce problème.

• Vous créez un projet portant le même nom d’application qu’un projet existant, mais un langage différent (de C++ à C#, par exemple).
• Vous modifiez l’architecture cible (de x86 à x64, par exemple) dans un projet existant.
• Vous modifiez la culture (de neutre à en-US, par exemple) dans un projet existant.
• Vous ajoutez ou supprimez une fonctionnalité dans le manifeste de package (ajout de l’authentification d’entreprise, par exemple) dans un projet existant.

La maintenance régulière des applications, y compris les mises à jour de manifeste qui ajoutent ou suppriment des fonctionnalités, ne déclenchent pas ce problème sur les déploiements des utilisateurs finaux de votre application. Pour contourner ce problème, désinstallez complètement toutes les versions de l’application et redéployez avec le nouveau langage, l’architecture, la culture ou la fonctionnalité. Cette opération peut être effectuée via l’écran de démarrage ou à l’aide de PowerShell et de l’applet de commande Remove-AppxPackage .

Exceptions dans Windows.Networking.BackgroundTransfer

Une exception est levée lorsqu’une chaîne non valide pour un identificateur de ressource uniforme (URI) est passée au constructeur de l’objet Windows.Foundation.Uri.

.NET : Le type Windows.Foundation.Uri apparaît comme System.Uri en C# et VB.

Dans C# et Visual Basic, cette erreur peut être évitée à l’aide de la classe System.Uri dans la .NET 4.5 et l’une des méthodes System.Uri.TryCreate pour tester la chaîne reçue de l’utilisateur de l’application avant la construction de l’URI.

En C++, il n’existe aucune méthode pour essayer d’analyser une chaîne à un URI. Si une application obtient une entrée de l’utilisateur pour le Windows. Foundation.Uri, le constructeur doit se trouver dans un bloc try/catch. Si une exception est levée, l’application peut avertir l’utilisateur et demander un nouveau nom d’hôte.

L’espace de noms Windows.Networking.backgroundTransfer comporte des méthodes utilitaires pratiques et utilise des énumérations du Windows.Networking.Sockets pour gérer les erreurs. Cela peut être utile pour gérer des exceptions réseau spécifiques différemment dans votre application.

Une erreur rencontrée dans une méthode asynchrone de l’espace de noms Windows.Networking.backgroundTransfer est renvoyée sous la forme d’une valeur HRESULT. La méthode BackgroundTransferError.GetStatus permet de convertir une erreur réseau d’une opération de transfert en arrière-plan en valeur d’énumération WebErrorStatus . La plupart des valeurs d’énumération WebErrorStatus correspondent à une erreur retournée par l’opération de client HTTP ou FTP native. Une application peut filtrer sur des valeurs d’énumération WebErrorStatus spécifiques pour modifier le comportement de l’application en fonction de la cause de l’exception.

Pour les erreurs de validation de paramètre, une application peut également utiliser HRESULT à partir de l’exception pour en savoir plus sur l’erreur qui a provoqué l’exception. Les valeurs HRESULT possibles sont répertoriées dans le fichier d’en-tête Winerror.h . Pour la plupart des erreurs de validation de paramètre, HRESULT retourné est E_INVALIDARG.

API importantes

• Windows.Networking.BackgroundTransfer
• Windows.Foundation.Uri
• Windows. Networking.Sockets