Host as a service registrar

Hi,

I am evaluating VSTA 2.0 and have a rudimentary problem I am trying to solve. I want the host application to act as a service registrar, wherein add-ins can register their own services. To that end, I defined this interface for my host:

public interface IHost
{
    string Name { get; }

    void RegisterService(Type serviceType, object serviceInstance);

    object GetService(Type serviceType);
}

However, when an add-in invokes the RegisterService method I get this exception:

System.NotSupportedException was unhandled by user code
  Message="Specified method is not supported."
  Source="Microsoft.VisualStudio.Tools.Applications.Adapter.v9.0"
  StackTrace:
    Server stack trace:
       at Microsoft.VisualStudio.Tools.Applications.RemoteMethodInfoAdapter.System.AddIn.Contract.Automation.IRemoteMethodInfoContract.Invoke(IRemoteObjectContract target, BindingFlags bindingFlags, IRemoteArgumentArrayContract arguments, Int32 lcid)
       at Microsoft.VisualStudio.Tools.Applications.ExceptionFilterHelper.Invoke(IExceptionManager mgr, IExceptionNotificationObject exceptionNotificationObject, IRemoteMethodInfoContract miContract, IRemoteObjectContract remoteObjectContract, BindingFlags bindingAttr, IRemoteArgumentArrayContract parameters, Int32 lcid, TypeInfrastructureManager typeInfrastructureManager)
       at Microsoft.VisualStudio.Tools.Applications.RemoteMethodInfo.Invoke(Object target, BindingFlags invokeAttr, Binder binder, Object[] arguments, CultureInfo culture)
       at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
       at Microsoft.VisualStudio.Tools.Applications.DynamicProxyImpl.MafInvoke(MethodInfo methodInfo, Object[]& args, Exception& exception)
    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at Proxy.IHost.RegisterService(Type serviceType, MarshalByRefObject serviceInstance)
       at AddIns.AppAddIn1.AppAddIn_Startup(Object sender, EventArgs e) in C:\Documents and Settings\kboogaar\Desktop\VSTA_Test\AddIns\AddIns.cs:line 57
       at AddIns.AppAddIn1.FinishInitialization() in C:\Documents and Settings\kboogaar\Desktop\VSTA_Test\AddIns\AddIns.cs:line 118
       at Proxy.IHostEntryPoint.Microsoft.VisualStudio.Tools.Applications.Runtime.IEntryPoint.FinishInitialization()
       at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecutePhase(ExecutionPhases executionPhases)
       at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.CompleteInitialization()
       at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecuteEntryPointsHelper()
       at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecuteEntryPoints()
       at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract2.ExecuteEntryPoints()
  InnerException:

The service instance I am trying to register extends MarshalByRefObject. The host has no knowledge of the service's interface, but I'm not sure how to grant it that knowledge at runtime.

Is there something obvious I'm doing wrong?

Thanks,
Kent

>>object serviceInstance);

I think the System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
does not succeed because the proxy does not know how to marshal the serviceInstance object across the AppDomain.

I think you should get this working for a strong-typed service object.

Then build some known service types into the proxy/automation library, so that the host can resolve them at runtime.

At present VSTA does not support dynamically proxied types.

Thanks for the reply Gary.

> At present VSTA does not support dynamically proxied types

I was afraid of that :) Indeed, I was looking through the System.AddIn APIs to see whether it supports dynamically constructing a pipeline between existing components in existing AppDomains (which I imagine VSTA would leverage to achieve dynamically proxied types), and it doesn't look as though it does. That would at least have allowed me to manually connect the host to the service implementation in the add-in.

My fallback is to have all services hosted in the same AppDomain as the host application. That way, the host can add the services to a registry without having any compile-time knowledge of the service (which is absolutely out of the question for our application). Of course, that means we lose some of the benefits of MAF / VSTA, but only for service add-ins. And hopefully this issue will be addressed in the future, allowing us to move those service add-ins into their own AppDomains.

Thanks again,
Kent

Are Domain-Neutral assemblies a possibility?

JackG says that this is available as of .NET 2.0 and I know that there are some System.Addin samples available (unfortunately I am not familiar with them):

Domain-neutral

Declaring assemblies to have domain-neutral behavior may be accomplished via the runtime hosting interfaces (see the framework SDK CorBindToRuntimeEx).  Loading code that is domain neutral will improve performance on subsequent referencing of the same code in additional AppDomains, because the assembly code pages will be shared across the AppDomains.   

So then the question arises as to why not load everything domain-neutral.  The primary reason is that domain-neutral code may not be unloaded.  So does this conflict with the Add-in model guidance of unloadability and isolation?  No, the majority of the scenarios addressed by the Add-in model would not have Add-in's loaded in the GAC, nor desired to be shared across AD's.  Common functionality offered by the hosting application to the Add-in's, is a likely candidate for domain-neutrality as opposed to Add-in assembly neutrality.  You may wish to reread that last sentence ;-).  These classifications of Host provided assemblies are available to consumers (Add-in's) for the duration of the Host process.  So there should be no conflict in the Add-in model isolation and unloadability recommendation and domain-neutrality.

In v1.0 and v1.1 native images that Ngen.exe produces cannot be shared (domain-neutrality) across AD's.  In v2.0, native images that Ngen.exe produces can be shared (domain-neutrality) across AD's.