Patrice Manac'h Web Log : .Net

Rejouer des requêtes SOAP

pmanach — Wed, 11 Mar 2009 15:45:40 GMT

Un problème assez courant en dev : comment rejouer des requêtes SOAP, afin de reproduire un scénario (cas d’erreur à reproduire, développement sans accès à l’infrastructure, etc). Le premier outil qui vient à l’esprit est Fiddler. Le souci avec cet outil est que lorsque l’on veut rejouer une trace, les règles travaillent sur les urls, et donc les query string. En mode SOAP, le client poste sur une url unique, et Fiddler a du mal à s'y retrouver.

Il existe deux autres outils : strace et httpreplay. Le premier permet de capturer des échanges entre un client et un serveur. Le second permet de rejouer ces traces. Il permet de rejouer aussi les traces de Fiddler. Pour rejouer mes traces, déjà prises avec Fiddler, j’ai donc installé HttpReplay. Pius j’ai récupéré l’archive Fiddler, l’ai renommé en zip, et ai extrait le sous-répertoire raw.

En allant dans le répertoire d’installation de HttpReplay, j’ai lancé la commande suivante :

SOCKTRC.EXE /s:81 /e:HTTPREPLAY.DLL /LOG:c:\temp\raw /RESPECTPOST

avec :

/s:81, pour que l’outil écoute sur le port 81.
/e:HTTPREPLAY.DLL, pour préciser que le plugin httpreplay doit être utiliser.
/LOG:c:\temp\raw, pour préciser le répertoire contenant les traces.
/RESPECTPOST, pour préciser que la mise en correspondance entre un appel et sa réponse doit tenir compte du corps de la demande, et pas simplement de l’URI.

Ultime point à ne pas oublier avant de lancer le client du Web Service, positionner le proxy du poste à localhost, port 81:

Et après, j’ai pu retester tout mon scénario dans une VPC sans avoir besoin d’être réellement connecté au serveur :)

Simple mais efficace…

Ouvrir une fenêtre WPF sans menu système

pmanach — Tue, 22 Jul 2008 19:57:00 GMT

Mais avec une barre de titre, bien entendu :)

Par défaut, on peut ouvrir une fenêtre sans décoration, ou alors avec une barre de titre standard (menu système, boutons de redimmensionnement et de fermeture). Mais si on veut la barre de titre sans le reste, c'est un peut plus embêtant. On peut toujours jouer sur la propriété ResizeMode="NoResize" pour supprimer deux des trois boutons. Mais le bouton Close est du genre résistant :)

Pour le faire disparaître, il faut en fait faire un peut d'interop et surcharger la méthode OnSourceInitialized de l'objet Window :

/// <summary>

/// Raises the SourceInitialized event. Overrided to cancel the close button.

/// </summary>

/// <param name="e">An EventArgs that contains the event data.</param>

protected override void OnSourceInitialized(EventArgs e)

{

base.OnSourceInitialized(e);

// D‚sactive le menu systŠme de la fenˆtre

IntPtr hwnd = new WindowInteropHelper(this).Handle;

int windowLong = GetWindowLong(hwnd, -16);

SetWindowLong(hwnd, -16, windowLong ^ WS_SYS_MENU);

}

Et voila :)

Bon, il ne faut pas oublier de déclarer les deux API utilisées :

[DllImport("user32.dll")]

static extern int SetWindowLong(IntPtr hWnd, int nIndex, int dwNewLong);

[DllImport("user32.dll")]

static extern int GetWindowLong(IntPtr hWnd, int nIndex);

const int WS_SYS_MENU = 0x00080000;

Erreur lors de la migration d'un projet Web de Visual Studio 2005 à Visual Studio 2008

pmanach — Wed, 02 Jan 2008 17:28:00 GMT

