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
- Remove all orphaned instances of vsta.exe in task manager processes, and close all sample exes still running.
- Go to the gac (C:\\windows\\assembly) and uninstall all proxy assemblies
- 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…>
- In the key file name enter key.snk (or whatever you wish). Unselect the ‘Protect my key file with a password’ entry. Click OK
- Rebuild proxy.
- gacutil – i the proxy assembly in C:\\ShapeAppBasicMFC\\ShapeAppBasicMFC\\Proxy\\bin\\Debug
- 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.
9. Change VSTAHookup project’s Build, Output directory to output the assembly into the ShapeAppMFC output directory. This will allow debugging into vstahookup source.
10. Run ShapeAppMFC and open the IDE. Open a new project. Confirm that the proxy has been referenced in the add-in project.
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)).
By setting a breakpoint in: Microsoft.VisualStudio.Tools.Applications.ProxyServices.Helper.xxx.GetMap() which is implemented in the tim.cs auto-generated file, you should be able to trace until the point of failure. This failure occurs when there is some type defined in the TypeInfrastructureManager that does not match up in your Proxy. This could be some inherited type/base class, which proxygen will generate a GUID of (00000000-0000-0000-0000000000) if it can't find a maatch for it in your proxygen code.
Once you find the offending line, if it is a type or class that you do not need you can simply comment the type out.If it is a type or class that you expect to be exposed to VSTA, please send more specific information about the type/class that is failing so we can look into it further.
==
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