Fail to access the property of the Application class when the property type is defined in a dependent component of the Application class

Using Visual Studio 2005 SDK 3.0 (August 2006 CTP), the latest VS SDK with VSTA.

I am stuck at a situation that the proxy threw an exception (listed below)  when the Add-in tried to access the property of the Application class if the data type (a class) of that property is defined in a dependent component of the Application class.

The dependent component that contains the class definition of the Application property is a strong named and sitting in the GAC.

I found that it worked fine if the class definition is moved from the dependent component to the same project as the Application. But in our product we have to keep quite a few of the Application class member types in other components.

Any help is greatly appreciated.

[6904] Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp.AIMExtension.LoadAddIns:
[6904] Microsoft.VisualStudio.Tools.Applications.Contract.AddInException: System.Collections.Generic.KeyNotFoundException, mscorlib
[6904] 
[6904] System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
[6904] 
[6904] Server stack trace: 
[6904]    at System.ThrowHelper.ThrowKeyNotFoundException()
[6904]    at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
[6904]    at Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager.GetCanonicalName(TypeDescription localType)
[6904]    at Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager.GetCanonicalName(Type localType)
[6904]    at Microsoft.VisualStudio.Tools.Applications.RemoteTypeAdapter.System.AddIn.Contract.Automation.IRemoteTypeContract.GetCanonicalName()
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
[6904] 
[6904] Exception rethrown at [0]: 
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
[6904]    at System.AddIn.Contract.Automation.IRemoteTypeContract.GetCanonicalName()
[6904]    at Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager.LocalTypeFromRemoteType(IRemoteTypeContract typeToFind)
[6904]    at Microsoft.VisualStudio.Tools.Applications.RemoteTypeAdapter.System.AddIn.Contract.Automation.IRemoteTypeContract.GetProperty(String name, BindingFlags bindingFlags, IRemoteTypeContract remoteReturnType, IArrayContract`1 remoteTypes)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
[6904] 
[6904] Exception rethrown at [1]: 
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
[6904]    at System.AddIn.Contract.Automation.IRemoteTypeContract.GetProperty(String name, BindingFlags bindingFlags, IRemoteTypeContract remoteReturnType, IArrayContract`1 remoteTypes)
[6904]    at Microsoft.VisualStudio.Tools.Applications.RemoteType.GetPropertyImpl(String name, BindingFlags bindingFlags, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
[6904]    at System.Type.GetProperty(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
[6904]    at AgileSoftware.GUIHost.Application.get_MyTestProperty()
[6904]    at CCEDesktopBasicAddInTest.ThisApplication.ThisApplication_Startup(Object sender, EventArgs e)
[6904]    at CCEDesktopBasicAddInTest.ThisApplication.FinishInitialization()
[6904]    at AgileSoftware.GUIHost.Application.Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract.FinishInitialization()
[6904]    at Microsoft.VisualStudio.Tools.Applications.EntryPointAdapter.Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract.FinishInitialization()
[6904] 
[6904] Server stack trace: 
[6904]    at Microsoft.VisualStudio.Tools.Applications.EntryPointAdapter.Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract.FinishInitialization()
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md
[6904] , Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
[6904]    at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
[6904] 
[6904] Exception rethrown at [0]: 
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
[6904]    at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
[6904]    at Microsoft.VisualStudio.Tools.Applications.Contract.IEntryPointContract.FinishInitialization()
[6904]    at Microsoft.VisualStudio.Tools.Applications.Internal.ExceptionFilter.ExceptionFilterHelper.CallFinishInitialization(IEntryPointContract hi, IExceptionFilterCallback callback)
[6904]    at Microsoft.VisualStudio.Tools.Applications.AddInImpl.ExecutePhase(String methodName, IEntryPointContract targetEntryPoint)
[6904]    at Microsoft.VisualStudio.Tools.Applications.AddInImpl.AttemptInternalLoad(IAppDomainBindingContract appDomainBinding, String appBase, String configFile, PermissionSet topOfStackPermission, StrongName[] strongNameAssemblies)
[6904]    at Microsoft.VisualStudio.Tools.Applications.AddInImpl.InternalLoad(IAppDomainBindingContract appDomainBinding, String appBase, String configFile, PermissionSet topOfStackPermission, StrongName[] strongNameAssemblies)
[6904]    at Microsoft.VisualStudio.Tools.Applications.AddInImpl.Load(String appBasePath)
[6904]    at Microsoft.VisualStudio.Tools.Applications.AddIn.Load(String appBasePath)
[6904]    at ASGUIHostVSTA.AIMExtension.LoadAddIns() in C:\Working\Plugin Framework\Source\AS GUI Host\ASGUIHostVSTA\ASGUIHostVSTA\Extenstion.cs:line 77

 Roger

Hi Roger,

You will have to use proxygen to create a proxy layer for the types contained in the dependent component and combine them with your application class proxy layer.

The proxy layer exists to prevent types defined in the host app from 'leaking' over to the add-in (and vice-versa) This is necessary, for version resilience and security (see MAF blogs).  Therefore, you must provide a proxy for all dependent types. 

Hope this helps!

Gary Depue, Summit Software

vstasupport@summsoft.com

Hi Gary,

Thanks for your response. I tried your suggestion but still got the same exception.

What I have done is:

•  running the proxygen against the dependent component to create a new .cs file (MyDependentLib.proxy.cs) ;
•  include it into the proxy project;
•  recompile the proxy project file and put it in the GAC.

When I tried my testing Add-in, I did not rebuilt the project template against the new proxy library, just recompiling the existing add-in project against the new proxy.

I am not quite sure the above is the correct way or not. I may have missed out something. Any comments appreciated.

Roger 

Hi Roger,

Yes, any time you change the proxy, you will need to run ProjectGen again (more on that later)

=====

Now here's how to wipe the slate clean and work with a matching set of bits and templates

1. Remove all orphaned instances of vsta.exe in task manager processes, and close all sample exes still running. 
2. Go to the gac (C:\\windows\\assembly) and uninstall all proxy assemblies
3. In the properties of the proxy assembly select Signing.  Check ‘Sign the assembly’ check box. Pulldown the ‘Choose a strong name key file:’ combobox and select <new…>
4. In the key file name enter key.snk (or whatever you wish).  Unselect the ‘Protect my key file with a password’ entry. Click OK
5. Rebuild proxy.
6. gacutil – i the proxy assembly in C:\\ShapeAppBasicMFC\\ShapeAppBasicMFC\\Proxy\\bin\\Debug
7. Confirm that it is installed in C:\\windows\\assembly

Now run ProjectGen ...

(Before you ru ProjectGen, I recommend using a new name for the project template and addin directory, at least, remove or rename the app-specific directory tree in MyDocuments so that ProjectGen creates completely new one)

8.  Run ProjectGen (be sure to generate a projectgen xml template to use for quick iterations in the future).  Change the naming as desired. 

I would not be surprised if you could debug into the proxy layer code; for instance, Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager GetMap()) 

or debug into the

HostItemProvider code; for instance,

HostItemProvider::GetHostObject(String^ primaryType, String^ primaryCookie)).