C'est une erreur qui risque d'être assez courante. Vous ouvrez un projet web créé avec Visual Studio 2005 avec Visual Studio 2008. Ce dernier vous propose de migrer le projet, d'éventuellement le passer en .Net 3.5 et de faire une copie de sauvegarde. Mais que vous le laissiez en .Net 2.0 ou le passiez en .Net 3.5, à la compilation, vous vous prenez systématiquement l'erreur "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level This error can be caused by a virtual directory not being configured as an application in IIS.". Alors que cela fonctionnait très bien avec la version précédente de Visual Studio :(

Ici, le problème vient en fait de la copie de sauvegarde : dans le répertoire créé par l'assistant pour la sauvegarde, il y a une copie du fichier web.config qui conserve son extension. Lors de la compilation, VS2008 détecte la présence d'un fichier de configuration dans un sous-répertoire, tente de le prendre en compte, et tombe sur des directives qui ne sont pas autorisées dans un sous-répertoire. Soyez radical : déplacez ce répertoire de sauvegarde dans un autre répertoire, mais ne le laissez pas comme sous-répertoire de votre projet Web. Cela devrait beaucoup mieux se passer à la compilation :)

Wix et les custom actions .Net

pmanach — Tue, 01 Jan 2008 12:14:00 GMT

Bien que je n'en ai pas eu besoin pour mes tests, il y a des cas où appeler une custom action écrite en .Net reste nécessaire. Dans ce cas, pour appeler le code associé à un objet ProjectInstaller, vous pouvez toujours suivre la démarche suivante : http://blog.vagmim.com/2004/09/installing-windows-services-created.html

Visual Studio 2003, Vista et les Custom Actions

pmanach — Mon, 31 Dec 2007 15:53:00 GMT

