Sébastien Bovo [Microsoft France] : Visual Studio

Session OpenXML et VSTO aux TechDays2009 - PPTX et démonstrations

Sebastien Bovo — Mon, 23 Feb 2009 10:39:00 GMT

Bonjour à tous,

Je profite de ce billet pour vous donner le lien vers la présentation et les démonstrations de la session au travers du blog de Julien Chable :

http://blogs.developpeur.org/neodante/archive/2009/02/14/open-xml-diapositives-et-codes-de-la-session-pos-206-sur-open-xml-et-vsto.aspx - Blog à garder sous le coude pour être au courant de ce qui se passe autour d’OpenXML ! Merci Julien.

A bientôt,

Sebastien.

Session OpenXML et VSTO aux TechDays2009

Sebastien Bovo — Wed, 21 Jan 2009 18:50:10 GMT

Bonjour,

Si vous souhaitez découvrir comment vous pouvez créer, manipuler, modifier, assembler, formater tous vos documents Word, Excel, PowerPoint au format OpenXML,

Si vous êtes intéressé par faire ce travail facilement coté serveur en profitant d'un modèle objet haut niveau, performant et supportant la montée en charge,

Et si, cerise sur le gâteau, vous souhaitez comprendre comment vous pouvez rendre vos documents intelligents en y intégrant des fonctionnalités métiers, et transformer Office en Business Application,

Alors...

Cette session est pour vous ! - "Génération de documents Office côté serveur avec OpenXML et VSTO (POS206)"

A bientôt, sur les TechDays ;-)

Sebastien.

Automatisation de la compilation de projets et solutions Visual Studio

Sebastien Bovo — Thu, 26 Jun 2008 09:50:00 GMT

Vous faites parti d’une équipe de développement très réduite

Vous n’avez pas la chance de travailler avec Team Foundation Server

Vous avez peut-être tenté d’automatiser vos builds en utilisant devenv.exe /build en ligne de commandes (devenv.exe "C:\temp\Projet1\Projet1.sln" /build Release "Projet1.csproj")

Vous en avez assez d’ouvrir vos solutions avec Visual Studio seulement pour en effectuer la compilation

Si vous répondez oui à au moins une de ces questions, MSBuild est fait pour vous !

Microsoft Build Engine (MSBuild.exe) est l’environnement, le jeu d’outils Microsoft de génération de builds pour les solutions Visual Studio. Il permet d’avoir le contrôle total sur le build de projets :

Spécifications des sorties et leurs propriétés
Gestion des configurations
Ciblage des différentes versions du .NET Framework à partir de 2.0
Utilisation de fichiers projets au format XML correspondant au formats .sln et .csproj générés par Visual Studio
Définition de tâches (fournies par MSBuild ou pouvant être développées) pour effectuer une action spécifique préliminaire ou postérieure à la compilation
Installation de Visual Studio non nécessaire sur le serveur de build

Au tout début, sans se plonger dans toutes ces possibilités, vous pouvez tout simplement commencer par compiler vos solutions en fonction de la configuration mise en place

Msbuild.exe NomProjet.sln /property:Configuration=Release

Pour plus d’informations :

Point d’entrée sur la référence MSBuild - http://msdn2.microsoft.com/en-us/library/ms171452.aspx
Ciblage de versions spécifiques du .NET Framework avec MSBuild - http://msdn2.microsoft.com/en-us/library/bb383796.aspx
Taches Personalisées - http://msdn2.microsoft.com/en-us/library/t9883dzc.aspx

MSBuild.exe se trouve dans le répertoire d’installation du .NET Framework 3.5 (C:\Windows\Microsoft.NET\Framework\v3.5)

Comment aborder la migration ASP.NET 1.1 vers 2.0

Sebastien Bovo — Thu, 22 May 2008 15:50:00 GMT

Visual Studio 2008 (et 2005) inclus un assistant de migration des projets ASP.NET. Cet assistant peut être utilisé de deux façon :

Migration vers le mode de projet "Web Application Project". Ce type de projet est similaire à celui que l’on connait en Visual Studio 2003 et est conseillé pour la migration ASP.NET 1.1 vers 2.0. Cette migration permet d’utiliser toutes les fonctionnalités ASP.NET 2.0 tout en étant dans un mode projet et donc compilation en une dll unique
Migration vers le nouveau mode de projet "Web Site Project". Cette migration est plus délicate dans la mesure où peuvent survenir des problèmes lors de l’exécution causés par le fait que nous n’avons plus maintenant une dll unique mais plusieurs dlls

Par exemple, le code behind d’une page Web peut vouloir instancier un contrôle utilisateur avec LoadControl() ou bien instancier une autre page Web à partir de son nom de classe (Webform2 par exemple). Ce code ne fonctionnera pas directement parce que les classes ne sont plus dans la même dll
De la même façon, une classe de l’application ne pourra pas instancier une classe d’une page Web parce que la dll contenant les classes ne référence pas la dll contenant les pages Web

