Discussion :

[tribaleur]

Bonjour.

J'ai une application dans la quelle je doit aller modifier un fichier Excel. Pour le moment, afin de tester, j'ai juste un fonction qui ouvre mon fichier, modifie la case A1 et ferme le fichier sans sauvegarder.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Imports Microsoft.Office.Interop.Excel
Imports Microsoft.Office.Interop
 
    Public Shared Sub PrintXls()
        'Déclaration des variables
        Dim Xls As Microsoft.Office.Interop.Excel.Worksheet
        Dim xlsapp As New Microsoft.Office.Interop.Excel.Application
        Dim Xlsbook As Microsoft.Office.Interop.Excel.Workbook
 
        'lancement d'excel et ouverture du fichier
        Xlsbook = xlsapp.Workbooks.Open("c:\GDC.xls")
 
        xlsapp.Visible = True
        Xls = Xlsbook.Worksheets(1) 'avant je mettais Xls = Xlsbook.Worksheets("Test")  ... ça ne fonctionne pas ^^
        Xls.Range("A1").Value = "Test"
 
        Xlsbook.Close(False)
        Xlsbook = Nothing
        xlsapp = Nothing
    End Sub

Ça fonctionne tout comme il faut ... sauf quand je déploie l'application sur un poste de test

Au début ça allait ... une foie déployé l'application fonctionnait bien ... même quand elle allait modifier le fichier Excel. J'avais une erreur mais seulement lié à un mauvais index de WorkSheet (je mettais le nom et pas le numéro). L'application se démarrait bien ... et plantait seulement quand je cliquai sur le bouton pour exécuter la fonction.

J'ai donc modifié la fonction pour quelle soit juste. Depuis j'ai au lancement de l'application un message comme quoi je doit d'abord installer l'assembly pour Office 12.

Sur le poste test j'ai Office 11 ... et sur mon poste de développement j'ai les offices 11 et 12 ... cependant je n'ai mis que la référence .net pour le Excel 11.

Alors oui sur mon poste, l'Excel par défaut est le 12 ... mais dans mon application je n'en parle jamais. Ça fonctionnait très bien 5 minute avant ... je corrige une petite faute et ça fonctionne plus.

J'ai remis comme avant le code mais rien à faire ... quand je publie l'appli ça me demande toujours l'assembly Office 12.

J'avoue ne pas comprendre d'où viens le problème ... vous avez des idées? ... je suis très novice dans les ajouts de référence pour publication et dans la publication ... je fait peut-être quelque chose de mal.

En tout cas merci d'avance.

P.S. : d'ailleurs, est-ce normal, qu'à la fin de ma publication, ça essaie d'ouvrir une page Internet vers mon projet? ... ça me gène pas mais je trouve ça louche

[bizet]

Salut,

Pour éviter ces problèmes de DLLs, voici comment je procède en général :
Ajout dans mon projet d'un répertoire DLLs dans lequel je copie mon fichier DLL.
Dans mon projet, je fais référence a ce fichier.

Ensuite j'utilise ILMerge pour merger mon exe et la dll comme ça, je suis sur qu'il n'y a pas de probleme de référence de Dlls manquantes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ILMerge /target:exe /out:"D:\monExeFinal.exe" "D:\monExe.exe"
"D:\Microsoft.Office.Interop.Excel.dll" 
"D:\Office.dll"

[tribaleur]

Je regarderai ça cette après midi.

Je te remercie pour l'information.

[tribaleur]

Bon alors déjà ... ça coince au niveau de la Dlll.

Je n'arrive pas à trouver où la récupérer.

Est-ce que par hasard tu aurai une réponse à cette énigme pour moi?

J'ai bien trouvé l'assembly (dans c:\Windows\assembly) ... mais je n'ai pas trouvé la Dll en elle même ... je n'ai donc pas le fichier Dll pour pouvoir l'ajouter au projet.

Je me dit que j'ai fait surement un mauvais réglage dans la publication.

[tribaleur]

Bon alors finalement j'ai trouvé la Dll.

Je sais pas si ça suffira, mais purement par hasard je suis tombé dessus.

Alors pour info on peut la trouver dans le répertoire "C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11\Microsoft.Office.Interop.Excel.dll"

Je vais essayer ILMerge et je te tiens au courrant.

Merci à toi.

[tribaleur]

Bon alors après plusieurs tests je me retrouve avec le message d'erreur suivant

ILMerge.Merge: Could not load assembly from the location '\\annecy\temp1\356\GDC
\setup.exe'. Skipping and processing rest of arguments.
à ILMerging.ILMerge.Merge()
à ILMerging.ILMerge.Main(String[] args)

