2010-01-19 3 views
7

Lors de la définition d'une classe COM visible en C++ je peux définir le modèle de thread pris en charge dans le fichier d'en-tête (la ligne threading(single)):Comment marquer des objets .NET exposés à COM-interop comme thread unique?

[ 
    coclass, 
    default(IComInterface), 
    threading(single), 
    vi_progid("Example.ComClass"), 
    progid("Example.ComClass.1"), 
    version(1.0), 
    uuid("72861DF5-4C77-43ec-A4DC-ED04396F0CCD") 
] 

est-il un moyen comparable de fixer le modèle de thread dans .NET (pour exemple un attribut)? Je définis actuellement mon COM-classe en tant que tel:

[Guid("67155A91-2948-43f5-B07F-5C55CDD240E5")] 
[ComVisible(true)] 
[InterfaceType(ComInterfaceType.InterfaceIsDual)] 
public interface IComInterface 
{ 
    ... 
} 


[Guid("DC5E6955-BB29-44c8-9FC0-6AADEEB2AFFB")] 
[ClassInterface(ClassInterfaceType.None)] 
[ProgId("Example.ComClass")] 
public class ComClass : IComInterface 
{ 
    ... 
} 

--edit:

Les commentaires sur la réponse marquée sont la chose vraiment importante. Il semble que la seule façon de dire à RegAsm de définir un ThreadingModel différent est d'écrire une méthode d'enregistrement personnalisée marquée avec l'attribut [ComRegisterFunction].

Répondre

6

C'est vraiment obscur, je n'ai jamais vu l'attribut "threading" dans MIDL. Pas plus que le MSDN Library authors.

Une coclasse COM publie ses exigences de thread dans le Registre à l'aide de la clé HKCR\CLSID\{guid}\InProcServer32. La valeur ThreadingModel déclare l'appartement dont il a besoin. Si elle est manquante ou est définie sur "Appartement", elle annonce qu'elle n'est pas sécurisée pour les threads et nécessite l'aide d'un thread STA. CoCreateInstance() utilise cette valeur lorsqu'il crée l'objet. Si nécessaire, il démarrera un thread STA et créera un proxy si le thread actuel n'est pas STA, s'assurant qu'il est toujours utilisé de manière thread-safe. Une classe [ComVisible] .NET sera enregistrée comme "Both", ce qui indique qu'il est acceptable d'être utilisé sur un thread dans le MTA. Assez optimiste, mais suit la philosophie .NET que tout est thread-dangereux, mais peut être sécurisé en mettant le mot-clé lock dans les bons endroits. Une promesse qui n'est pas souvent testée, risquée. Substituer la valeur ThreadingModel (ou l'omettre) nécessite d'écrire du code pour enregistrer le coclass vous-même, décoré avec l'attribut [ComRegisterFunction]. RegistrationServices.RegisterTypeForComClients() peut être utile pour mettre en place les clés de base.

+2

Je pense que l'OP ne parle pas des attributs MIDL. http://msdn.microsoft.com/de-de/library/zfbxt3zs.aspx – Henrik

+0

Vous avez raison. Cela ne change pas ma réponse. –

+0

Je viens de vérifier le registre et la valeur actuelle de ThreadingModel est "Both", ce qui n'est pas celui que je recherche. N'existe-t-il pas une autre façon de définir le ThreadingModel en plus d'enregistrer manuellement les classes COM en utilisant une méthode marquée avec [ComRegisterFunction]? – Xperimental

Questions connexes