Générer des ressources licenses buildées (App_Licenses.dll) à partir des fichiers licences.licx - Build Runtime Licenses

Comment générer des ressources licenses buildées (App_Licenses.dll) à partir des fichiers licences.licx? Après de nombreuses recherche voici un résumé de ces recherches ainsi que la solution à cette question.

Les fichiers licenses.licx sont des fichiers textes qui contiennent le nom de l'assembly ainsi que le nom du composant sur lequel agit une licence d'utilisation. Les applications ASP.Net (et les WCF applications) ont besoin d'avoir une dll qui comprends la licence car ces applications ne s'exécutent pas par elles-mêmes, elles sont exécutée par un process IIS. Pour ces applications, il ne suffit pas de simplement ajouter le fichier licenses.licx dans votre assembly et de lancer la compilation, mais il est nécessaire de les liers à des ressources compilées qui contiendra la license. On vous expliquera que pour générer ces assembly il suffit de faire un clic droit dans l'explorateur de solution de visual studio 2010 et de cliquer sur "Build Runtime Licenses". Le problème c'est que mise à part si vous travaillez sur un site Web vous ne verrez pas cette option. 

Alors, comment faire ? Il suffit de simplement ouvrir votre solution comme un Site Web (File > Open > Web Site) et de déposer votre fichier licenses.licx à la racine de votre projet. Et la, miracle, vous avez l'option "Build Runtime Licenses" disponible qui va vous générer le fameux fichier App_Licenses.dll dans le dossier Bin de votre application. Il ne reste plus qu'a rajouter cette assembly aux références de votre projet et fini les problèmes de licenses sur vos application asp.Net !

Cette solution marche également pour les projets de type "Wcf Application".

Client WCF à partir de l'interface .NET - le ChannelFactory

Souvent, pour réaliser un client sur un service WCF, on passe par une "Service Reference". Ce type de référence, va générer du code(Visual Studio) et notamment un client qui implémente une interface compatible avec l'interface du service. Après génération de ce code, si vous regarder votre code, vous trouverez d'une part l'interface au niveau de votre service et d'autre part l'interface générée gentiment par Visual Studio. Les datacontracts utilisés par votre service seront également dupliqués du coté du client.

L'avantage de cette solution est sa facilité de mise en place et l'indépendance du client par rapport au service. Le désavantage est cette duplication du code. Si vous êtes détenteur du code du service et donc de ses contrats, pourquoi ne pas directement utiliser ces contrats au lieu d'en régénérer dans votre assembly cliente ? Pour éviter cette duplication, il est possible de créer un client wcf à partir du contrat via la classe System.ServiceModel.ChannelFactory. Comment utiliser ce ChannelFactory ?

Pour voir le fonctionnement, nous allons faire une petite solution visual studio qui comprendra:

• Un assembly avec l'interface du service(Contracts)
• Un assembly avec l'implémentation du service(Services) - reférence Contracts
• Un host pour le service (SVCHost) - référence Services et Contracts
• Une console qui sera client du service (ConsoleClient) - référence Contracts

N'oubliez pas d'ajouter les références vers System.ServiceModel et System.Runtime.Serialization sur vos projets. Vous devriez alors avoir quelque chose comme :

Voici le code des différents composants :

 

Le code du host (hello.svc)

 Le code du client

Comme nous pouvons le voir ici, il n'y a pas de code généré. Le client référence simplement l'assembly contenant les interfaces et WCF va nous généré un client au travers de la classe ChannelFactory.

Le gros avantage est que si vous modifier votre interface, vous pouvez directement voir les impacts. Cette solution ne fonctionne néanmoins que dans un système fermé (entièrement sous contrôle d'une seule entité). Si vos services sont ouverts, vous ne pouvez pas fournir forcément fournir votre assembly de contrats. Dans ce cas la, une service reference s'impose !

Sources :

• http://msdn.microsoft.com/en-us/library/system.servicemodel.channelfactory.aspx

Définir les styles par défaut dans Word

Certaines configuration de Word ne montre pas les styles que vous utilisez le plus souvent. Dans mon cas, je suis tombé sur une machine ou Word ne me proposait pas les styles Titre1,Titre2,Titre3 ou Heading1, Heading2, Heading3 si votre MS Office est en anglais.

Alors comment faire pour configurer son bandeau ? Pour les styles, voici la procédure à suivre :

• Afficher la fenetre des styles (ctrl+alt+shift+s ou cliquer sur la petite flèche de la boite des style comme montré sur l'image ci dessous

•  Afficher la boite de dialogue Manage Styles

 

•  A partir de cette fenêtre, dans l'onglet Recommend, vous pouvez définir les styles à afficher par défaut (Show), à cacher (Hide) ou à cacher tant qu'il n'est pas utilisé (Hide until used)

• Enfin, vous avez la possibilité de préciser que vous souhaiter garder la configuration pour votre document ou pour tous les documents qui ont le même template

A socket operation encountered a dead network

Ce matin, en voulant me connecter à ma base de données Oracle locale via un projet Console C# avec devart dotConnect for Oracle

connection = new OracleConnection(ConfigurationManager.ConnectionStrings["XE"].ConnectionString);

 
voici le joli message d'erreur que j'ai obtenu :

Network error:: 10050 - A socket operation encountered a dead network < Host = 127.0.0.1:1521>

Un tnsping vers ma base de données m'indique que la base de données est joignable et que le problème vient donc de l'application .Net. Après de nombreuses recherches je tombe sur une discussion qui indique que cela peut venir du "Firewall Client for ISA Server". Après désactivation de ce process, j'obtiens le message suivant :

Socket error "An invalid argument was supplied"

Network error:: 10022 - An invalid argument was supplied < Host = 127.0.0.1:1521>

Alors que je perséverais dans mes recherches, je me suis souvenu que mes projets C# avait été déplacé sur un disque réseau ... Pour ceux qui ne le saurait pas, Windows n'autorise pas à une application se situant sur un disque réseau(qui n'est pas configuré comme étant un "disque de confiance") à effectuer des connections réseaux ...

L'une des solutions pour régler ce problème consiste donc simplement à déplacer votre exécutable sur votre disque local. Ces messages peuvent provenir d'autres problèmes sur votre machine mais avant de chercher trop loin vérifiez que votre application ne se trouve pas sur un disque réseau !