2008-12-15 4 views
3

J'ai développé un prototype C# Excel 2003 dans VS2005 qui supporte un objet avec quelques appels simples, plus une classe RTD séparée, tous assis au sommet d'une grande pile C# interne existante.Création d'un add-in Excel basé sur C# avec un minimum de douleur

Tout fonctionne très bien-est, mais ...

On me dit que pour éviter d'éventuels conflits avec d'autres compléments Excel qui pourraient vouloir un autre moment de l'exécution .Net que je vais doit pousser le code .Net ce hors-proc.

1) Est-ce vrai? 2) Cela peut-il être fait de telle sorte que le serveur non-proc est lancé automatiquement à la demande, est accessible uniquement à l'utilisateur approprié (pour simplifier les problèmes de sécurité) et n'a pas besoin d'une installation compliquée, etc. , etc?

3) Si cela peut être fait, comment?

Actuellement, mon (COM visible) talons de classe commencent:

namespace SimpleAddinMockup1 
{ 
    /// <summary> 
    /// Main entry point from Excel for non-real-time methods. 
    /// </summary> 
    [ClassInterface(ClassInterfaceType.AutoDual), ComVisible(true)] 
    public sealed class Main 
    { 

    ... 
    } 
} 

et

namespace SimpleAddinMockup1 
{ 
    /// <summary> 
    /// In-proc real-time server facade for an Excel instance to our main server connection. 
    /// </summary> 
    /// Note: to throttle updates in Excel use 'Application.RTD.ThrottleInterval = nnn' for nnn ms between updates (default is 2000). 
    /// See: http://msdn.microsoft.com/en-us/library/aa140060(office.10).aspx 
    [ClassInterface(ClassInterfaceType.AutoDual), ComVisible(true)] 
    public sealed class CPRTDServer : Excel.IRtdServer 
    { 

    ... 

    } 
} 

Mise à jour: je serais toujours très désireux de savoir si pousser le C# outproc est facile à faire, par exemple, de manière déclarative ...

Répondre

2

Il est vrai qu'avec les versions CLR actuellement disponibles (1.0, 1.1 et 2.0), différentes versions du CLR ne peuvent pas coexister dans un processus. Cependant, en théorie, tant qu'Excel est configuré pour charger le CLR 2.0, il ne devrait pas y avoir de problèmes avec le code de complément 1.x et le code de complément 2.0 coexistant. Quand un code d'extension 1.x est chargé, il doit automatiquement pointer vers le 2.0 CLR, qui est rétrocompatible. Il fut un temps où Excel était câblé pour ne pas charger le 2.0 CLR afin de résoudre un problème de compatibilité spécifique (expliqué dans la barre latérale dans this article), mais cela a été résolu avec une mise à jour Office (KB908002) qui peut être installé séparément ou avec l'installateur de votre add-in (et devrait avoir été poussé maintenant de toute façon). Avec cette mise à jour appliquée, Excel est supposé charger automatiquement la dernière version CLR disponible. Le plan actuel de Microsoft est que, lorsque le 4.0 CLR est publié (avec VS2010), il sera capable de coexister dans un processus avec le 2.0 CLR, donc j'espère que ce ne sera pas non plus un problème pour l'avenir.

Questions connexes