==

Another easy thing you might try is to work around the problem by reducing/simplifying the proxy layer.  You can do this by setting isExcluded=”true” for most of your object model in your descriptor.xml (just do a ‘replace all’ for all the isExcluded="false" entries in the entire xml file to set all to isExcluded="true".)  Reset a select few entries to isExcluded="false" again.

Then regenerate the proxy source using the descriptor as input:

>proxygen /l:<path to yourassembly or typelib> /c:proxy.cs /i:descriptor.xml /f

Excluding all the objects except the entry object and one of its properties is the simplest proxy layer that you can generate and still test from the addin. 

Hope this helps.

 Gary

Hi Gary,

Thanks for your updating, I've found what I have missed out: I just simply included the dependent component proxy file (the .cs file created by the Genproxy) into the proxy project without calling its Microsoft.VisualStudio.Tools.Applications.ProxyServices.Helper.xxxx.AddTypesToMap method to add the CanonicalName/Type map to the typeInfrastructureManager. It worked after I implemented the above operation.

BTW, when I was trying creating the proxy tier project with the proxygen, I notice that if a class derives from the MarshalByRefObject the proxy class created for it will be compiled with a couple of exceptions and I’ve got to manually fix its proxy source file. My testing class is

namespace ASGUIHostVSTA

{

