Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Bonne nouvelle pour les abonnés MSDN : TFS 2017 est disponible au téléchargement ;)

Bonne migration !

En temps normal, il n’y a rien de particulier à faire pour qu’une application UWP soit localisée. On ajoute les ressources, et Visual Studio trouve de lui-même les langues utilisables.

Ceci est défini via la section Resources du fichier Package.appxmanifest :

<Resources>
    <Resource Language="x-generate" />
</Resources>

Mais si Visual Studio n’arrive pas à déterminer les langues utilisées, on peut avoir plusieurs difficultés :

- Vous avez localisé une application et vos utilisateurs ne peuvent utiliser que la langue par défaut.

- Lors de la publication, le Store ne vous propose pas de renseigner toutes les langues contenues dans l’application.

Cette situation peut se produire si on a placé nos ressources dans un projet d’assembly dédié de type Portable Class Library. Dans ce cas de figure, il faut lister les ressources que l’on utilise dans le fichier Package.appxmanifest

Ex :

<Resources>
    <Resource Language="en-US" />
    <Resource Language="fr-Fr" />
    <Resource Language="it-It" />
</Resources>

Ceci n’est pas forcément très joyeux à faire, mais cela résout le problème.

Lors de la connexion d’un client à un Windows Server Essentials 2016, il existe a une erreur qui n’est pas documentée :

« Impossible de se connecter au serveur. Le serveur n’est pas disponible ».

Lors de mes tests, j’ai repris la liste des opérations que j’avais planifiées pour ma migration vers Windows Server 2016. C’est alors que je me suis rendu compte que j’avais rétrogradé le contrôleur principal de domaine qui était en service lors de l’installation des features Windows Server Essentials.

Si on regarde du côté des paramètres Windows Server Essentials, on peut constater qu’il existe une section : « Contrôleur de domaine désigné ». Si ce paramètre n’est pas bon, aucun client ne peut être ajouté au serveur.

clip_image001

Pour le changer, il suffit d’utiliser le bouton « Modifier », puis de choisir un serveur dans la liste de ceux qui sont disponibles.

clip_image002

Comme sur 2012 R2, sur Windows Server 2016, pour changer la langue d’un server core, il faut passer par PowerShell.

Toutes les langues n’étant pas installées par défaut, on doit commencer par installer la langue voulue : New-WinUserLanguageList fr-fr

clip_image002

Puis la définir comme étant la langue à utiliser : Set- WinUserLanguageList fr-fr

clip_image004

On peut aussi passer par "control int.cpl" pour changer les options de localisation et de globalisation.

En voulant upgrader un hôte Hyper-V de Windows 2012 R2 à 2016, j'ai eu une petite surprise : Les configurations NIC Teaming doivent être supprimées avant l'upgrade et reconstruites après.

Si en plus vous avez la chance d'utiliser cette fonctionnalité avec des switchs managés, il faudra planifier quelques manipulations supplémentaires avant de passer à Windows Server 2016.

clip_image002

Bonnes migrations à vous ;)

Lors des Microsoft Expériences, j’ai eu l’opportunité de présenter avec Pierrick un talk très sympathique sur l’accessibilité : Tout pour mijoter de belles applications UWP accessibles à tous et partout

Comme promis, voici les slides que nous avions présenté Pierrick et moi : https://1drv.ms/p/s!AmH_MyeRP0S6m89eo3Mltck8lPOg0g

clip_image002 Je souhaitais vous faire part de ma joie de recevoir un nouveau MVP Award. Comme tous les ans, je l’annonce avec un peu de retard. Octobre étant toujours un mois très chargé pour moi.

Cette année, je suis passé de l’expertise "Microsoft Azure" à "Visual Studio and Development Technologies".

Merci à Microsoft pour cet honneur, et un

