Se connecter en remote shell sur Windows Serveur avec WinRM et .NET

Windows Remote Management permet d’ouvrir à distance un shell sur Windows Server 2008 (WinRM existe depuis Windows Vista et Windows Server 2003 R2). Concrétement, il est possible d’exécuter des lignes de commandes sur un serveur à distance.

Pour des raisons évidentes de sécurité, certains pré-requis sont nécessaires. Si l’ordinateur client n’est pas sur le même domaine que le serveur, ou si l’authentification ne se fait pas par Kerberos alors les transmissions doivent être chiffrées. Concernant la ligne de commande, les droits sont respéctés. Un utilisateur qui ne présente pas les droits suffisants pour exécuter une commande sur le serveur se verra refuser l’exécution de la dite commande à distance.

Requêter Active Directory via .NET

Active Directory, le service d’annuaire de Microsoft se repose sur le protocole LDAP. Pouvoir se connecter à l’Active Directory, y ajouter des utilisateurs, des groupes, etc… est possible avec le framework .NET grâce au namespace System.DirectoryServices.

Avant de commencer le code, il faut ajouter une référence dans votre projet vers System.DirectoryServices.

Se connecter à Active Directory

La connexion se fait en 2 temps. Premièrement, on créé un DirectoryEntry avec le serveur, nom d’utilisateur, mot de passe, etc… Si une correspondance est faite dans l’AD, on continue. Si le couple utilisateur/mot de passe, l’adresse du serveur n’est pas bonne, etc… une exception de type DirectoryServicesCOMException sera levée. Si la connexion est faite, on pourra tester que pour se connecter, l’utilisateur doit être dans le groupe administrateur. Cette recherche se fait à l’aide d’un DirectorySearcher. La syntaxe du filtre est celle propre à LDAP. Le filtre utilisé ci-dessous, vérifie que l’utilisateur a bien pour nom “Aymeric”, qu’il appartient au groupe administrateur et qu’il est bien de type “user”.

Documenter son code .NET avec GhostDoc

Bien documenter son code est important afin d’aider d’une part d’autres développeurs à comprendre le code le plus rapidement possible mais aussi à soi-même afin d’être le plus efficace possible lors de la maintenance du code.

Visual Studio utilise le XML pour ses commentaires, pour par exemple ajouter une description à une méthode.

/// <summary>
/// Tests the specified param1.
/// </summary>
/// <param name="param1">The param1.</param>
/// <param name="param2">The param2.</param>
/// <param name="param3">The param3.</param>
/// <param name="param4">The param4.</param>
/// <returns>This method return 1</returns>
public int Test(int param1, int param2, int param3, int param4)
{
    return 1;
}

Si l’application fait plusieurs milliers de lignes, il est long et fastidieux de documenter chaque méthode, classe, etc… Souvent la quantité se fait au détriment de la qualité. Pour remédier à cet obstacle et toujours garder un code correctement documenté, il est possible d’utiliser un outil nommé GhostDoc. **GhostDoc **s’intègre à Visual Studio (de 2005 à 2010) et génère via un raccourci clavier (Ctrl-Shift-D par défaut) la documentation d’une méthode, classe, etc… Seule condition, respecter quelques standards de nommage dans votre code. Par exemple “myParam” pour un paramètre et “DefineTheParam” pour une méthode. En effet GhostDoc va découper les noms de paramètres, méthodes, etc… afin de construire des phrases dans la documentation.

Envoyer un email grâce à un template en ASP.NET et C#

Dans un article précédent, j’expliquais comment envoyer un email en C#, un autre aspect intéressant de l’envoi de mail est de pouvoir utiliser un fichier texte comme template. Cette fonctionnalité est utilisée notamment par le contrôle _**CreateUserWizard avec le _MailDefinition : **

<MailDefinition BodyFileName="~/Skels/template.txt" Subject="Sujet du mail">
</MailDefinition>

Le code ci-dessus permet donc d’utiliser le contenu du fichier _template.txt _comme corps de notre email.

Pour reproduire ce comportenant en C#, il faut utiliser la classe **MailDefinition **comme exposé dans l’exemple suivant.

‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Je continue mes articles sur l’ASP.NET et sur DXperience.

Dans le “Demo Center” de Dxperience (logiciel qui présente des exemples d’utilisation de cet outil). Dans la partie ASP.NET -> XtraReports, les exemples peuvent ne pas fonctionner si votre système est en 64 bits.

L’erreur obtenue est :

Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Pour remédier au problème, rendez-vous dans la console de gestion du serveur IIS, soit dans Server Manager > Roles > Web Server (IIS) > Internet Information Services (IIS) Manager pour Windows Server ou dans Computer Management > Services and Applications pour Windows Vista ou Seven.