toujours dans mes tests de compatibilité du Framework .Net 1.1 avec Vista (version 64 bits, qui plus est), je suis passé aux tests de projets de type setup. Je sais que VS2003 n'est pas supporté sous Vista, mais il faut parfois s'assurer que certains scénarios continuent de fonctionner. Et en l'occurence, le msi produit par VS ne devrait pas avoir de dépendance particulière à l'OS. Sauf que si :(

Je ne parle pas d'une condition triviale dans le projet setup qui testerait que l'os est un XP (version 5.1) au lieu de tester toute version supérieure ou égale à 5.1 pour embarquer les versions 6 et plus dans la foulée. Pour cela, si on a encore le projet, on peut changer le test. Et dans le cas contraire, on peut essayer de jouer avec les modes de compatiblités. Mais dans mon cas de figure, rien de tout cela : lors de l'installation de mon service via le msi généré, je me suis retrouvé avec un échec systématique et un erreur 11708 dans le journal d'événement sans information exploitable. Et l'indice de fiabilité de mon poste dégringolant à toute vitesse :(

En fouillant un peu, je suis tombé sur l'article suivant : http://arnshea.spaces.live.com/blog/cns!32B8884142441255!220.entry

Il semble en fait que dans le msi généré par VS 2003, un flag d'impersonification soit mal positionné au niveau des actions personalisées, ce qui passe sans problème sous XP ou 2003, mais se fait toper par l'UAC sous Vista. A priori, ce problème concernairait aussi les msi généré par Visual Studio 2005 RTM. N'ayant plus que des versions SP1+Vista fix, je n'ai pas pu faire le test. Par contre, j'ai testé les configurations suivantes :

Intégration du manifest dans l'exécutable puis génération du MSI avec VS 2003. Contrairement à ce que laisse entendre l'article, il y a moyen d'automatiser l'opération (cf ThemeMe sur http://www.msjogren.net/dotnet/eng/tools/). Mais pas moyen de passer la protection DEP sous Vista 64 bits. Je suppose donc que cela doit marcher avec un Vista 32 bits mais comme j'ai besoin de toutes les configurations, cela ne me convient pas.
Génération du msi avec un VS 2005+SP1+Vista fix (j'ai un doute sur l'utilité réelle de ce fix pour ce problème spécifique, mais passons). Victoire (de courte durée), le service s'installe bien sous Vista 64, les custom actions sont lancées (elles démarrent le service), et la désinstallation marche bien. Oui mais sur un XP 32 bits sans le Framework 2.0, une agaçante popup apparaît au lancement du msi :(
Idem que précédement mais en modifiant la condition pour demander une v1.1 du Framework (avec ou sans support d'une version ultérieure). Cela marche bien sur mon XP, mais plante sur mon Vista. Grrr....

Bon, je suppose que dans le dernier cas, en jouant avec Orca, on doit pouvoir faire sauter la dépendance, mais comme ce n'est pas automatisable, cela ne m'interesse pas. Autre solution, produire deux setup, un pour chaque plateforme. Les outils de télédistribution savent en général cibler des packages en fonction de variables comme l'OS, ce serait jouable. Mais cela ne me plaisait pas non plus.

Dernière solution, utiliser Wix. Cela ne m'enchantait pas trop car cela me semblait un peu "lourd". Mais comme on va l'intégrer à la prochaine version de VS, ce pouvait être l'occasion d'y jeter enfin un coup d'oeil. Et c'était en fait un bel à priori :

Je suis allé sur le site http://wix.sourceforge.net/index.html récupérer le package (la V2).
Je suis parti de l'exemple SampleFirst que j'ai testé tel quel
Puis je l'ai modifié pour référencer mon service, être par défaut en français (valeur 1036 pour les tag Langages) et cibler la plateforme x86 (tag Platforms='Intel' sur le noeud package).
Et voila :)

Pour référencer le service, j'ai ajouté le composant suivant :

<Component Id='MainService' Guid='04C7E6DD-A2C6-40B6-9069-083DC4A4BD2F'>

<File Id='service1.exe' Name='service1.exe' LongName='service1.exe' src='service1.exe'

DiskId='1' />

<ServiceInstall Id='service1.exe' Name='Service1' DisplayName='Service1'

Type='ownProcess' Interactive='no' Start='auto' Vital='yes' ErrorControl='normal' />

<ServiceControl Id='service1.exe' Name='Service1' Start='install' Stop='both' Remove='uninstall'

Wait='yes' />

<Registry Id='Service1InstallDir' Root='HKLM' Key='Software\Company\Service1'

Name='InstallDir' Action='write' Type='string' Value='[INSTALLDIR]' />

</Component>

avec en bonus pour mon test l'écriture d'une clé de registre. Au final :

Cela fonctionne bien sous XP 32 bits et Vista 64 bits.
Plus de message d'alerte sur une dépendance à une version du Framework.
Les custom actions ne servent plus à rien, le démarrage ou l'arrêt du service sont pris en charge par le msi généré par Wix.
Et donc, lors d'une désinstallation, plus de message d'alerte indiquant que certaines applications tournent encore et peuvent nécessiter un reboot.
Les binaires et clés de registre vont bien au bon endroit (dans HKLM\Software ou HKLM\Software\Wow6432Node pour les clés de registres par exemple).
En suivant le tutoriel et les exemples fournit sur le site de Wix, on a une solution qui marche en à peu près une heure. Ok, pour des tests complémentaires, des interfaces riches et ce genre de chose, c'est peut être plus couteux. Mais cela, ce ser pour une autre fois :)

Bon, le besoin de déployer du .Net 1.1 sur plusieurs plate-formes ne doit pas être très courant mais si cela peut éviter quelques galères et heures perdues inutilement...

Applications 32 bits et registre 64 bits, quelques points à savoir avant de s'arracher les cheveux

pmanach — Sat, 29 Dec 2007 13:45:00 GMT

J’étais tranquillement en train de tester une application .Net 1.1 sur un Vista 64 bits quand je suis tombé sur un point bloquant : mon application ne pouvait lire des clés dans la base de registre, clés que j’avais créé à la main avec regedit. Plutôt surpris, j’ai relancé regedit et vérifié : mes clés étaient bien là.

Un petit test rapide du bout de code incriminé avec Visual Studio 2005 : le même code arrive bien à lire les clés. Après avoir éliminé assez rapidement les questions de sécurité et de droits, j’en suis venu à me demander si ce n’était pas un problème de plate-forme. J’ai alors forcé la compilation de mon bout de code en mode x86 sous VS2005, et là, bingo : les clés n’étaient plus visible. Après quelques tests de confirmation (x86, x64, AnyCPU), cela s’est confirmé.

Après quelques recherches, je suis tombé sur ce post très intéressant : http://207.46.236.188/MSDN/ShowPost.aspx?PostID=2428227&SiteID=1

En particulier :

The rules are pretty straightforward:

.NET app compiled for "x86":

Always 32-bit

On 32-bit platforms, accesses 32-bit registry

On 64-bit platforms, accesses 32-bit registry (inside Wow6432Node)

64-bit registry inaccessible (without doing something weird)

.NET app compiled for "x64":

Always 64 bit

On 32-bit platforms, won't run

On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)

If you want to get to the 32-bit registry, you need to do something weird

.NET app compiled for "AnyCpu"

Either 32 or 64 bit depending on platform

On 32-bit platforms, accesses 32-bit registry

On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)

