Le blog de Kropernic

Etablir une connexion FTPS avec .NET

Kropernic — Tue, 15 Jul 2014 08:43:13 +0000

De nos jours, il n’est pas rare d’échanger de l’information via le protocole FTP (File Transfert Protocol). Mais depuis l’affaire PRISM, l’accent est davantage mis sur la sécurité de ces échanges. S’il est facile de trouver des libraires permettant d’utiliser le protocole FTP et SFTP (SSH File Transfert Protocol), il l’est un peu moins d’en trouve une capable de faire du FTPS (File Transfert Protocol over SSL). Vu que je m’y suis heurté ces deux dernières semaines, je vous présentes mes « découvertes ».

Avant d’aller plus loin, il est bien sûr possible de faire tout cela directement avec le framework .NET (via l’espace de nom NET) mais cela serait assez fastidieux. Et puisque d’autres l’ont déjà fait pour nous, inutile de réinventer la roue.

Comme annoncé dans l’introduction, je me suis heurté au problème pendant quelques temps. Tentant d’abord d’utiliser directement le framework .NET., je me heurtais à une erreur me disant « Unable to connect to the remote server. ». Sans plus de détail, c’est un peu léger pour permettre le débogage. J’ai donc fouillé le net et après quelques essais avec des libraires diverses, je suis tombé sur System.Net.FtpClient. Une libraire qui m’a l’air assez bien faite et simple d’usage mais surtout, fonctionnelle !

Sans plus attendre, un peu de code avec, comme mise en situation, la récupération de fichiers au format CSV (pratiques pour l’échange de données d’une compagnie à une autre) depuis un serveur distant.

Premièrement (je devrais dire deuxièmement car il faut ajouter la dll aux références du projet en premier lieu), importons l’espace de nom histoire de pouvoir coder plus légèrement.

1	Imports System.Net.FtpClient

Et maintenant le vif du sujet, la récupération des fichiers. Voici la procédure. Nous la commenterons ensuite ligne par ligne.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Private Sub GetCsvFiles()
Try
Dim ftps = New FtpClient
ftps.Host = "ftps.LeServeurDistant.be"
ftps.Credentials = New Net.NetworkCredential("username", "password")
ftps.Port = 990 'port par defaut
ftps.DataConnectionType = FtpDataConnectionType.PASVEX

AddHandler ftps.ValidateCertificate, AddressOf OnValidateCertificate

ftps.EncryptionMode = FtpEncryptionMode.Implicit

