[MonoDevelop] Patch allowing support for MonoXNA addin
lavima at gmail.com
Mon Jan 25 14:19:03 EST 2010
On Mon, Jan 25, 2010 at 5:47 PM, Lluis Sanchez Gual
<slluis.devel at gmail.com> wrote:
> El dg 24 de 01 de 2010 a les 17:48 +0100, en/na Lars Magnusson va
>> 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
> I was on holidays when you sent this mail and I somehow forgot about it,
There's no need to apologize :) I just wanted to explain why I
abandoned the previous solution you suggested and created the patch
>> 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
>> 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.
I thought about about this myself actually, but I guess I didn't grasp
the severity. I do now though.
> 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.
What I meant when I say it doesn't change the default behavior is that
this property is defaults to true. My reasoning was that this property
should only be responsible for hiding the project from the sln file
and the project pad, other than that the project should be considered
a normal project.
> 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.
I will do an update and test your approach.
Thanks for the quick response
More information about the Monodevelop-list