Created attachment 75265 [details] [review]
doxygen_parse_c++cli.patch

Again, this patch is tested with a complex C++/CLI program, and is taken from a much larger set of changes working against a huge .NET application with C#, C++, C, C++/CLI and additional dot graphs.

Created attachment 75267 [details] [review]
doxygen_parse_c++cli.patch

The other one had some cvs diff junk at the top that wasn't related.

Created attachment 75268 [details] [review]
doxygen_parse_c++cli.patch

Now I obsolete everything properly.

Just a comment to support the importance of this bug/patch for Windows C++ developers.  There is an increasing push for C++ developers on Windows to be using the C++/CLI extensions - as this makes it possible to use the .NET framework (much better GUI/dialog editor, etc).
Our team would very much like to see this patch integrated into doxygen...

I have a couple more updates related to finalizers and \copydoc, if you use those let me know and I'll make a new patch.  Meanwhile my project lead wants some new functionality implemented so documentation (and therefore any work on doxygen) gets delayed yet again...

But please do try out the patch and let me know if you have any code that confuses it.

Hi Ben,

I noticed that a large part of your patch deals with adding support for the "internal" access-specifier. I've been reading through the C++/CLI standard (which has little to do with "real" C++ by the way) to see how this is used and noticed there are two more possible access-specifiers (see section 34.7.2) 
The total list is:

1) private
2) protected
3) public
4) internal
5) protected public      OR     public protected
6) protected private     OR     private protected

So I think we should either support them all or not.

The semantics of internal seem equivalent to package scope in Java...

At first glance, internal looks the same as package, but it's not.  I guess you could say it's what package should have been.

For Java's package visibility, you can join someone else's package and get access to "package" variables and methods.  .NET's internal visibility is limited by the physical presence of the code within the .DLL, not the logical namespace.  In fact, most .NET assemblies end up with "XYZ.Internals" namespaces and classes to tuck away helper functions into.

You're right that the other two visibility layers should probably be added as well (though they're not available from C#).

It's all a great hack because .NET doesn't support the C++ idea of friend.  And then there's the InternalsVisibleToAttribute.

I'd actually consider it quite reasonable to ditch the separate blocks for internal in the documentation and just look at the INTERNAL_DOCS config setting.  If it's set, treat internal as public, protected public as public, and private protected as protected, while if INTERNAL_DOCS is false, treat internal as private, protected public as protected, and private protected as private.

doxywizard is having a problem setting the new CPP_CLI_SUPPORT flag.  We'll need to fix that also.

This issue was initially brought up by a subscriber from our doxygen-users mailing list.

Created attachment 77874 [details] [review]
Proposed Patch for the Doxywizard

This patch should fully add the CPP_CLI_SUPPORT option from the doxywizard's wizard.

Kevin what is the exact problem with doxywizard w.r.t. the CPP_CLI_SUPPORT flag? 

I don't think it is a good idea to couple the CPP_CLI_SUPPORT to the C# output option, since C# and C++/CLI are different languages.

As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to 

   https://github.com/doxygen/doxygen/issues

All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github.

Hence I am closing this GNOME Bugzilla ticket.
Please use the corresponding ticket in Github instead. Thanks a lot!