If you've downloaded and tried out the IronPythonIntegration sample in the July/August 2007 CTP of the VSSDK, you may have noticed the addition of WPF project support for IronPython projects. We've had questions from folks also trying to add this support to their project systems around trouble getting the "Add New Item" dialog to appear. Indeed, you'll notice that this is also not working in the IronPythonIntegration sample. In the spirit of openness and airing dirty laundry, here's an explanation of the issue(s) as well as what you can do about it today, and when Visual Studio 2008 is released:
In short, the IronPythonIntegration sample isn't quite correct in the implementation we shipped in the July/August CTP. When Visual Studio needs to bring up the "Add New Item" dialog, it needs to know which item templates it should show. For example, you wouldn't want to see C# specific items appear if you were working on a Visual Basic project. Before showing the dialog, VS will query the project system for the VSHPROPID_AddItemTemplatesGuid property. The GUID that gets returned tells Visual Studio which templates to show.
Since the WPF flavor doesn't know about non-Microsoft project systems that it might be flavoring, it can't possibly know what GUID in advance to return here. As such, the correct way to do this is to provide your own flavor that sits atop the WPF flavor. Doing this allows you to override GetGuidProperty and return the proper value to Visual Studio. The version of the IronPython sample in the latest CTP does not show this.
Our next release of the Visual Studio 2008 SDK will show how to do this correctly.
Yes, but that depends on your definition of "working". :-) The problem here is that in Beta 2, the WPF Flavor used a deprecated version of the classes that allow you to do "flavored" projects in C#. Your language-specific WPF flavor would also need to use the old classes (FlavoredProjectFactory/FlavoredProject) in Beta 2. In the upcoming final release of VS 2008, the WPF flavor uses the new classes (FlavoredProjectFactoryBase/FlavoredProjectBase), and your language-specific flavor would need to match it.
I only mention the definition of "working" because the old classes have some known bugs around the way they handle COM-aggregation behind the scenes. The bugs could cause your product to crash Visual Studio under certain situations. The new classes which will need to be used at RTM do not have these problems.