If you want to get to the 32-bit registry, you need to do something weird

"Something weird" technically requires passing a special flag to RegOpenKeyEx to obtain the alternate registry view. .NET doesn't expose any function that will do this nicely, so you'd have to drop to p/invoke to get there.

Alternatively if you want to get to the 32-bit registry from a 64-bit/AnyCpu app, you can hardcode the "Wow6432Node" path in (since the 32 bit registry is visible from 64 bit, but not the reverse), but MS explicitly recommends against this.

En fait, l'utilisation de la fonction ReOpenKeyEx nécessite effectivement de faire du p/invoke en utilisant l'option KEY_WOW64_32KEY (0x200), voir http://msdn2.microsoft.com/en-us/library/ms724878.aspx. Et il faut repasser cette option à chaque ouverture de sous-clé, l'api repassant systématiquement en mode par défaut quelque soit le handle passé en paramètre.

Le second cas marche aussi très bien en pratique, évite de faire appel à du p/invoke mais le fonctionnement n'est pas garanti à terme. L'idéal reste quand même d'avoir un setup qui cible la même plate-forme que l'application qu'elle installe (donc x86 si l'application a une dépendance à cette plate-forme, comme l'utilisation de SQL Ce 3.1) : les clés seront alors automatiquement créées sous le noeud Wow6432Node et visibles par l'application comme étant directement sous HKLM\Software. Ce faisant, que l'application soient déployées sur un XP 32 bits, ou sur un Vista 32 ou 64 bits, il n'y a aucune "bidouille" à faire. Et lors des tests manuels, pendand le dev par exemple, il faut juste ne pas oublier de créer les clés sous HKLM\Software\Wow6432Node sous peine de se poser beaucoup de questions :)

Publication ClickOnce avec Vista

pmanach — Tue, 05 Dec 2006 23:38:00 GMT

Si vous cherchez à tester la fonction de publication de VS 2005 avec Vista, par d"faut, vous allez vous prendre des erreurs de sécurité et une erreur de librairie CAPICOM qui n'existe pas. Pour les erreurs de sécurité, il suffit de lancer VS en mode admin mais pour CAPICOM c'est un peu plus compliqué :

installez le SDK Windows.
Allez dans C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin.
lancez regsvr32 capicom.dll

Bon, ce n'était pas si compliqué que cela :)

Visual Studio US, Vista FR et les extensions pour .Net 3.0

pmanach — Sun, 05 Nov 2006 22:07:00 GMT