Microsoft Store Services SDK est le nouveau nom du SDK dédié à la monétisation d'applications UWP. Depuis son passage à la version 10.0.0, de gros changements sont à noter :

  • Fin du support Windows 8.1, ce SDK est orienté UWP à 100%.
  • Fin du AdMediatorControl (il faut utiliser le AdControl, la médiation se faisant côté serveur)
  • Il n'est plus utile de télécharger les packages NuGet des annonceurs.
  • Il n'y a plus de configuration des annonceurs dans l'application.
  • Le AdControl est une classe sealed (donc l'héritage est impossible… sniff).
  • Changements de namespaces.
  • Les events du AdControl ne sont pas les mêmes que ceux du AdmediatorControl.

Si comme moi vous aviez codé une classe partagée entre Windows 8.1 et 10 qui héritait du AdMediatorControl, il va falloir revoir votre code en profondeur. Pour les autres, quelques changements de namespace et d'events devraient suffire.

Côté Windows 8.1 : on peut rester sur la version 2.0.8 du Microsoft Advertising SDK for Windows and Windows Phone 8.x (ceci sans changer son code). Ce SDK peut aussi être utilisé pour passer au AdControl. À l'avenir, ce SDK n'évoluera plus. Seules des correctifs se sécurité pourront être apportés.

Bonne mise à jour ;)

Suite à l'update 3 de Visual Studio 2015, Universal Windows Platform est passée en version 5.2. Version qui a le très désagréable inconvénient de ne pas respecter toutes les règles du store, et qui peut provoquer un rejet lors de la publication d'un package.

Le store indique une erreur 1300 (conformément à la capture suivante). Et la documentions sur cette erreur, n'est pas très épaisse… On nous dit juste de préparer un nouveau package avec Visual Studio. A la seconde tentative qui échoue, on peut laisser tomber.

Le sujet à déjà pas mal animé les forums :

https://social.msdn.microsoft.com/Forums/en-US/6cecb739-f41c-4449-9182-54c40e067652/uwp-submission-failed-with-error-code-1300-and-no-appxsym-file-inside-appxupload-package?forum=wpdevelop

https://social.msdn.microsoft.com/Forums/en-US/e766a904-7346-4f76-bad2-852d3b301b0e/known-issue-version-52-of-microsoftnetcoreuniversalwindowsplatform-delisted-all?forum=Win10SDKToolsIssues

Des issues en rapport ont été créées sur GitHub.

https://github.com/dotnet/corefx/issues/9711

https://github.com/dotnet/corefx/issues/9743

 

Si vous avez mis à jour une application UWP cette semaine, une seule solution s'offre à vous pour le moment : revenir à UWP 5.1.

Pour cela, il suffit de lancer la gestion de package NuGet et de sélectionner ses projets et de demander l'installation de la version 5.1.0 (liste version, on sélectionne 5.1.0 et on click sur Install)

La UWP 5.2 a été retirée temporairement, il n'y a donc pas à craindre pour la suite qu'elle revienne avec ces méchants bugs.

Vous avez envie de découvrir l'accessibilité ? Vous voulez vous faire une idée de ce que peut être la vie avec un PC quand on a un handicap ?

Ne cherchez pas midi à quatorze heures. Pour commencer, il n'est pas utile de vous bander les yeux. Il n'est pas non plus utile d'installer cinquante utilitaires sur son PC, ou d'acquérir de couteuses licences.

Commencez en douceur. Choisissez l'un des deux défis suivants et tenez-vous-y une journée :

  1. Utiliser son PC uniquement avec le clavier.
  2. Utiliser son PC uniquement avec la souris.

Saurez-vous tenir une journée sans craquer ?

Note : contrairement à ce que l'on pourrait croire, le fait de se passer de la souris est souvent plus simple que de se passer du clavier.

Ma définition préférée de l'accessibilité c'est : « Simplifier l'accès aux services pour tous ».

Certain préfèreront des tournures plus longues, plus élaborées ou documentées. Personnellement, je préfère en rester à ces quelques mots essentiels qui traduisent toute la difficulté de la chose et son périmètre.

« Simplifier l'accès »

Avec un PC, on a accès à une infinité de possibilités, d'applications et de service. C'est génial. Mais est-ce pour autant simple d'accès ? Pas toujours !

