[MonoDevelop] Patch allowing support for MonoXNA addin

[Lars Magnusson]

Hi Lluis

I've been testing the SolutionItem.RegisterInternalChild() method, but
it seems to bring me back to my previous problems with the previous
possible solution you suggested. You pointed me towards a method (I
think it was MSBuildProjectService.LoadItem()) that lets me manually
specify the filename from where to load, but I can't find a
corresponding method which lets me save with a manually specified
filename. It also brings back some issues with the context menu were
it gives an exception (provided below) on first access. It seems to
complain about the parent solution being null, but why the problem
disappears after this initial problems is unknown to me.

Both of these issues are hopefully just me doing the wrong thing.. Do
you have any tips for me?

-lavima

System.NullReferenceException: Object reference not set to an instance
of an object
  at MonoDevelop.Ide.Execution.ExecutionModeCommandService+<GetCustomModes>c__Iterator6.MoveNext
() [0x00122] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Execution/ExecutionModeCommandService.cs:187
  at System.Collections.Generic.List`1[MonoDevelop.Ide.Execution.CustomExecutionMode].AddEnumerable
(IEnumerable`1 enumerable) [0x00000]
  at System.Collections.Generic.List`1[MonoDevelop.Ide.Execution.CustomExecutionMode]..ctor
(IEnumerable`1 collection) [0x00000]
  at MonoDevelop.Ide.Execution.ExecutionModeCommandService.GetExecutionModeCommands
(MonoDevelop.Ide.Execution.CommandExecutionContext ctx, Boolean
includeDefault, Boolean includeDefaultCustomizer) [0x00006] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Execution/ExecutionModeCommandService.cs:129
  at MonoDevelop.Ide.Execution.ExecutionModeCommandService.GenerateExecutionModeCommands
(MonoDevelop.Projects.SolutionEntityItem project,
MonoDevelop.Ide.Execution.CanExecuteDelegate runCheckDelegate,
MonoDevelop.Components.Commands.CommandArrayInfo info) [0x00008] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Execution/ExecutionModeCommandService.cs:70
  at MonoDevelop.Ide.Commands.RunEntryWithHandler.Update
(MonoDevelop.Components.Commands.CommandArrayInfo info) [0x00026] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Commands/ProjectCommands.cs:365
  at MonoDevelop.Components.Commands.ActionCommand.UpdateCommandInfo
(MonoDevelop.Components.Commands.CommandInfo info) [0x0005d] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Components/MonoDevelop.Components.Commands/ActionCommand.cs:106
  at MonoDevelop.Components.Commands.CommandManager.GetCommandInfo
(System.Object commandId, System.Object initialTarget) [0x00192] in
/home/lars/Documents/Code/monodevelop/main/src/core/MonoDevelop.Components/MonoDevelop.Components.Commands/CommandManager.cs:654

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
> 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.
>
>
>