    public class TestProperty2 : MarshalByRefObject, TestLib.ITestProperty2

    {

        string id = "1234567890";

        #region ITestProperty2 Members

        public string ID

        {

            get

            {

                return id;

            }

            set

            {

                id = value;

            }

        }

        public void DoSomeThing(string text)

        {

            System.Diagnostics.Trace.WriteLine(text);

        }

        #endregion

    }

}

Compiling its proxy file created by the proxygen had the following exceptions:

Error     33         'ASGUIHostVSTA.TestProperty2' does not contain a definition for 'RemoteObject'    C:\Working\Plugin Framework\Source\AS GUI Host\ASGUIHostVSTA\ASGUIHostVSTAProxy\Proxy.cs          537       88            ASGUIHostVSTAProxy

Error     34         No overload for method 'MarshalByRefObject' takes '2' arguments  C:\Working\Plugin Framework\Source\AS GUI Host\ASGUIHostVSTA\ASGUIHostVSTAProxy\Proxy.cs  541       10         ASGUIHostVSTAProxy

Error     35         'ASGUIHostVSTA.TestProperty2' does not contain a definition for 'RemoteObject'    C:\Working\Plugin Framework\Source\AS GUI Host\ASGUIHostVSTA\ASGUIHostVSTAProxy\Proxy.cs          555       22            ASGUIHostVSTAProxy

Error     36         'ASGUIHostVSTA.TestProperty2' does not contain a definition for 'RemoteObject'    C:\Working\Plugin Framework\Source\AS GUI Host\ASGUIHostVSTA\ASGUIHostVSTAProxy\Proxy.cs          557       40            ASGUIHostVSTAProxy

 Thanks,

 Roger

Thanks Roger,

I'll take a look at the "...does not contain a definition for 'RemoteObject'" error and report it to the VSTA team at Microsoft.

Regards,

Gary

Thanks Gary, it is greately appreciated if this issue could be fixed. In our proxy tier we have quite a few classes like that and could afford to modify every one manually.

Roger

Still waiting on reply from Microsoft.

Will ask again.

-G

This is a bug that should be fixed in the next release of ProxyGen.

-G

Thanks Gary. Does MS have an estimated timeframe when is the next release?

Roger 

MS expects vNext of VSTA will ship around the time Visual Studio 'Orcas' ships.

If this proxygen problem is a blocking issue, I would again recommend taking the minimal/simple proxy layer approach.

Thanks Gary. This sounds reasonable - creating a thin proxy layer and leave other jobs to the user plug-ins, providing the host provide all the necessary objects - even if it needs to do a downcast job. We'll think about it seriously.

Roger

Gary

For this to work doesn't it require that the type of the OM is known, i.e. that it is a COM object or some other .NET known type?

The reason I'm asking is that I have the same problem when trying to integrate VSTA into our appplication in order to get a scripting and a macro recording solution. I simply cannot create a proxy for all my types because of limitations in proxygen:
 1) lack of support for generics (we use these extensively)
 2) lack of support for dependent components (we have +100 dll's - some contain utility classes others use and some contain base classes others use)
 3) a bug: when an interface implements a base interface and "new"'s one of its members in order to return a more specific type the generated proxy code does not compile (the problem is that two proxy methods only differing in return type is created).
 4) the problem with MarshallByRef objects that you are also discussing

My code base is simply too big for me to try to wrap or rewrite everything to suit ProxyGens needs. All of this means that I have not been able to expose the full object model to the macro/script project. I have had to make a reduced object model wrapping a small subset of the full one. However, this is not a feasible solution as I would then have to develop and maintain two object models in the future with all the extra work and maintenance problems this yields.

So what I would really like is to do something like you describe above, i.e. have a thin proxy layer that only hands a reference to the full object model along to the macro project. I have been experimenting with this but without success and have concluded that a proxy has to be made for all classes and methods I want to use in the macros. You seem to indicate above that it should be possible or am I misunderstanding something?

Cheers,
 Thomas

>>I have been experimenting with this but without success and have concluded that >>a proxy has to be made for all classes and methods I want to use in the macros.

I have this working with testcon (simple managed OM) and with VB6 (simple unmanaged OM).  What specific problems are you encountering?  Tell me I will look into it and possibly send along a relevant sample.