Je sais que je cherche un peu les coups à vouloir faire fonctionner ensemble des logiciels beta dans des langues différentes mais pour l'instant, je m'en étais plutôt pas mal tiré. J'ai récement reconfiguré mon poste avec une version récente de Vista en français, j'ai installé Visual Studio en anglais et j'ai installé les extensions pour le Framework 3.0 (Cider, etc). Et là, la mauvaise surprise : en voulant créer un nouveau projet, je n'avais plus le choix que de créer un projet .Net 3.0 (WPF, WF, etc). Mais plus de projet librairie ou console. Hors, avant d'installer les extensions pour le Framework 3.0, j'avais eu l'occasion de constater que cela marchait.

En creusant, je me suis rendu compte que les projets "classiques" étaient tous localisés (dans un répertoire dédié au code pays, ici le 1033) alors que les projets .Net 3.0 étaient dans des répertoires ne dépendant pas de la langue. J'ignore en quoi l'installation des extensions modifie le comportement standard de devenv mais le fait est qu'après, Studio ne permettaient plus que la création de projet non localisés (voir localisées en français mais je n'ai pas creusé).

J'ai trouvé plusieurs solutions basées sur la recopie de fichiers dans des répertoires indépendant de la langue, dans un répertoire correspondant au français ou autre, mais la méthode la plus propre reste de lancer Visual Studio avec un paramètre permettant de fixer la langue : devenv.exe /LCID 1033

Une fois le raccourci modifié, je peux de nouveau charger VS avec tous les projets standards et les projets spécifiques au Framework 3.0...

Support d’APS .Net 1.1 sous Vista

pmanach — Mon, 05 Jun 2006 13:37:00 GMT

Question récurrente s’il en est…

Je suis tombé sur cet article sur le site www.asp.net : http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=993

Ce nouveau site a l’air d’être une vrai mine d’or

Compilation de Workflow avec signature de l'assembly

pmanach — Sat, 01 Apr 2006 11:57:00 GMT

Un besoin très courant, vous en conviendrez (au moins pour me faire plaisir) :)

Le contexte

Pour être plus précis, je travaille en ce moment sur une application à destination de fonctionnels qui doit leur permettre de mettre au point des processus métier avec un outil haut niveau. Et de les tester bien sûr...

Je suis donc parti sur l'intégration du Wrokflow Designer dans une application Windows Form (Visual Studio étant un peu trop hardcore pour cette population). Et pour le versioning, je me suis dit : facile, on utilise l'attribut AssemblyVersion et pour bien faire, on signe le résultat.

Et là, je me suis pris le mur pour faire cela coté code : j'ai seché lamenteblement avant de trouver une solution un peu compliquée mais que je trouve très interressante. Bien entendu, il y a beaucoup plus simple et je vais commencer par la seconde solution.

La bonne solution

Les développeurs de la librairie CodeDom avaient du voir venir la question car ils avaient prévu une option fourre-tout au niveau de l'objet CompilerParameters : il dispose d'une propriété CompilerOptions de type string qui prend en fait tous les paramètres disponibles par la ligne de commande. Ici, on a au choix : /keyfile ou /keycontainer (merci à Aditya Bhandarkar pour l'information). Et voila...

L'autre solution

Oui, mais si on veut positionner d'autres éléments non disponibles par la ligne de commande ?

C'est là tout l'intérêt de ma solution "un peu compliquée" :)

Tout d'abord, je compile le Workflow en mémoire et conserve l'objet généré CompiledUnit :

WorkflowCompiler compiler = new WorkflowCompiler();
WorkflowCompilerParameters parameters = new WorkflowCompilerParameters(assemblyNames);
parameters.LibraryPaths.Add(Path.GetDirectoryName(typeof(ActivityLibrary.SimpleWebServiceActivity).Assembly.Location));
parameters.OutputAssembly = string.Format("{0}.netmodule", this.WorkflowName);
parameters.GenerateCodeCompileUnitOnly = true;
_compilerResults = compiler.Compile(parameters, fileName);

Puis je récupère l'objet voulu en mémoire et je le compile je modifie ses attributs:

