ILocalRegistry4 Interface
Establishes a local registry relative to the Visual Studio registry hive. You can get an instance of the interface through the SLocalRegistry (SID_SLocalRegistry) service.
Namespace: Microsoft.VisualStudio.Shell.Interop
Assembly: Microsoft.VisualStudio.Shell.Interop.9.0 (in Microsoft.VisualStudio.Shell.Interop.9.0.dll)
Syntax
'Declaration
<GuidAttribute("5C45B909-E820-4ACC-B894-0A013C6DA212")> _
<InterfaceTypeAttribute()> _
Public Interface ILocalRegistry4
[GuidAttribute("5C45B909-E820-4ACC-B894-0A013C6DA212")]
[InterfaceTypeAttribute()]
public interface ILocalRegistry4
[GuidAttribute(L"5C45B909-E820-4ACC-B894-0A013C6DA212")]
[InterfaceTypeAttribute()]
public interface class ILocalRegistry4
[<GuidAttribute("5C45B909-E820-4ACC-B894-0A013C6DA212")>]
[<InterfaceTypeAttribute()>]
type ILocalRegistry4 = interface end
public interface ILocalRegistry4
The ILocalRegistry4 type exposes the following members.
Methods
| Name | Description | |
|---|---|---|
.gif "Public method") |
GetLocalRegistryRootEx | Returns the local registry root. |
|
RegisterClassObject | Loads a class factory and registers it with COM. |
|
RegisterInterface | Registers an interface for marshaling by using a locally registered proxy. |
|
RevokeClassObject | Revokes a registered class object. |
Top
Remarks
There are two main uses for IVsLocalRegistry4, as follows:
Advertising local COM objects or proxy-stubs for in-process, cross-thread calls that do not otherwise have to know about the local registry.
Obtaining local registry paths (HKEY and root) that may be redirected in the certain non-administrator scenarios.
For class objects that are typically created by using CoCreateInstance, register the class factory in the AppID local registry in the same way that you do for CreateInstance. This is not quite the same as global registration beneath HKEY_CLASSES_ROOT, where InprocServer32 is a sub-key and not a value.
HKEY_LOCAL_MACHINE\<RegRoot>\CLSID\{your-CLSID}
InprocServer32 REG_SZ yourclassfactory.dll
Calling the RegisterClassObject method loads this class factory and registers it with COM so that it can subsequently be accessed from the same thread by using CoCreateInstance.
For proxy-stubs, this mechanism lets you register your PS factories in the AppID local registry as follows.
HKEY_LOCAL_MACHINE\<RegRoot>\CLSID\{your-ProxyStubCLSID}
InprocServer32 REG_SZ yourproxy.dll
HKEY_LOCAL_MACHINE\<RegRoot>\Interface\{private-IID}
AutoRegister REG_DWORD {0 or 1}
HKEY_LOCAL_MACHINE\<RegRoot>\Interface\{private-IID}\ProxyStubClsid32
(Default) REG_SZ {your-ProxyStubCLSID}
With the registry entries in place, a call to RegisterInterface loads the proxy DLL and registers it as the marshaler for that interface on the calling thread only. Therefore, for cross-thread, in-process marshaling, you must call RegisterInterface on each thread that has to marshal the interface. There is no way to unregister. For the sake of efficiency, avoid calling RegisterInterface more than once on the same interface on the same thread. One way to ensure this is to call RegisterInterface immediately after CoInitialize or OleInitialize.
The AutoRegister value is optional and should be used sparingly. Most interfaces have a clear implementation owner and the implementation code can typically be responsible for calling RegisterInterface before any client code has access to the proxy. However, some interfaces do not have a clear owner and may have to be registered by the platform at startup. If the AutoRegister value is present and non-zero, then the platform will register the associated proxy on the main thread automatically before any packages or local class factories are created. Use this mechanism with care because it may impact startup performance.