Impossible de charger xll par programme

J'essaie d'automatiser certains tests pour un complément Excel, qui est sous forme xll. J'ai un problème en chargeant le xll. Je suis en train d'écrire en C# et mon code ressemble à ceci:Impossible de charger xll par programme

using Microsoft.Office.Interop.Excel; 

Application xlApp; 
Workbook xlWorkBook; 
Worksheet xlWorkSheet; 

// create application, open workbook, etc ... 
// now try to register xll 
xlApp.RegisterXLL("C:\\SomePath\\Whatever.xll");

Cependant, ce retour toujours faux. J'essaie de voir ce que fait secrètement Excel quand je charge le xll manuellement en enregistrant la macro. La macro ressemble à:

Sub Macro1() 
ChDir "C:\SomePath" 
Application.RegisterXLL Filename:= _ 
"C:\SomePath\Whatever.xll" 
End Sub

La seule différence semble être le ChDir, donc je changé mon code pour:

FileSystem.ChDir("C:\\SomePath"); 
xlApp.RegisterXLL("C:\\SomePath\\Whatever.xll");

Mais encore ne fonctionne pas. Une autre chose étrange est quand je mets un point d'arrêt avant la ligne RegisterXLL et charge le xll manuellement d'abord, la méthode RegisterXLL retournera vrai. Mais sinon, il retournera faux.

Source

2010-07-07 Chris

Merci pour toutes les suggestions. J'ai résolu le problème en modifiant le chemin de fichier par défaut pour l'application Excel. Je rencontrais des problèmes avec le chargement de la fonction définie par l'utilisateur [UDF] dans le code VBA

Source

2010-07-19 13:18:34 Chris

Comment désinscrire Excel AddIn ... – Ocean

Oui, la commande ChDir peut être importante. Il aide Windows à trouver toutes les DLL dont dépend quel.xll. La raison pour laquelle cela ne résout pas votre problème est que FileSystem.ChDir() modifie le répertoire de travail pour votre programme de test, pas pour Excel.

Pas tout à fait possible. Déployer le xll faire un répertoire qui est sur le système PATH le résoudra. Une solution pragmatique consiste simplement à exécuter cette macro.

Source

2010-07-07 16:32:03

Je sais que ce n'est pas une réponse directe à votre question, mais vous voudrez peut-être envisager d'utiliser VSTO dans Visual Studio. VSTO automatise beaucoup de ces types de problèmes. La version de VS 2010 est tellement meilleure que ce qu'elle avait l'habitude d'avoir et vous pouvez construire des compléments au niveau de l'application plutôt que des compléments au niveau du document. Si vous avez besoin des fonctions définies par l'utilisateur, vous pouvez utiliser un complément COM comme décrit ici:

http://blogs.officezealot.com/whitechapel/archive/2005/04/10/4514.aspx

Il a été basé sur cet article:

http://blogs.msdn.com/eric_carter/archive/2004/12/01/273127.aspx

Nous utilisons une combinaison de VSTO pour notre application principale, et le complément COM pour les fonctions définies par l'utilisateur. Ce qui est bien, c'est qu'ils sont chargés dans le même domaine d'application afin qu'ils puissent se parler.

Source

2010-07-07 18:55:10 Erick

Hey Erick, je me demandais si vous pouviez expliquer comment vous ajustez votre complément d'automation managé dans le même AppDomain que VSTO? Cela semble très cool. –

Mike, en fait je ne sais pas pourquoi c'est le cas. Nous avions l'habitude d'utiliser l'accès à distance qui a causé des problèmes pour essayer d'utiliser l'application avec les services de terminaux. Nous vérifions si l'addin COM est enregistré, et si ce n'est pas le cas, inscrivez-le avec Regasm.exe. Si vous vérifiez les domaines d'application de chacun (AppDomain.CurrentDomain.FriendlyName), vous devriez le voir (le nôtre est "PrevisionAddIn.vsto"). Nous utilisons une classe globale avec une propriété qui fait référence à l'instance Excel et une interface UDF au code principal. La classe COM UDF est en réalité un shell qui transmet les appels au code principal. Notez, cela utilise VS 2010 et Excel 2007. – Erick

Merci Erick, c'est intéressant. J'ai fait ce genre de chose avec des solutions non-radicales. Je ne savais pas qu'ils iraient tous les deux au même AppDomain si vous faisiez cela. Très cool de le savoir, merci! –

A été en mesure de charger le fichier xll mais n'a pas pu appeler.

Le code suivant charge correctement les fichiers XLL et appelle la fonction définie par l'utilisateur à partir du code VBA. Il peut y avoir des instructions redondantes dans ce module mais cela fonctionne!

Sub InstallAddIn() 

On Error GoTo ErrorHandle 

Application.DefaultFilePath = "D:\\MyFolder" 

Application.RegisterXLL ("MyXLLFileName.xll") 

Set AI = AddIns.Add(Filename:="D:\MyFolder\MyXLLFileName.xll") 

    If AddIns("MyXLLFileName").Installed Then 
     LogInformation ("My XLL is installed") 
    Else 
     LogInformation ("My XLL is NOT installed") 
    End If 
Exit Sub 

ErrorHandle: 

LogInformation ("------------------------") 'Logging function that I have written. Not a std api 

LogInformation (Err.HelpFile) 

LogInformation (Err.HelpContext) 

LogInformation (Err.Description) 

LogInformation ("Error in InstallAddIn module") 

LogInformation ("------------------------") 

End 

End Sub

Source

2013-08-26 13:29:05 nishu

Une bonne solution serait:

1- enregistrer le répertoire courant avec

string CurrentDir = Directory.GetCurrentDirectory()

2- vous utilisez

Directory.SetCurrentDirectory(dirXll);

où dirXll est l'emplacement de votre xll (cf GetExecutingAssembly()).

3- Chargez votre Xll (RegisterXLL)

4 et CurrentDir finaly utilisation pour définir le répertoire courant à son emplacement d'origine. N'oubliez pas d'ajouter toutes les DLL que vous avez dans le même dossier que votre xll.

Source

2015-11-14 02:29:32 Malick

Répondre

Questions connexes