Exemples d'application ou sites, dont l'accès n'est pas simple :

  • Textes écrits en pourpre ou violet sur fond noir (merci le mal de tête).
  • Navigation impossible au clavier. Comment faire si on ne peut pas utiliser une souris ?
  • Navigation impossible avec une tablette.
  • Plan d'accès d'un salon au format timbre-poste de 300x300px (c'est du vécu).

Et si l'on a un handicap lourd, c'est encore plus difficile. Si l'on est aveugle, nombre de sites ou d'applications sont tout simplement inutilisables. Avec un peu de travail, les développeurs pourraient les rendre accessibles.

« Tous »

On est tous concernés. Potentiellement à tout moment de notre vie, on peut se retrouver avec des difficultés pour effectuer une action ou une autre. Ceci peut être le produit d'un accident, d'une maladie, de l'âge.

En France, on associe presque toujours l'accessibilité à un handicap (vue, fauteuil roulant, amputation). Mais il y aussi ces contenus / applications / sites dont le contenu ne parle à personne ou presque. Exemples :

  • La notice de montage d'un meuble suédois.
  • La première déclaration d'impôts (pour certains, les suivantes aussi peuvent poser problème).
  • Les feuilles de paie.
  • …. Etc…

Dans ces cas-là, nous sommes tous en difficulté.

« Service »

Aujourd'hui, l'informatique est là pour rendre des services. En tout cas, c'est que l'on en attend. Quand votre application n'est pas accessible à un utilisateur, elle ne peut lui rendre aucun service. Pire, elle peut donner une mauvaise image de votre société et de votre travail. Il y a de fortes chances que ce ne soit pas ce que vous souhaitiez.

Conclusion

Pour conclure avec l'exemple ultime de ce que n'est pas l'accessibilité, ce serrait :

  • Une déclaration d'impôts rédigée en suédois.
  • Sur une page écrite en pourpre sur fond noir.
  • Avec une notice de 30 pages qui s'affichent dans un encart de 300 par 300 pixels.
  • Avec un bouton « valider » qui bouge dès qu'on l'approche.
  • Le tout étant inutilisable au clavier.

Voilà, en espérant avoir été accessible ;)

Sur de nombreux projets web, j’ai pu voir des personnes être bloquées pour rediriger les utilisateurs vers une page de login personnalisée. Elles avaient monté des authentifications Custom sans Forms. Pourtant, elles utilisaient la configuration de l’authentification Forms pour fixer la page de Login.

Exemple :

<system.web>
  <authentication mode="Forms">
    <forms loginurl="~/Login">
  </forms>
  </authentication>
</system.web>

Ceci n’est pas très élégant et peut compliquer la compréhension de vos intentions : « Authentification Forms, ou pas Forms ???? »

Heureusement, il existe une solution plus élégante : Coder un module de redirection. Ce module aura pour vocation de rediriger l’utilisateur dès que l’accès à une page lui est refusé. Ceci, sans avoir connaissance des processus d’authentification et d’autorisation.

Pour l’exemple, j’ai codé le module suivant :

- Dès qu’une erreur 401 est produite, on redirige l’utilisateur, vers la page de login.

- La page peut être configurée via les AppSettings.

Ce qui donne ceci :

using System;
using System.Configuration;
using System.IdentityModel.Services;
using System.Web;

namespace MyDemo.Modules
{
    public sealed class LoginPageHttpModule : HttpModuleBase
    {
        private const string LoginPageSettingsKey = "LoginPage";
        private const String LoginPageDefault = "~/Login";        
        private String _loginPage;

        /// 
        /// Chargement de la configuration
        /// 
        protected override void InitializePropertiesFromConfiguration()
        {
            // Utilisation des settings, si il sont présents
            _loginPage = ConfigurationManager.AppSettings[LoginPageSettingsKey] ?? LoginPageDefault;
        }

        /// 
        /// Initialisation du module
        /// 
        /// 
        protected override void InitializeModule(HttpApplication context)
        {
            // S'abonner pour connaitres les réponse données aux utilisateurs
            context.EndRequest += Context_EndRequest;
        }

        /// 
        /// Action en fin de request web
        /// 
        /// 
        /// 
        private void Context_EndRequest(object sender, EventArgs e)
        {
            // Test si il y a un refus d'autorisation
            if (HttpContext.Current.Response.StatusCode == 401)
            {
                HttpContext.Current.Response.Redirect(_loginPage);
            }
        }
    }
}

Côté configuration, il suffit d’ajouter le module à la liste des modules web