CodeCompileUnit ccu = _compilerResults.CompiledUnit;
ccu.AssemblyCustomAttributes.Add(new CodeAttributeDeclaration("System.Reflection.AssemblyKeyFile",

new CodeAttributeArgument (new CodePrimitiveExpression(@"c:\key.snk"))));

Enfin, je compile le résultat :

CodeDomProvider provider = new Microsoft.CSharp.CSharpCodeProvider();

string libPath = typeof(ActivityLibrary.SimpleWebServiceActivity).Assembly.Location;
ICodeCompiler gen = provider.CreateCompiler();
CompilerParameters cp = new CompilerParameters(new string[] { libPath,
                    @"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll",
                    @"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll",
                    @"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll",
                @"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll",
                @"C:\Program Files\Reference Assemblies\Microsoft\WinFX\v3.0\System.Workflow.Activities.dll",
                @"C:\Program Files\Reference Assemblies\Microsoft\WinFX\v3.0\System.Workflow.ComponentModel.dll",
                @"C:\Program Files\Reference Assemblies\Microsoft\WinFX\v3.0\System.Workflow.Runtime.dll"});

cp.GenerateExecutable = false;

cp.OutputAssembly = exeName;

cp.GenerateInMemory = false;

cp.TreatWarningsAsErrors = false;

CompilerResults _compilerResults2 = gen.CompileAssemblyFromDom(cp, ccu);

Et voila une jolie assembly correspondant à mes besoins :)

A noter que l'objet CompilerResults expose une propriété Output qui contient le résultat de l'affichage du compilateur en mode ligne de commande : très pratique pour trouver les erreurs voir les afficher...

Code snippets et C#

pmanach — Wed, 22 Mar 2006 15:51:00 GMT

De base, les snippets fournit avec VS en C# sont un peu pauvre en regard de ce qui est disponible en VB.. Vous pouvez mettre à jour la librairie en téléchargeant la mise à jour suivante : http://go.microsoft.com/fwlink/?linkid=57395&clcid=0x409

Une fois installée sur votre poste, lancez VS et dans le menu Tools, lancez le Code Snippet Manager. Si ce module manque dans le menu, vous pouvez toujours faire Ctr-K, Ctr-B. Puis ajoutez le répertoire racine de l’installation.

Activation de VSS 2005 dans VS 2005

pmanach — Sat, 29 Oct 2005 00:00:00 GMT

Je me suis un peu pris la tête sur une bétise ce soir : faire marcher VSS 2005 dans VS 2005. Ce qui n'aurait pas du causer le moindre souci :(

En fait, j'ai installé comme d'habitude VS puis VSS. J'ai ensuite chargé mes projets dans VS pour les compiler et les intégrer à VSS. Et là, la panne : pas de menu contextuel sur la solution, rien dans le menu fichier, rien dans outils, l'angoisse en somme (surtout un vendredi soir).

Deux solutions : coder sans contrôle de source ou résoudre le problème. La solution 1 étant inacceptable, j'ai donc cherché un peu et me suis rendu compte que par défaut, le pluggin VSS n'était pas activé dans les options de VS (alors que dans les versions précédentes, l'installation de VSS activait le pluggin par défaut).

Il faut donc aller dans Tools, Options, Source Control, Plug-in selection et choisir Microsoft VisualSourceSafe. Et cela va beaucoup mieux après :)

Whidbey beta 2 et Yukon CTP

pmanach — Thu, 05 May 2005 14:28:00 GMT

Un petit rappel pas inutile vu le nombre de problème rencontré : la CTP de Yukon doit être installée avec la beta 2 de Visual Studio. Sinon, prévoyez de l'aspirine :)

Et faîtes l'installation sur une machine propre. Si vous avez déjà installé des versions précédentes, assurez vous de bien avoir tout désinstallé.

Enfin, pour la beta 1 d'Avalon et de WinFX, le scénario d'installation à posteriori est normalement supporté, donc pas de sueurs froides dans un mois :)