Support for C++ Projects

Topics: Features, General Discussion
May 11, 2007 at 6:31 AM
Hi ...

what's the reason for the lacking support for managed C++ projects? As far as I know Sandcastle supports C++ Assemblies too ...

Greetings
RogerLae
Coordinator
May 11, 2007 at 10:59 AM
Hi,

Sandcastle will support a C++ project as long as it generates a managed assembly and optionally, an xml documentation file. The language that is used to generate a managed assembly is not important.

The problem is that DocProject uses Visual Studio automation and, in particular, the VSLangProj80.VSProject2 interface, which only provides information for Visual C#, Visual J# and Visual Basic projects. Visual C++ projects require the Microsoft.VisualStudio.VCProjectEngine.VCProject interface, which does not share a common inheritance chain and is defined in a different assembly. In order to use both interfaces DocProject would have to essentially provide two different back-ends with mirrored functionality whenever an automation interface is required.

I do plan on attempting to provide support for C++ in the future, but I don't know if it will be possible at this point using the C++ automation interfaces or even how difficult it will be. But I was going to try it when I refactor the engine for the MSBuild support, soon.

I've thought about creating a class that will encapsulate the automation functionality required of Visual Studio. All classes that require VS automation would instead use the methods and properties of this facade class, which would query for the supported VS automation interfaces whenever they are needed without having to expose them.

Sorry for any inconvenience, but thanks anyway for your interest in DocProject :)
Coordinator
May 11, 2007 at 11:02 AM
Hi,

You may want to add a work item for this in the Issue Tracker so that others could vote on the feature. Thanks!
May 16, 2007 at 2:34 PM

davedev wrote:
Hi,

Sandcastle will support a C++ project as long as it generates a managed assembly and optionally, an xml documentation file. The language that is used to generate a managed assembly is not important.

The problem is that DocProject uses Visual Studio automation and, in particular, the VSLangProj80.VSProject2 interface, which only provides information for Visual C#, Visual J# and Visual Basic projects. Visual C++ projects require the Microsoft.VisualStudio.VCProjectEngine.VCProject interface, which does not share a common inheritance chain and is defined in a different assembly. In order to use both interfaces DocProject would have to essentially provide two different back-ends with mirrored functionality whenever an automation interface is required.

I do plan on attempting to provide support for C++ in the future, but I don't know if it will be possible at this point using the C++ automation interfaces or even how difficult it will be. But I was going to try it when I refactor the engine for the MSBuild support, soon.

I've thought about creating a class that will encapsulate the automation functionality required of Visual Studio. All classes that require VS automation would instead use the methods and properties of this facade class, which would query for the supported VS automation interfaces whenever they are needed without having to expose them.

Sorry for any inconvenience, but thanks anyway for your interest in DocProject :)


Hi ...

I looked a little bit around and in fact this separation of interfaces makes it awkward to integrate managed C++ projects.
What Do You think about such a functionality like "external links" in a way like: adding a list of assemblies/.xml - documentation.

I think, that the support from Microsoft for C++, even managed, will be reduced, so may be it doesn't pay off to think about integration in a more elegant manner.

By the way, DocProject is very cool :-)
Coordinator
May 16, 2007 at 4:05 PM
Hi,

First, thanks for the feedback :)


I looked a little bit around and in fact this separation of interfaces makes it awkward to integrate managed C++ projects.

To support my plans for MSBuild and command-line build functionality I need a way to execute the build process outside of the Visual Studio IDE, which means no automation interfaces at all. I've almost completed a few new classes to account for this and I've been mercilessly refactoring the Add-In and Sandcastle projects to use the new classes in place of the VS automation interfaces. So far, I've already encapsulated the dependency and sources (project references) lists into the new classes and removed them from the BuildSettings class, which always seemed to me like a weird place for them. The new classes so far:

  • VSAnyProject : DTEComponent
  • VSDocProject : VSAnyProject
  • VSSourceProject : VSAnyProject
The cool thing about doing this, other than how much it improves the code-base, is that I can easily encapsulate the C++ automation interfaces into these facade classes right next to the VSProject2 interface, as long as the C++ interfaces expose the same functionality. If they do, then expect to see full support for managed C++ in the 1.6.0 RC of DocProject. This means possible support for C++ projects as sources and as DocProject and DocSite templates (although I probably won't add C++ templates in the next release).


What Do You think about such a functionality like "external links" in a way like: adding a list of assemblies/.xml - documentation.

I haven't thought about adding support for external sources, yet, but it's an interesting idea and I'll certainly consider it for a subsequent release. You should add a work item for this and describe the idea in a bit more detail.


I think, that the support from Microsoft for C++, even managed, will be reduced, so may be it doesn't pay off to think about integration in a more elegant manner.

It's still probably a good idea to add a work item for the support of C++ projects since I'd really like to know what others think about the feature. And although you may be right, it may end up being really easy to do so, why not? ;)

Thanks.