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.

ObjectDataSource et Guid, propriété non trouvée en ASP.NET

Lorsque l’on veut utiliser un GridView pour ajouter/modifier/supprimer des données dans une table SQL qui a pour clé primaire un **Guid **(par exemple aspnet_Users), une erreur survient lorsque l’on veut modifier ou supprimer un élément :

Could not find a property named 'xxx' on the type specified by the DataObjectTypeName property in ObjectDataSource 'yyy'

Tout semble pourtant bien configurer, mais l’erreur persiste. J’ai été confronté à ce problème avec la table aspnet_Users, qui contient les utilisateurs créés avec le système interne d’ASP.NET.

Réparer le namespace des fichiers .dbml utilisés pour Linq To SQL en .NET

En utilisant Linq To SQL, il arrive après une modification du fichier .dbml de ne plus avoir accès aux données en affichant une erreur du type :

The type or namespace name 'Article' could not be found (are you missing a using directive or an assembly reference?) 

Pour résoudre ce problème, vérifier premièrement dans le fichier .designer.cs de votre fichier .dbml que le namespace est correct (VotreProjet.LeDossier par défaut).

Si le problème persiste, vérifier dans les propriétés du fichier .dbml que Entity Namespace et Context Namespace aient bien la valeur du namespace précisée dans le fichier .designer.cs.

Introduction à ADO.NET en C#

ADO.NET est un ensemble de composants présents de base dans le framework .NET permettant l’accès et la gestion de données situées sur une base de données relationnelle (SQL Server, Oracle, etc…) ou non. ADO.NET est une évolution de ADO (ActiveX Data Objects).

Les classes ADO.NET peuvent être divisées en 2 parties. Les classes permettant de se connecter à la source de données et les classes utilisées pour gérer les données.

La connexion à la source de données

Pour se connecter à une base de données via ADO.NET un Data Provider (fournisseur de données) correspondant à la base de données utilisée. Ainsi le Data Provider de SQL Server est optimisé pour fonctionner avec les bases de données SQL Server, idem pour le Data Provider Oracle. Tous les Data Providers sont dérivés d’une seule et même classe, ils implémentent les mêmes méthodes, propriétés, et fonctionnent donc de la même manière. Dans certains cas, les Data Providers peuvent implémenter des fonctionnalités spécifiques à la base de données utilisée (exemple des requêtes XML pour SQL Server).

Empêcher la connexion automatique de l’utilisateur après sa création avec un CreateUserWizard en ASP.NET

Visual Studio propose un contrôle permettant la création d’utilisateurs dans la base de données : CreateUserWizard.

Ce contrôle est un gain de temps non négligeable, mais lorsque l’on veut sortir du cadre classique de l’inscription de membres, il faut chercher un peu pour obtenir ce que l’on souhaite.

Dans le cadre d’un panneau d’administration, il peut être utile de permettre la création d’utilisateurs par les administrateurs. Cependant le comportement par défaut du CreateUserWizard est d’automatiquement connecter l’utilisateur courant avec le compte qui vient juste d’être créé, ce qui est embêtant dans le cadre d’un panneau d’administration.

Modification des données grâce à Linq To SQL et aux procédures stockées

Cet article est la suite de l’article Lier une base de données et un GridView avec Linq To SQL.

Ici il est question des procédures stockées. Comme vous avez pu le remarquer dans l’article précédent, nous n’avons écrit aucune ligne de code pour construire des requêtes SQL, tout s’est fait automatiquement.

Pourquoi s’embêter à écrire du code alors ?

Les procédures stockées sont enregistrées et pré-compilées dans la base de données SQL Server, ce qui est un gain de **rapidité **et de performance. Toutes les procédures stockées sont enregistrées au même endroit dans la base de données ce qui simplifie grandement leurs éditions. Dernier atout qui n’est pas à négliger, la sécurité. En effet toutes les modifications de la base de données se font via les procédures stockées. A aucun moment l’utilisateur n’a un accès direct à la table.