-Gary

Hi Gary

Thank you for the quick response!

I have created a proxy for a simplified object model of my program and this works fine: I am able to execute macros working on the simplified object model. Then (inspired by this blog) I went on and tried to let the simplified object model return a reference to a more advanced object (sudokuObjectModel) defined in another assembly. I did this by adding a method that returned this as an object:

        public System.Object GetParameter()
        {
            return (System.Object)sudokuObjectModel;
        }

I am able to build the proxy and the project template and build a macro trying to access this method. But when the macro calls this function it fails in the proxy code for GetParameter() with the same keynotfound exception as Roger describes above. Why I am not sure. System.Object is in the typemap (but with a GUID of all 0's) but the type of my sudokuObjectModel (SudokuUI) is not of course. (If I try to have GetParameter return some intrinsic type as an object instead that works fine.)

I then tried to add the sudokuObjectModel to the typemap myself. The InitializeTypeInfrastructureManager() in extension.cs I modified to:
        private void InitializeTypeInfrastructureManager()
        {
            if (typeInfrastructureManager == null)
            {
                typeInfrastructureManager = new TypeInfrastructureManager();

                // This was auto-generated from ProxyGen with the /h:hostmapfile commandline argument.
                global::System.Type hostType;
                global::System.Type proxyType;
                hostType = typeof(global::BK.Platform.Example.Sudoku.SudokuScriptingUI);
                proxyType = typeof(NonProxiableType<global::BK.Platform.Example.Sudoku.SudokuScriptingUI>);
                typeInfrastructureManager.CanonicalNameToTypeMap.Add("Framework3-Example-Sudoku-ScriptingUI, BK.Platform.Example.Sudoku.SudokuScripting" +
                        "UI", proxyType);
                typeInfrastructureManager.TypeToCanonicalNameMap.Add(hostType, "Framework3-Example-Sudoku-ScriptingUI, BK.Platform.Example.Sudoku.SudokuScripting" +
                        "UI");

                hostType = typeof(global::BK.Platform.Example.Sudoku.SudokuUI);
                proxyType = typeof(NonProxiableType<global::BK.Platform.Example.Sudoku.SudokuUI>);
                typeInfrastructureManager.CanonicalNameToTypeMap.Add("Framework3-Example-Sudoku-UIModel, BK.Platform.Example.Sudoku.SudokuUI", proxyType);
                typeInfrastructureManager.TypeToCanonicalNameMap.Add(hostType, "Framework3-Example-Sudoku-UIModel, BK.Platform.Example.Sudoku.SudokuUI");
            }
        }

And in the proxy.cs the AddTypesToMap looks like this:
        public static global::Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager AddTypesToMap(global::Microsoft.VisualStudio.Tools.Applications.TypeInfrastructureManager typeInfrastructureManager) {
            typeInfrastructureManager.CanonicalNameToTypeMap.Add("Framework3-Example-Sudoku-ScriptingUI, BK.Platform.Example.Sudoku.SudokuScripting" +
                    "UI", typeof(global::BK.Platform.Example.Sudoku.SudokuScriptingUI));
            typeInfrastructureManager.TypeToCanonicalNameMap.Add(typeof(global::BK.Platform.Example.Sudoku.SudokuScriptingUI), "Framework3-Example-Sudoku-ScriptingUI, BK.Platform.Example.Sudoku.SudokuScripting" +
                    "UI");

            System.Type proxyType = typeof(NonProxiableType<global::BK.Platform.Example.Sudoku.SudokuUI>);
            typeInfrastructureManager.CanonicalNameToTypeMap.Add("Framework3-Example-Sudoku-UIModel, BK.Platform.Example.Sudoku.SudokuUI", proxyType);
            typeInfrastructureManager.TypeToCanonicalNameMap.Add(proxyType, "Framework3-Example-Sudoku-UIModel, BK.Platform.Example.Sudoku.SudokuUI");
          
            return typeInfrastructureManager;
        }

This also compiles and runs but fails the same place with a slightly different error: unknownproxytypeexception: No proxy type matches the specified canonical name.

You mention you have a .NET sample where you do something like this. Could you make that available for me?

Cheers,
 Thomas