[MonoDevelop] Patch allowing support for MonoXNA addin

[Lluis Sanchez Gual]

El dg 24 de 01 de 2010 a les 17:48 +0100, en/na Lars Magnusson va
escriure:
> Hi
> 
> This patch has been written as a result of many hours of frustration
> trying to achieve the functionality needed to develop a MonoXNA addin
> for MD. I've made a post here in the mailing list
> (http://lists.ximian.com/pipermail/monodevelop-list/2010-January/011008.html)

I was on holidays when you sent this mail and I somehow forgot about it,
sorry.

> and bothered lluis numerous times on the irc channel. But I decided
> not to wait for help anymore and make some changes to MD myself. These
> changes makes the development of a MonoXNA possible (or at least much
> easier)
> 
> Most of the changes is in the MonoDevelop.Projects assembly, but some
> changes have also been made in MonoDevelop.Ide. The changes have been
> described in the Changelog entries, but common for all of them is that
> they should not change the current behavior of MD, it should only add
> additional flexibility)

The changes in MonoDevelop.Projects.Formats.MSBuild are mostly ok, but
there is a major issue. In MD there are several DotNetProjectNode nodes,
one for each supported .net language (c#, vb.net, boo, etc). Each
DotNetProjectNode defines an extension (csproj, vbproj, booproj...).
When loading a project, the extension of the file is used to match files
to DotNetProjectNode instances. The problem with nested project is that
they always use the extension contentproj, so the file extension can't
be used anymore to find the corresponding DotNetProjectNode. Your
implementation of DotNetProjectNode.CanHandleFile is not correct because
it is going to match any DotNetProjectNode it finds, no matter what's
the language of the project.

To properly find the language, some additional work is required. msbuild
files contain the project type guid in the ProjectTypeGuids property. So
when no direct match of extension is found, MD could try to read that
guid from the file, and use it to find a matching DotNetProjectNode.

The changes in MD.Projects don't look good to me. You say that they
should not change the current behavior of MD, but that's not really
true. Introducing a new Visible property means that all code in MD that
iterates through solution items has to deal with that property, ignoring
the item when visible=false. You patched a couple of files, but there
are many other files that would need to be patched. So this is actually
an important change in behavior.

I think there is a less intrusive solution. I added a new protected
method to SolutionItem: RegisterInternalChild (item). With this method
you can register a nested solution item, and events like file add/remove
should flow up to the workspace, yet this child won't be included in any
items collection in the solution. I haven't really tested it, so tell me
if you find any issue with it.

Lluis.