More a curiousity question really, I've noticed in our project system that if you have the project node selected when you click the Project menu the menu just shows 'Properties' as the last item. Selecting any other hierarchy node shows '[Project_name] Properties'. I've noticed this also with the VSSDK samples (e.g. BscPrj or IronPython projects).
C# always shows '[Project_name] Properties' regardless of the hierarchy selection. So the question is, what's different in this case
How does the IDE determine the project name to show in the Project menu?
millercj
For those following this post, it apears the problem Simon hit was due to some problems in the MPF project aggregator. Testing this repro scenario against the soon to be release Visual Studio SDK Version 2, the problem no longer occurs.
The new SDK is in the last cycle of testing and verification, and should be out shortly.
Kenny Spade
Hi Ed, hopefully you should be able to repro this by following these steps:
- Using bscprj sample, amend a .bscp project file to add the ProjectSubType sample guid. I.E. in the.bscp file
"ProjectGuids" = "{AEED9E8B-A96E-4019-908B-7DD7099C7BD4};{06D95370-B7D2-11D1-87B4-00A0C91E2A46}"
Put this project into the ProjectSubType sample Templates directory.
- You should now be able to create a new task project based on the .bscp once you've built the projectsubtype sample.
- Initially, you will not be able to bring up the project pages (and in fact closing the IDE doesn't work either!). The latter problem is to do with hierutil for some reason returning E_INVALIDARG in QueryClose - you have to override that yourself. The former problem is related to where the project browse object is implemented. All the old hierutil samples implement IDispatch on the hierarchy node and in hierutil there's a QI for IDispatch for the project browse object (in hu_archy.cpp). In the aggregated case this performs a QI on the Outer object (which returns E_NOINTERFACE). You can get round this by adding support for VSHPROPID_BrowseObject in the project node and doing an Internal QI back on the hierarchy node. Whether this is right or wrong or against the rules of aggregation I don't know. However, by doing this you'll be able to bring up the property page dialog and it should say 'MarshalByRefObject Property Pages'.
- If you now implement an IDispatch on the project node (prjnroot.cpp) you'll actually be able to get the correct project name displayed. Of course, you'll end up moving a bunch of interfaces from the hierarchy node to the project node if you actually want to see anything useful(e.g. ISpecifyPropertyPages, IVsGetCfgProvider etc).
I guess my real question is where is the correct place to implement the project browse object The project managed code sample appears to implement it explicitly on the project node. Are the hierutil code samples actually incorrect Is the 'MarshalByRefObject' some kind of native/managed marshalling bug
Regards,
xcorporation
Dino Nguyen
Hi Simon,
I thought this would be fairly easy to figure out, but was I ever mistaken
. However, curiousity led me to debug both a C# and a MyC project to try and figure out how this stuff actually works.
The menu item in question corresponds to the guidVSStd97:cmdidProjectProperties command, which is actually processed by the IDE. The IDE's IOleCommandTarget::QueryStatus implementation processes this command by checking against the current selection status of the solution explorer.
If the selected item(s) don't support ISpecifyPropertyPages, the IDE will attempt to retrieve the VSHPROPID_BrowseObject of the selected project, QI for IDispatch and then call Invoke on the object's "_id" property. If this property doesn't exist, we then try using the MEMID_Name dispid, and then attempt to call GetIDsOfNames to find the "Name" property, to call Invoke against.
C# projects actually implement that _id property, but if you tweak the MyC project by commenting out the entry for ISpecifyPropertyPages in the COM MAP of the CMyProjectCfg class (in projcfg.h), you'll see that the project name get displayed after the shell call's into the Name property (implemented by CMyProjectHierarchy::get_Name in prjheir.cpp).
However, having removed ISpecifyPropertyPages, you will now have no support for the Properties dialog.
C# and VB projects implement a project designer, which the the shell's IOleCommandTarget.Exec implementation tests for (presumably looking for the VSHPROPID_SupportsProjectDesigner property mentioned below), so conequently we wind up displaying the project designer. But our existing samples don't support these, and you wind up falling though to the default behavior where we blissfully display an empty property frame.
So essentially, the trick to getting the project name on that menu item, is to remove the ISpecifyPropertyPages implementation from your project configuration object (the object that implements IVsProjectCfg2), and add support to display a custom project designer. Which sadly we have zero information on how to implement in the SDK today.
For those interested in implementing a project designer, I can only recommend that you closely research the comments in the SDK's VSSHELL80.IDL files around constructs like VSHPROPID_ProjectDesignerEditor and VSHPROPID_SupportsProjectDesigner, and IVsSpecifyProjectDesignerPages.
A sample illustrating implementation of a custom project designer is something we're currently considering for a future release of the VS SDK.
Sincerely,
Todd H.
frank_wang
Hi Simon,
The code appears to be similar. We use the same function to retrieve the name of the selected object "_PageFrameGetNameOfObject".
Can you post some additional details as to what you are actually seeing, and now to repro
Thanks,
Kyralessa
Thanks for a great response Ed.
One further query, can you tell me how the property page frame determines the project name as well It appears to be based on the IDispatch 'Name' property too, but I've been experimenting with adding support for project flavoring and noticed the strange effect that the property page frame is showing 'MarshalByRefObject Property Pages' in this case!