Exceldotnet : programmer excel en dotnet sans vba ni vsto
Description
Comment programmer Excel en DotNet sans utiliser VBA ni VSTO (Visual Studio Tools for Office) ? L'astuce consiste simplement à piloter Excel via automation (jusque là rien de spécial), et de placer des gestionnaires d'événement (toujours en DotNet) sur des items ajoutés sur l'objet CommandBar de l'instance d'Excel pilotée, c'est tout ! Cette source est la conversion en VB de l'exemple en C# trouvé ici :
http://www.codeproject.com/KB/office/extending_excel.aspx
via le convertisseur :
http://www.developerfusion.com/tools/convert/csharp-to-vb
La source en C# précise que la démo fonctionne avec Excel 2003 et Excel 2007 en utilisant la même référence à "Microsoft Excel 11.0 Object Library". Du coup, j'ai eu l'idée de remplacer cette référence par "Microsoft Excel 10.0 Object Library" pour tester avec Excel 2002 : pour cela, il m'a fallut déterrer de vielles pages internet poussiéreuses (avec des liens cassés sur la doc MSDN) et j'ai retrouvé les PIAs d'Office XP (mais si souvenez-vous !) :
Working with the Office XP Primary Interop Assemblies
http://msdn.microsoft.com/en-us/library/aa163987(office.10).aspx
Et on peut encore les télécharger ici : "Office XP PIAs"
http://www.microsoft.com/downloads/details.aspx?familyid=c41bd61e-3060-4f71-a6b4-01feba508e52&displaylang=en
Il m'a suffit de remplacer les références par leur version 10 en ajoutant les dll Microsoft.Office.Interop.Excel.dll et office.dll du dossier "Office XP PIAs", et le code source n'a relevé aucune erreur !
Mais le plus intéressant dans ce test est le principe de la compatibilité ascendante : l'exécutable DotNet ainsi généré fonctionne toujours avec les versions 2003 et 2007 d'Excel !!! Enthousiasmé par ce fantastique résultat, j'ai ressorti un vieux zip de Windows XP avec Office 2000 installé (un zip pour la maintenance des applications Office 2000 encore en service, fait avec mon logiciel VBWinBackup). Il n'existe pas de PIA pour Office 2000 (vous pouvez toujours essayer de reconstruire le Wrapper, mais ce n'est pas évident que vous puissiez distribuer une application en faisant cela), cependant le modèle de conception d'Excel 2002 et de la barre d'outil d'Office 2002 diffère peu du modèle de la version 2000 d'Office, du coup... cela marche !!! vous pouvez voir un bon vieux Excel 2000 piloté en DotNet sur la capture d'écran (enfin presque, car le "New Button 1" lui ne fonctionne pas :-).
Moralité : Les techniques préconisées par Microsoft pour programmer des applications Excel en DotNet ciblent une version spécifique d'Excel. Cela peut convenir pour du développement en interne, car les grands comptes qui ont des licences en volume peuvent imposer la même version d'Office sur leur Intranet, mais ces techniques sont trop limitées pour distribuer de telles applications dans le cas général. En fait les adaptateurs fournis dans les PIAs sont compatibles de façon ascendante, il suffit donc de n'utiliser que des fonctionnalités présentes depuis la première version ciblée (je n'ai jamais vérifié si on pouvait vraiment le faire via VSTO, il m'a toujours semblé que non). En programmant en liaison tardive au lieu de la liaison anticipée, on s'affranchit des problèmes de compilation pour fonctionner avec plusieurs versions, mais le code est moins pratique et moins "propre" en regard des bonnes pratiques de programmation (on peut toutefois isoler ces portions de code dans des modules moins stricts). Ici, comme l'interfaçage est assez simple, on peut se contenter de l'adaptateur pour la version 2002/XP d'Excel, mais cela semble plus délicat et plus risqué pour la version 2000, je ne le conseille pas (déjà que la liaison tardive pour piloter Office ferait grimacer n'importe quel MVP Microsoft...).
http://www.codeproject.com/KB/office/extending_excel.aspx
via le convertisseur :
http://www.developerfusion.com/tools/convert/csharp-to-vb
La source en C# précise que la démo fonctionne avec Excel 2003 et Excel 2007 en utilisant la même référence à "Microsoft Excel 11.0 Object Library". Du coup, j'ai eu l'idée de remplacer cette référence par "Microsoft Excel 10.0 Object Library" pour tester avec Excel 2002 : pour cela, il m'a fallut déterrer de vielles pages internet poussiéreuses (avec des liens cassés sur la doc MSDN) et j'ai retrouvé les PIAs d'Office XP (mais si souvenez-vous !) :
Working with the Office XP Primary Interop Assemblies
http://msdn.microsoft.com/en-us/library/aa163987(office.10).aspx
Et on peut encore les télécharger ici : "Office XP PIAs"
http://www.microsoft.com/downloads/details.aspx?familyid=c41bd61e-3060-4f71-a6b4-01feba508e52&displaylang=en
Il m'a suffit de remplacer les références par leur version 10 en ajoutant les dll Microsoft.Office.Interop.Excel.dll et office.dll du dossier "Office XP PIAs", et le code source n'a relevé aucune erreur !
Mais le plus intéressant dans ce test est le principe de la compatibilité ascendante : l'exécutable DotNet ainsi généré fonctionne toujours avec les versions 2003 et 2007 d'Excel !!! Enthousiasmé par ce fantastique résultat, j'ai ressorti un vieux zip de Windows XP avec Office 2000 installé (un zip pour la maintenance des applications Office 2000 encore en service, fait avec mon logiciel VBWinBackup). Il n'existe pas de PIA pour Office 2000 (vous pouvez toujours essayer de reconstruire le Wrapper, mais ce n'est pas évident que vous puissiez distribuer une application en faisant cela), cependant le modèle de conception d'Excel 2002 et de la barre d'outil d'Office 2002 diffère peu du modèle de la version 2000 d'Office, du coup... cela marche !!! vous pouvez voir un bon vieux Excel 2000 piloté en DotNet sur la capture d'écran (enfin presque, car le "New Button 1" lui ne fonctionne pas :-).
Source / Exemple :
Cf. Zip
Conclusion :
Moralité : Les techniques préconisées par Microsoft pour programmer des applications Excel en DotNet ciblent une version spécifique d'Excel. Cela peut convenir pour du développement en interne, car les grands comptes qui ont des licences en volume peuvent imposer la même version d'Office sur leur Intranet, mais ces techniques sont trop limitées pour distribuer de telles applications dans le cas général. En fait les adaptateurs fournis dans les PIAs sont compatibles de façon ascendante, il suffit donc de n'utiliser que des fonctionnalités présentes depuis la première version ciblée (je n'ai jamais vérifié si on pouvait vraiment le faire via VSTO, il m'a toujours semblé que non). En programmant en liaison tardive au lieu de la liaison anticipée, on s'affranchit des problèmes de compilation pour fonctionner avec plusieurs versions, mais le code est moins pratique et moins "propre" en regard des bonnes pratiques de programmation (on peut toutefois isoler ces portions de code dans des modules moins stricts). Ici, comme l'interfaçage est assez simple, on peut se contenter de l'adaptateur pour la version 2002/XP d'Excel, mais cela semble plus délicat et plus risqué pour la version 2000, je ne le conseille pas (déjà que la liaison tardive pour piloter Office ferait grimacer n'importe quel MVP Microsoft...).
Codes Sources
- AssemblyInfo.vb
- Excel.ico
- ExcelDotNet.html
- ExcelDotNet.sln
- ExcelDotNet.vbproj
- ExcelDotNet._exe_
- ExcelDotNetXP.sln
- ExcelDotNetXP.vbproj
- ExcelDotNetXP._exe_
- frmExcelDotNet.Designer.vb
- frmExcelDotNet.resx
- frmExcelDotNet.vb
- Microsoft.Office.Interop.Excel.dll
- Microsoft.Vbe.Interop.dll
- modGenESK.vb
- office.dll
- Program.vb
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.