J'ai vérifié mes chemins d'accès. J'ai essayer avec une autre syntaxe (sous la forme => ILMerge.exe "App.exe" "Lib1.dll" /out:"MergeApp.exe")

J'ai essayé en passant par l'interface graphique Gilma.

J'ai toujours le même message d'erreur sur mon fichier "setup.exe".

Mon fichier "setup.exe" ne ce trouve pas dans le même répertoire que la dll.

Le fichier "Setup.exe" est celui généré par Visual Studio 2008 quand je fait "Générer\Publier le projet" ... je pense que le soucis viens d'ici ... mais je vois pas ce que c'est...

Une piste de réflexion?

D'avance merci.

[bizet]

salut

Perso pour les applications WinForm, je n'ai jamais trouvé la publication très pratique.
En général je compile le projet en Realease. J'ai alors dans MonProjet/bin/realease/ mon exécutable et les dlls.

C'est ces fichiers que je passe en argument de ILMerge.

[MABROUKI]

bonjour tribaleur
Il est vivement recommende par microsoft de ne pas avoir 2 versions d'office installe sur la machine de dev.

citation MSDN 1 pour Net FrameWork 4(VS 2010):

If your customer base uses both Microsoft Office 2010 and the 2007 Microsoft Office system, you can use Visual Studio 2010 to develop solutions that work in both versions of Office. If you need to create a solution that can also run in Microsoft Office 2003, you must use an earlier version of Visual Studio.

Conclusion :pour office 2003 il faut VS2008.

citation MSDN 2 pour Net FrameWork 3.5(VS 2008):

Create a solution by using a project template for Microsoft Office 2003.
Applications in the 2007 Microsoft Office system can run solutions created by using projects for Microsoft Office 2003, if the Visual Studio 2005 Tools for Office Second Edition runtime is installed on the computer

Conclusion :une solution pour office 2003 fonctionne egalement sous ms office 2007....

citation MSDN 3 pour Net FrameWork 3.5(VS 2008):

Visual Studio Tools for Office does not support installing both the 2003 and the 2007 versions of Office applications side-by-side on the development computer. To develop separate projects for different versions of Microsoft Office, use a different development computer for each version of Microsoft Office.

Finalite : pas de tambouille VSTO sur machine dev..Une seule version d'office doit etre installe.................sinon c'est les deboires et le bricolage sans fin.......................

Bon code..................

[tribaleur]

Bonjour.

@MABROUKI : Merci à toi pour ces informations. Je pense qu'il est trop tard maintenant pour les versions d'offices ... mais je garde cette information sous le coude.

@bizet : Bon alors j'ai testé de merger en utilisant le .exe du dossier release ... et ça fonctionne super pour le moment. Un grand merci à toi.

Donc pour résumer la marche à suivre ... si ça peut aider quelqu'un :
-Dans le menu "Projet\Ajouter une référence...". Dans l'onglet ".net" je choisi "Microsoft.Office.Interop.Excel" (Version 11 pour Office2003, V12 pour 2007 ...)
-Dans Visual Studio je fait "Générer\Regénérer MonProjet"
-Cela créer un fichier .exe dans le répertoire : "RépertoireDeMonProjet\MonProjet\bin\Release\Monprojet.exe"
-Je copie ce fichier dans un répertoire (Ex : C:\Tmp)
-Je copie la Dll d'Office dans le même répertoire que ci-dessus (La DLL ce trouve dans "C:\Program Files\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11\Microsoft.Office.Interop.Excel.dll")
-J'utilise ILMerge pour merger les deux.
-Je diffuse le fichier .Exe généré, par ILMerge, sur les postes clients.

Petites info sur ILMerge :
-Il existe une petite interface graphique pour l'utiliser qui est très pratique ... vous pouvez la trouver là : Gilma
-Quand on passe par la ligne de commande pour merger, après à l'exécution de fichier exe généré, une fenêtre de ligne de commande s'ouvre derrière. Pas trop gênant ... mais pas top je trouve. En passant par l'interface Gilma cette fenêtre n'apparait pas.
-Quand on passe par Gilma, quand on clique sur le bouton "Merger" ça ouvre une fenêtre d'invite de commande toute noir ... chez moi je doit regarder dans mon dossier de génération pour voir si le fichier .exe est généré. Une fois ce dernier créé avec un taille correcte ... je peux fermer la fenêtre d'invite de commande. Sinon elle reste ouverte indéfiniment. Quand on la ferme ça affiche un rapport de génération. Y'a plus qu'à tester le .Exe mergé.
-Attention par contre à ne surtout pas renommer la .Dll ... chez moi si elle ne s'appelle pas Microsoft.Office.Interop.Excel.Dll ... ILMerge plante.

Voila je crois que j'ai tout dit.

Encore merci à tous les deux pour vos contributions.