D’autres points, ne provoquant pas des erreurs, sont à noter et à tester comme par exemple la présence des fichier .resx devenus inutiles.

Des tests et retours d’expérience ont permis de lister ces points. Je vous encourage à lire le document suivant : Common Web Project Conversion Issues and Solutions - http://msdn2.microsoft.com/en-us/library/aa479312.aspx

Voici les ressources utiles sur ce sujet :

Upgrading VS 2003 Web Projects to be VS 2005 Web Application Projects - http://webproject.scottgu.com/CSharp/Migration/Migration.aspx
Migrating - http://msdn2.microsoft.com/en-us/library/aa530793.aspx
Upgrade from ASP.NET 1.x - http://msdn2.microsoft.com/en-us/asp.net/aa336650.aspx
Migration vers "Web site project"
- Converting from Visual Studio .NET 2002 or 2003 - http://msdn2.microsoft.com/en-us/library/3z019waa(VS.80).aspx
- How to: Convert a Visual Studio .NET Project to Visual Studio 2005 - http://msdn2.microsoft.com/en-us/library/ms247241(VS.80).aspx
Migration vers "Web Application Project"
- Introduction to Web Application Projects - http://msdn2.microsoft.com/en-us/library/aa730880(vs.80).aspx
- Step-By-Step Guide to Converting Web Projects from Visual Studio .NET 2002/2003 to Visual Studio 2005 - http://msdn2.microsoft.com/en-us/library/aa479567.aspx
- Common Web Project Conversion Issues and Solutions - http://msdn2.microsoft.com/en-us/library/aa479312.aspx
- ASP.NET 2.0 Migration Overview - http://msdn2.microsoft.com/en-us/library/ms227549(vs.80).aspx

Concernant la pré-compilation, voici le point de départ : Selecting a Precompilation Model - http://msdn2.microsoft.com/en-us/library/ms227430(vs.80).aspx

Comment mettre en place le débogage distant avec Visual Studio .NET

Sebastien Bovo — Fri, 23 Mar 2007 19:32:00 GMT

Je vous propose, par ces quelques lignes, de clarifier l'insaisissable et célèbre "débogage distant avec Visual Studio .NET".

Conditions préalable

Pour simplifier les explications,

Appelons clientA notre station de travail et serveurB le serveur distant
ClientA fonctionne avec Windows 2000, Windows XP ou Windows 2003
ServeurB fonctionne avec Windows 2000 ou Windows 2003
clientA et ServeurB sont dans le même domaine Windows

D'autre part,

IIS et Visual Studio .NET sont installés sur ClientA
IIS est installé sur ServeurB
Si ServeurB fonctionne avec Windows 2000, le .NET Framework 1.1 doit être téléchargé et installé
Le compte du domaine utilisé fait parti des groupes Administrateurs, VS Développeurs et Utilisateurs du Débogueur sur clientA et sur ServeurB

Composants distants

Afin de pouvoir déboguer un processus sur un serveur distant, ce dernier doit pouvoir recevoir les ordres de débogage et communiquer en retour avec la station de travail. Ce sont les composants distants qui participent à ce travail.

Pour les installer, je lance l'installation de Visual Studio .NET. Sur le tout premier écran, j'utilise le lien Installations des composants distants. S'affiche ensuite une fenêtre dans laquelle il suffit localiser puis de cliquer sur le bouton Tout installer

Configuration du pare-feu

Le point délicat est celui de la configuration du pare-feu si nous avons Windows XP SP2 et Windows 2003 SP1. En effet, pour le débogage, il importe de pouvoir utiliser certains ports comme TCP 135, mais aussi d'autoriser des composants comme Mdm.exe, Vs7Jit.exe ou Msvcmon.exe.

Afin d'effectuer cette configuration, la fiche technique 841177 nous fourni l'outil DebuggerFirewall.hta. Ce dernier est une simple page qui liste les paramétrages nécessaires et les applique en un clic.

L'utilisation de DebuggerFirewall.hta est indispensable sur ClientA et ServeurB si le pare-feu est activé.

Si vous avez la curiosité de découvrir le travail dont nous soulage cet outil ou si vous avez besoin de faire les manipulations manuellement, voici tous les détails >> 833977

Points à vérifier si cela ne fonctionne pas

L'application doit est un répertoire virtuel dans IIS. Ce dernier doit avoir au moins l'authentification Intégrée Windows
La création du projet ASP.NET et son débogage doit se faire en utilisant le nom de serveur et non pas son adresse IP
Le Web.config de l'application doit avoir debug="true"
Dans l'explorateur de solution de Visual Studio, en cliquant droit sur le projet, vérifiez que le débogage ASP.NET est autorisé
Lorsque vous naviguez avec Internet Explorer sur l'application ASP.NET, vous devez être dans la zone Intranet ou Sites de confiance (cette condition n'est pas rempli si vous utilisez le nom complet du serveur comme ServeurB.Domaine1.com). Dans ce cas, ajoutez le nom du serveur à la liste des sites de la zone Intranet