<system.webserver>
  <modules>
    <add name="LoginPageHttpModule" type="MyDemo.Modules.LoginPageHttpModule, MyDemo"/>
  </modules>
</system.webserver>

Et on peut définir sa page via les settings

<appsettings>
  <add value="~/Login" key="LoginPage"/>
</appsettings>

Voila ! Simple et efficace en WebForm comme en MVC ;)

 
		

Pour faire suite à mon précédent article sur l’update avec Entity Framework, voici une autre une idée qui a la peau dure : “pour supprimer des données avec EF, il faudrait systématiquement aller chercher en base l’entité avec toutes ses propriétés”.

Même si cela à longtemps été le cas, ceci est faux aujourd’hui. Avec EF, on peut effectuer une suppression en un seul DELETE.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à supprimer (logique).

// Instanciation de l'entité à supprimer
Customer entity = new Customer
{
    Id = 10// ma clé primaire
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter le fait que l’entité doit être supprimée.

// Recupération de l'entry et la marquer pour suppression
var entry = _datacontext.Entry(entity);
entry.State = System.Data.Entity.EntityState.Deleted;

 

5. Lancer l’enregistrement des modification, donc l’exeution du DELETE.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean DeletCustomer(Int32 id)
{
    // Instanciation de l'entité à supprimer
    Customer entity = new Customer
    {
        Id = id,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et la marquer pour suppression
    var entry = _datacontext.Entry(entity);
    entry.State = System.Data.Entity.EntityState.Deleted;

    // Enregistrement
    return _datacontext.SaveChanges() > 0;
}

Avec MVC, Entity Framework a pris un essort incroyable. Les mauvaises pratiques aussi. Je profite de cet article pour tordre le coup à une idée qui a la peau dure : “pour mettre à jour des données avec EF, il faudrait systématiquement utiliser l’entité avec toutes ses propriétés”.

C’est est faux. Avec EF, on peut effectuer des mises à jour en choisissant les propriétés utiles.

Ceci peut se faire en quelques étapes clés :

1. Instancier un objet avec les valeurs voulues. Seul impératif: utiliser la clé primaire de l’enregistrement à mettre à jour. Le set sur les propriétés n’a pas besoin d’être fait lors de l’instanciation, ceci facilite juste l’écriture.

// Instanciation de l'entité à mettre à jour
Customer entity = new Customer
{
    Id = 10,// ma clé primaire
    Name = "Duc",
    FirtName = "Donald",
    Email = "faux.mail@outlook.com",
};

 

2. Attacher l’entité au contexte de donnée.

// Attacher l'entité au context
_datacontext.Customers.Attach(entity);

 

3. Expliciter les propriétés qui seront modifiées.

// Recupération de l'entry et marquages de propriété à mettre à jour
var entry = _datacontext.Entry(entity);
entry.Property(c => c.Name).IsModified = true;
entry.Property(c => c.FirtName).IsModified = true;
entry.Property(c => c.Email).IsModified = true;

 

4. (optionnel) Désactiver la validation Si on ne modifie pas certaine propriété qui ont des contraintes (ex: une propriété qui ne peut pas être null).

// Désactiver la validation 
// pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
_datacontext.Configuration.ValidateOnSaveEnabled = false;

 

5. Lancer l’enregistrement.

// Enregister les modifications
Boolean result = _datacontext.SaveChanges() > 0;

 

Et pour ceux qui voudraient avoir une idée de ce que cela peut donner dans une méthode complette :

public Boolean UpdateCustomer(Int32 id, String name, String firstName, String email)
{
    // Instanciation de l'entité à mettre à jour
    Customer entity = new Customer
    {
        Id = id,
        Name = name,
        FirtName = firstName,
        Email = email,
    };

    // Attacher l'entité au context
    _datacontext.Customers.Attach(entity);

    // Recupération de l'entry et marquages de propriété à mettre à jour
    var entry = _datacontext.Entry(entity);
    entry.Property(c => c.Name).IsModified = true;
    entry.Property(c => c.FirtName).IsModified = true;
    entry.Property(c => c.Email).IsModified = true;

    // Enregistrement
    try
    {
        // Désactiver la validation 
        // pour ne pas chercher à valider des donnée qui ne font pas partie de l'update
        _datacontext.Configuration.ValidateOnSaveEnabled = false;
        // Enregister les modifications
        return _datacontext.SaveChanges() > 0;
    }
    finally
    {
        // Retour à la normale
        _datacontext.Configuration.ValidateOnSaveEnabled = true;
    }
}

Si existait un concours des fausses idées autour de l’utilisation d’un bloc Try, Catch, Finally en .net, j’en proposerais deux :

1. En cas d’exceptions “très particulières”, On peut sortir d’un Try sans aller dans un Catch générique. Il faut donc coder un Finally et utiliser des variable pour savoir si tout c’est bien passé.

Exemple C# :

// Je déclare des variable
// Je déclare aussi des variable pour savoir si tout c'est bien passé
Boolean toutVaBien = false;
try
{
    // Faire qqchose

    // Fin de qqhcose
    toutVaBien = true;
}
catch(Exception ex)
{
    // Je capture tout
}
finally
{
    // Je corrige mon context car je sais que tout ne s'est pas bien passé
    if (!toutVaBien)
    {

    }
}

Désolé, c’est faux. Si il y a exception, on passera par le catch. Ceci est valable, même si’il y a une exception système (on pourra même savoir ce qu’elle contient). Il n’y a pas d’exception “particulières”, “très particulières”, voir “trop particulières” qui puissent passer à côté du Catch.

Seul cas “possible” : le processus de l’application est coupé. Dans ce cas, le finallly ne sert à rien. Votre application est Off, un point c’est tout Winking smile

 

2. Il faut catcher finement ses exceptions pour avoir de meilleures performances et un impacte moindre sur les ressources système.

Exemple C# :

try
{
    // Faire qqchose
}
catch (MyTypedException ex1)
{
    // J'application la corretion générique
    Corriger();
}
catch (Exception ex2)
{
    // J'application la même corretion générique
    Corriger();
}

Désolé, c’est aussi faux. Ce code n’a aucun impact bénéfique. En plus, faire deux fois la même opération dans deux Catch différents. Ce qui induit une redondance inutile Winking smile

voilà, si vous avez d’autres blagues du genre, il ne faut pas hésitez à les partager.

Parmi les fonctionnalités de 2012R2, il en est une dont je ne pourrai plus jamais me passer. Il s'agit du « Network Interface Teaming ». Pour ceux qui auraient hiberné ces dernières années et qui ne connaitraient pas cette fonctionnalité, voici un lien vers la documentation : NIC Teaming Overview

En voulant configurer cette fonctionnalité avec un switch ProSAFE Plus, j'ai été désagréablement surpris par le manque d'informations techniques fourni par Netgear.

Côté switch, la configuration n'est pas très compliquée. Il faut juste savoir dans quel ordre effectuer les opérations.

Pour débuter, on doit passer par le lien  « LAG » (pour Link Aggregation Group) du menu « System ». Il faut ensuite se rendre sur « LAG Membership » pour sélectionner les ports réseau constituant un group.

Ex : pour le groupe 1, il faut sélectionner LAG ID=1. Pour associer les ports, il suffit de cocher la prise réseau voulue. Ensuite on utilise la commande « Apply ».

 

Pour que le groupe fonctionne, il faut ensuite passer par « LAG Configuration ». Cocher la ligne que l'on veut activer, et sélectionner « Enable » dans la liste déroulante. Puis « Apply ».

Côté Windows Server, Netgear ne permettant pas d'avoir une information technique complète sur la manière dont fonctionne le LAG, on ne peut pas savoir quel mode il faut appliquer au NIC Teaming. Pour arriver à avoir un agrégea de liens qui fonctionne correctement et de manière stable, il m'a fallu y aller au hasard et attendre L.

La logique qui voudrait que « dans le doute » on applique une configuration dynamique (mode LACP) n'a pas été payante. L'agrégat à fonctionné une petite heure avant de planter. Il m'a fallu rebooter le switch à distance pour que le serveur retrouve le réseau.

Le mode à utiliser est donc « Static Teaming ».

Note : le mode de « load balancing mode » ne concernant que le serveur, le switch n'a pas d'impact sur celui-ci.

À l'usage, le lien est stable et performant, que du bonheur ;)

Lors de la préparation d'un package pour le Windows Store, il est important d'avoir une politique de numérotation claire. Dans le cas où l'on prépare des packages pour plusieurs plateformes, ceci est encore plus important, car le store peut vous empêcher de publier votre application.

Pour ne pas se faire avoir, il faut bien saisir les trois règles de base :

  • Les nouvelles versions doivent avoir des numéros de versions plus élevés que les précédentes (logique)
  • Les packages des plateformes les plus récentes doivent avoir les numéros de versions les plus élevés.
  • La numérotation est libre. Il n'y a pas de règle sur les notions : majeur, mineur, révision, build.

Pour ne plus me poser de question, j'ai choisi d'appliquer systématiquement la stratégie suivante :

  • La première composante du numéro de version me sert à noter ma realese.
  • La seconde et la troisième composante me servent à numéroter la plateforme (10, 8.1, 8.0, 7.5 …etc… ). Exemple : Windows 10 devient 10.0. Vu que je commence à ne plus publier pour Windows 8.0, il n'est pas rare que pour Windows 8.1, j'utilise uniquement le numéro 8 sans ajouter de 1 sur le numéro de révision (troisième composante du numéro de version)
  • Le reste me sert en cas d'échec de certification de l'application.

Ainsi, pour une première version, j'aurai :

  • 1.10.0.0 pour une app UWP, donc pour Windows 10
  • 1.8.1 pour la version Windows 8.1 (si je pousse une Universal App avec une version Windows phone, je pousse un numéro de build en plus)
  • 1.8.0 pour la version Windows 8.0
  • Etc…

La version suivante sera alors numérotée :

  • 2.10.0.0 pour une app UWP, donc pour Windows 10
  • 2.8.1 pour la version Windows 8.1 (si je pousse une Universal App avec une version Windows phone, je pousse un numéro de build en plus)
  • 2.8.0 pour la version Windows 8.0
  • Etc…

 

Même si on respecte ces règles, lors de l'upload des packages, il n'est pas rare d'avoir des messages d'information de ce type :

Dans le cas présent, le premier message indique que l'on va remplacer un package. Ceci est donc normal.

Le second message se produit, car j'ai uploadé une version pour Windows 8.1 avant la version pour Windows 10. Le Store fait donc la comparaison entre mon nouveau package et l'ancien. Le message est donc tout à fait normal et disparaitra à partir du moment où j'aurai uploadé la version pour Windows 10.

Pour bien comprendre ce qui se passe à ce moment, il faut regarder en bas de page : on y voit clairement que la version pour Windows 8.1 est à remplacer, mais que la version pour Windows 10 n'a pas encore été uploadée.

Astuce : si on veut pousser une version pour Windows 8.1 sans pousser de mise à jour pour Windows 10, il faut donc jouer avec la dernière composante du numéro de version (la build)

 

Si je pousse le package pour Windows 10, j'obtiens l'affichage suivant. J'ai poussé tous les packages utiles. Je peux publier :

    

Heureux propriétaire d'un Band 2 remplacé par le SAV, je viens de me retrouver confronté à un problème peu ragoutant : l'application Microsoft Health n'arrive pas à joindre le Band. Moralité, le Band est inutilisable.

Heureusement, le problème est connu et l'astuce est toute simple. L'application Microsoft Health a un bug qui fait qu'il est impossible de coupler un Band 2 avec un Windows Mobile 10, si celui-ci n'utilise pas la langue anglaise en version US. Pour coupler son téléphone avec sont Band, il suffit donc de passer sa langue en anglais US, rebooter le téléphone et relancer le processus de couplage.

L'application détecte le Band du premier coup et le couplage peut se faire. Quand le processus est terminé, on peut changer la langue de son téléphone sans problèmes, le Band continu à se synchroniser normalement.

Dans SSIS, la manipulation de champ de type TEXT n’a rien de très compliqué. Étrangement, elle semble en rebuter plus d’un. Pour faciliter la chose, j’ai traduit ma snippet VB.net (oui au début de SSI, comme avec WF, il n’y avait que du VB).

Voici donc les 3 méthodes que j’utilise couramment pour  manipuler un champ TEXT. Dans SSIS, pour ce cas on a un DataType : DT_TEXT avec un CodePage : 1252, ce qui explique les encodages (à adapter en fonction des besoins)

 

Méthode pour lire un Blob et obtenir ne retour une String

///  
/// Lire un blob 
///  
///  
///  
private static String BlobToString(BlobColumn blob) 
{ 
    try 
    { 
        if (blob == null) 
        { 
            return null; 
        } 
        else 
        { 
            Int32 length = Convert.ToInt32(blob.Length); 
            Byte[] data = blob.GetBlobData(0, length); 
            return System.Text.Encoding.GetEncoding(1252).GetString(data); 
        } 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
        return null; 
    } 
}

Méthode pour écrire une String dans un Blob :

///  
/// Ecriture d'un text dans un blob 
///  
///  
///  
private static void StringToBlob(String text, BlobColumn blob) 
{ 
    try 
    { 
        if (String.IsNullOrWhiteSpace(text)) return; 
 
 
        // Ecriture de la donnée 
        Byte[] data = System.Text.Encoding.GetEncoding(1252).GetBytes(text); 
        blob.AddBlobData(data); 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
    } 
}

 

En bonus, la variante avec un StringBuilder :

///  
/// Ecriture d'un text dans un blob 
///  
///  
///  
private static void StringToBlob(StringBuilder sb, BlobColumn blob) 
{ 
    try 
    { 
        // Test le StringBuilder 
        if (sb == null || sb.Length <= 0) return; 
 
 
        // Test si on a un text utilisable 
        String text = sb.ToString().Trim(); 
        if (String.IsNullOrWhiteSpace(text)) return; 
 
 
        // Ecriture de la donnée 
        Byte[] data = System.Text.Encoding.GetEncoding(1252).GetBytes(text); 
        blob.AddBlobData(data); 
    } 
    catch (Exception ex) 
    { 
        Trace.TraceError(ex.Message); 
    } 
}

Si votre Band 2 a un petit problème ou défaut matériel, il peut être retourné gratuitement au support Microsoft. Bien entendu, si le problème est autre et qu'il n'est pas couvert par la garantie, des frais peuvent être occasionnés.

Le lien à connaitre pour cela :

https://www.microsoft.com/microsoft-band/fr-ca/support/troubleshoot

Une fois sur cette page, on doit choisir l'option 3, puis se laisser guider jusqu'à l'impression de l'étiquette de retour UPS.

Pour les personnes qui n'arrivent pas à lire le numéro de série du Band, celui-ci est imprimé sur l'étiquette en bas de la boite d'origine du Band (préfixé par SN).

Note : pensez à bien lire les consignes d'emballage et de préparation du Band. Il y est notamment expliqué qu'il ne faut pas utiliser la boite d'origine de celui-ci.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Office 365: Utiliser les alertes dans SharePoint Online par Blog Technique de Romelard Fabrice le 11-30-2016, 12:45

- Windows: Comment comparer les outils de copie de fichiers disponibles en mode console avec un script PowerShell par Blog Technique de Romelard Fabrice le 11-18-2016, 11:17

- TFS 2017 est disponible ! par Blog de Jérémy Jeanson le 11-17-2016, 08:04

- Office 365: Configurer l’ouverture des fichiers dans Office Web Apps pour une Librarie Documentaire par Blog Technique de Romelard Fabrice le 11-15-2016, 17:14

- Office 365: Comment gérer les Access Requests dans les sites SharePoint Online par Blog Technique de Romelard Fabrice le 11-10-2016, 15:11

- Windows 2008 R2: Réduire la taille du répertoire system volume information par Blog Technique de Romelard Fabrice le 11-07-2016, 10:01

- UWP et langues indisponibles ? par Blog de Jérémy Jeanson le 11-04-2016, 12:54

- Impossible de se connecter à Windows Server Essentials 2016 par Blog de Jérémy Jeanson le 10-29-2016, 09:55

- Changer la langue d’un Windws Server Core 2016 par Blog de Jérémy Jeanson le 10-27-2016, 17:51

- Upgrade Windows Server 2016 in place et NIC Teaming par Blog de Jérémy Jeanson le 10-26-2016, 17:14