Creating MMC snap-in?
-
Hi all! I'm supposed to create an MMC snap-in in C# for XP/Win2000. As far as I've seen, there is no support for this in C#. And most of the time people recommend the framewok of IronRingSoftware as a great starting point. Now I wonder, if I'm adding a reference to Microsoft Management Console 2.0 in the Visual Studio IDE (Add Reference -> COM tab -> Microsoft Management Console 2.0), what am I referencing? By doing this I can write MMC20. in the code window, and a list of interfaces and methods appear. Is this reference useful for creating snap-ins? If this is a way of building snap-ins, what is the difference between the MMC reference and the framework from IronRingSoftware? Thanx in advance :)
-
Hi all! I'm supposed to create an MMC snap-in in C# for XP/Win2000. As far as I've seen, there is no support for this in C#. And most of the time people recommend the framewok of IronRingSoftware as a great starting point. Now I wonder, if I'm adding a reference to Microsoft Management Console 2.0 in the Visual Studio IDE (Add Reference -> COM tab -> Microsoft Management Console 2.0), what am I referencing? By doing this I can write MMC20. in the code window, and a list of interfaces and methods appear. Is this reference useful for creating snap-ins? If this is a way of building snap-ins, what is the difference between the MMC reference and the framework from IronRingSoftware? Thanx in advance :)
esjq wrote: Is this reference useful for creating snap-ins? It's necessary. MMC is a COM client, and snap-ins are COM servers. .NET can communicate with COM using Runtime Callable Wrappers (RCWs) to consume COM components, and with COM-Callable Wrappers (CCWs) to expose managed component to COM. You're actually doing both. You must implement those interfaces defined in that interop assembly you created, and register your assembly with regasm.exe. There are rules to exposing your managed components to COM. NEver use auto-generated interfaces, and in this case you wouldn't have to because it's the interfaces defined in that interop assembly that you're implementing. This means, on your classes, you set
ClassInterfaceAttribute
toClassInterfaceType.None
. Always attribute your classes and interfaces - if you define any - with a uniqueGuidAttribute
that you do not change. Never change published interfaces. These are all rules for writing COM components and must be followed when exposing managed components to COM, otherwise your COM clients (like MMC) will never find your components (because the CLSID, or class ID - a GUID for your classes keeps changing) or because the interfaces IDs (IIDs) keep changing. Read Design Considerations for Interoperability[^] in the .NET Framework SDK, as well as Exposing .NET Components to COM[^] for more information about this topic. Code Project has some good articles about developing MMC snap-ins, including how to do it in managed code. Creating MMC Snapin using C# (Part I)[^] is one such example. You can search for others. You should also read the MMC Programmer's Guide[ -
esjq wrote: Is this reference useful for creating snap-ins? It's necessary. MMC is a COM client, and snap-ins are COM servers. .NET can communicate with COM using Runtime Callable Wrappers (RCWs) to consume COM components, and with COM-Callable Wrappers (CCWs) to expose managed component to COM. You're actually doing both. You must implement those interfaces defined in that interop assembly you created, and register your assembly with regasm.exe. There are rules to exposing your managed components to COM. NEver use auto-generated interfaces, and in this case you wouldn't have to because it's the interfaces defined in that interop assembly that you're implementing. This means, on your classes, you set
ClassInterfaceAttribute
toClassInterfaceType.None
. Always attribute your classes and interfaces - if you define any - with a uniqueGuidAttribute
that you do not change. Never change published interfaces. These are all rules for writing COM components and must be followed when exposing managed components to COM, otherwise your COM clients (like MMC) will never find your components (because the CLSID, or class ID - a GUID for your classes keeps changing) or because the interfaces IDs (IIDs) keep changing. Read Design Considerations for Interoperability[^] in the .NET Framework SDK, as well as Exposing .NET Components to COM[^] for more information about this topic. Code Project has some good articles about developing MMC snap-ins, including how to do it in managed code. Creating MMC Snapin using C# (Part I)[^] is one such example. You can search for others. You should also read the MMC Programmer's Guide[