For Each item In ftps.GetListing("le/chemin/des/fichiers/")
If item.Type = FtpFileSystemObjectType.File Then
If item.Name.EndsWith(".CSV") Then
Console.Writeline("fichier en cours : " & item.FullName & ")" 'affichage du fichier en cours de traitement dans la console
Dim reader As New IO.StreamReader(ftps.OpenRead(item.FullName), Text.Encoding.Default)
Dim writer As New IO.StreamWriter(My.Settings.storageFolder & item.Name, False, Text.Encoding.Default)
Dim line As String = reader.ReadLine
While Not reader.EndOfStream
writer.WriteLine(line)
line = reader.ReadLine()
End While
writer.WriteLine(line)
writer.Close()
writer.Dispose()
reader.Close()
reader.Dispose()
End If
End If
Next
If ftps.IsConnected Then
ftps.Disconnect()
End If
Catch ex As Exception
Console.WriteLine(ex.Message)
End Try
End Sub

Comme vous l’aurez remarqué, j’ai choisi d’utiliser un projet de type Application Console. En effet, pas besoin ici de jolis écrans. La console nous suffira pour afficher les infos utiles à suivre le bon déroulement du processus.

Décortiquons à présent ensemble cette procédure.

Ligne 2 : Ouverture d’un bloc Try…Catch. Une bonne habitude à prendre, tout simplement.
Lignes 3-6 : Création d’un objet FtpClient (que j’ai nommé ftps) auquel on assigne les valeurs qui vont bien aux propriétés habituelles que sont Host, Port et Credentials.
Ligne 7 : Le type de connexion. Vous avez ici plusieurs possibilités. Dans mon cas, le serveur distant me renvoyant une adresse privée (192.168.X.X), il me fallait utilisé PASVEX.
Ligne 9 : Ajout d’un gestionnaire d’événement pour la validation des certificats. J’y reviendrai après.
Ligne 11 : Il s’agit ici de la raison pour laquelle nous faisons tout ça. C’est cette ligne qui définit le mode d’encryption des données. Avec le mode Implicit, les données sont cryptées de bout en bout. Avec le mode Explicit, l’encryption démarre après les politesses d’usages échangées avec le serveur.
Ligne 13 : Démarrage d’une boucle qui va parcourir les éléments du répertoire (du serveur distant) passé en paramètre.
Ligne 14 : Vérification que l’élément en cours est bien un fichier. Il pourrait s’agir d’un répertoire ou d’un lien symbolique.
Lignes 15-30 : Ici, rien de bien spécifique. Si le fichier est bien un fichier CSV, on crée un stream de lecture et un stream d’écriture et on copie le fichier ligne par ligne en n’oubliant pas de libérer les ressources à la fin. Pour un autre format de fichier, cette méthode pourrait ne pas convenir. Notez également que j’utilise les paramètres de projet pour définir où stocker le fichier de notre côté.
Lignes 32-34 : Si ce n’est pas déjà fait, fermeture de la connexion qui a été ouverte par la commande GetListing. On n’est jamais trop prudent.
Lignes 35-37 : Affichage du message d’erreur éventuel.

Voilà pour ce qui est du code de la procédure. Revenons maintenant sur la validation des certificats. Car qui dit FTPS, dit certificats à accepter par celui qui se connecte au serveur distant (c’est-à-dire nous).
Dans mon cas, je n’ai pas fait la fine bouche. La récupération de ces données étant primordiales et la source digne de confiance, je les accepte quoi qu’il arrive. Voici ce que cela donne :

1
2
3

Private Sub OnValidateCertificate(control As FtpClient, e As FtpSslValidationEventArgs)
e.Accept = True
End Sub

Pour les plus pointilleux, les objets X509Certificates, 509Chain et SslPolicyErrors sont accessibles via la variable d’événement e. Libre à vous de gérer la validation des certificats comme bon vous semble. Personnellement, ce n’est pas ma tasse de thé et de loin.

Et voilà, il ne reste plus qu’à appeler cette procédure dans le main de notre projet et le tour est joué.

En espérant que cela en aidera plus d’un.

Kropernic.

Gérer l’événement KeyPress d’une cellule d’un DataGridView

Kropernic — Fri, 27 Jun 2014 09:54:26 +0000

Gérer l’événement d’un contrôle est une chose basique à laquelle chaque débutant c’est un jour heurté. Une fois que le mécanisme est compris, la chose est en fait assez facile. Mais la chose est un peu moins triviale lorsqu’il s’agissait d’une cellule d’un DataGridView.

En effet, le contrôle DataGridView ne possède pas d’événement CellKeyPress vers lequel on serait tenté de se tourner (je n’entrerai pas dans les détails ici mais c’est en fait tout à fait normal que cet événement ne soit pas présent). Lorsque l’utilisateur édite une cellule, il n’édite en fait pas directement dans le DataGridView. En effet, ce dernier crée et affiche un contrôle en avant plan de la cellule pour permettre l’édition. Et c’est sûr ce contrôle qu’il faut gérer l’événement qui nous intéresse.

Voyons comment cela fonctionne concrètement.

Pour rester concis, disons que nous voulons empêcher toutes autres saisies qu’un nombre entier dans la cellule.

Commençons par écrire la procédure pour gérer la pression de touche proprement dite :

1
2
3
4
5

Private Sub EditingControl_KeyPress(sender As System.Object, e As System.Windows.Forms.KeyPressEventArgs)
If Not Char.IsNumber(e.KeyChar) Then
e.Handled = True
End If
End Sub

Cela se passe d’explication je pense.

L’astuce consiste maintenant à savoir comment ajouter la gestion de l’événement sur le contrôle d’édition afficher par notre DataGridView. C’est en fait assez simple mais il fallait le savoir. Ce contrôle nous est accessible très facilement via l’événement EditingControlShowing du DataGridView.

Nous pouvons donc maintenant écrire quelque chose dans ce goût-là :

1
2
3
4
5
6
7
8

Private editingControl As Control

Private Sub dgvExample_EditingControlShowing(sender As System.Object, e As System.Windows.Forms.DataGridViewEditingControlShowingEventArgs) Handles dgvExample.EditingControlShowing
If dgvExample.CurrentCell.OwningColumn.Name = "Le nom de la colonne en question" Then
editingControl = e.Control
AddHandler editingControl.KeyPress, AddressOf EditingControl_KeyPress
End If
End Sub

Ici, nous vérifions donc que la colonne que l’utilisateur édite est bien celle qui nous intéresse en vérifiant son nom et si le test est positif, nous nous abonnons donc à l’événement KeyPress de ce contrôle accessible via le paramètre e de l’événement. Et nous conservons une référence vers ce contrôle via la variable editingControl.

Il ne reste plus qu’à nous désabonner à l’événement contrôle une fois que l’édition est finie. Et c’est pour cela qu’il nous fallait garder une référence vers le contrôle en question. Car là, le framework ne nous donne pas « d’accès simplifié ».

1
2
3
4
5

Private Sub dgvExample_CellEndEdit(ByVal sender As System.Object, ByVal e As System.Windows.Forms.DataGridViewCellEventArgs) Handles dgvExample.CellEndEdit
If dgvExample.CurrentCell.OwningColumn.Name = "Le nom de la colonne en question" Then
RemoveHandler editingControl.KeyPress, AddressOf EditingControl_KeyPress
End If
End Sub

Et voilà, nous pouvons à présent empêcher les utilisateurs d’encoder n’importe quoi.

T-SQL : Récupérer le numéro de semaine d’une date

Kropernic — Wed, 25 Sep 2013 13:23:26 +0000

Trouver le numéro de la semaine d’une date donnée est un besoin qui revient régulièrement lorsque l’on en vient à gérer des données temporelles. Si au premier abord cela semble trivial, la fonction DATEPART pourrait bien vous réserver quelques surprises si vous n’y prenez pas garde (comme cela a été mon cas aujourd’hui).

Il ne s’agit pas ici de faire un descriptif détaillé de la fonction DATEPART. Pour cela, il y a la MSDN.

Intéressons-nous donc à l’argument WEEK. Comme on peut s’y attendre, l’utilisation de cette argument nous renvoi un numéro de semaine. Mais déjà un piège pointe le bout de son nez.
Selon la MSDN :

When datepart is week (wk, ww) or weekday (dw), the return value depends on the value that is set by using SET DATEFIRST.

Traduction :

Lorsque le paramètre est week (wk, ww) ou weekday (dw), le résultat dépend de la valeur définie par l’instruction SET DATEFIRST.

En effet, SET DATEFIRST permet de signaler à SQL SERVER quel est le premier jour d’une semaine.

En pratique, qu’est-ce que cela signifie ?

Voyons un cas concret. Pour nous faciliter la vie, créons une table de dates toute simple dont voici le code DDL ainsi que le code d’insertion de quelques lignes :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

CREATE TABLE T_DATE_DAT(
DAT_DATE DATE PRIMARY KEY
);
GO

INSERT INTO T_DATE_DAT
VALUES ('20120101'),
('20120102'),
('20120103'),
('20120104'),
('20120105'),
('20120106'),
('20120107'),
('20120108'),
('20120109'),
('20120110')

Sur base de ceci, nous pouvons maintenant faire quelques tests. Par défaut, le premier jour d’une semaine pour SQL SERVER est le dimanche.
Exécutons alors la requête suivante :

1
2
3
4
5

SELECT
DAT_DATE,
DATEPART(WEEK,DAT_DATE) AS 'WEEK'
FROM
T_DATE_DAT

Vous devriez obtenir comme résultat que la première semaine de 2012 va du 1 Janvier au 7 Janvier. Le premier étant un dimanche et le 7 un samedi.

Ce n’est pas vraiment ce nous attentions n’est-ce pas ?

Signalons maintenant à SQL SERVER que le premier jour d’une semaine est le lundi et exécutons à nouveau cette requête.

1
2
3
4
5
6
7

SET DATEFIRST 1;

SELECT
DAT_DATE,
DATEPART(WEEK,DAT_DATE) AS 'WEEK'
FROM
T_DATE_DAT

A présent, nos semaines commencent bien le lundi. C’est déjà un net progrès ! Cependant, si je regarde un calendrier sur lequel sont notés les numéros des semaines, je constate que la première semaine de 2012 commence en fait le 2 Janvier ! Cela s’explique par le fait que la première semaine d’une année est la semaine comprenant le premier jeudi de la-dite année. La première semaine de 2012 est donc bien la semaine allant du 2 Janvier au 8 Janvier.
N.B. : Cette numérotation n’est principalement utilisée qu’en Europe.

Et c’est là qu’est le piège. S’il est normal d’avoir des années de 53 semaines, l’utilisation de la fonction DATEPART avec l’argument WEEK vous retourna des semaines avec un numéro 54.

Mais alors comment faire pour récupérer le bon numéro de semaine avec la fonction DATEPART. Et bien tout simplement en n’utilisant pas l’argument WEEK mais ISOWK. Et oui, il fallait le savoir, il y a un argument pour récupérer le numéro de la semaine au format ISO.

Remplaçons donc le paramètre WEEK par ISOWK dans notre requête. Cela donne donc la requête suivante :

1
2
3
4
5

SELECT
DAT_DATE,
DATEPART(ISOWK,DAT_DATE) AS 'ISO WEEK'
FROM
T_DATE_DAT

Et nous récupérons maintenant les numéros de semaines correctes tels que nous les retrouvons sur tous calendriers (européens) qui se respecte.

Utilisation d’un fichier de configuration pour une dll

Kropernic — Tue, 18 Jun 2013 13:20:01 +0000

Bonjour,

Pour ceux qui comme moi voudraient utiliser un fichier de configuration avec une dll pour, par exemple, stocker une chaîne de connexion à une base de données, voici la procédure à suivre.

Premièrement, il faut bien sûr ajouter un fichier de configuration au projet et le nommer « .dll.config ».
Votre fichier devrait ressembler à ceci :

Deuxièmement, il faut modifier les propriétés du fichier pour qu’il se copie dans le répertoire d’output du projet GUI.

N.B. : Il est à noté que C# et VB ne gère pas les solutions multi-projets de la même manière. Il sera donc peut-être nécessaire de le copier manuellement.

Il faut maintenant ajouter la partie permettant de stocker la chaîne de connexion.

Jusque-là, rien de bien sorcier.

And now, the tricky part ! (Et maintenant, la partie la plus délicate !)

Le problème est qu’il n’est pas possible d’accéder aux informations placées dans ce fichier de configuration via My.Settings.
Il faut donc ruser pour ouvrir ce fichier de configuration et accéder à la partie qui nous intéresse (car il pourrait contenir bien d’autres choses que juste la chaîne de connexion).

Voici le code de la fonction que j’utilise dans la classe de base de ma couche DAL.

1
2
3
4
5
6
7
8
9
10
11
12

Private Shared Function CreateConnection() As SqlConnection
Dim cnx As New SqlConnection

'Open the configuration file using the dll location
Dim myDllConfig As Configuration = ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly.Location)
' Get the appSettings section
Dim myDllConfigAppSettings As AppSettingsSection = DirectCast(myDllConfig.GetSection("appSettings"), AppSettingsSection)
' return the desired field
cnx.ConnectionString = myDllConfigAppSettings.Settings("MyConnectionString").Value

Return cnx
End Function

En quelque mot, voici ce qu’elle fait :

instanciation de la connexion
ouverture du fichier de configuration
récupération de la bonne partie du fichier
affectation de la chaine de connexion
renvoi de la connexion

Vous voilà maintenant capable d’utiliser un fichier de configuration avec une dll.