[MonoDevelop] Patch allowing support for MonoXNA addin

[Lars Magnusson]

Oh I forgot..

There still are some issues with the command handling, and now also
the node builder.

I get the following error the first time I right-click the node:

Error while updating status of command: RunEntryWithList

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:192
  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:132
  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

When I press OK to close the error notification, two exceptions are
dumped to the console. These exceptions relates to gtk_window_move and
gtk_window_resize. Let me know if I should provide these exceptions as
well.

-lavima

On Tue, Feb 2, 2010 at 4:52 PM, Lluis Sanchez Gual
<slluis.devel at gmail.com> wrote:
> El dt 02 de 02 de 2010 a les 16:49 +0100, en/na Lars Magnusson va
> escriure:
>> I apparently misunderstood the previous reply, because I scrapped my
>> changes all together ;)
>>
>> So to sum up (so I don't misunderstand again):
>> - Keep the changes made to support alternative extensions, but modify
>> it to check the project type guid like suggested
>> - Scrap all the changes made to allow "hidden" solution items, and
>> instead use the RegisterInternalChild methods
>
> That's it.
>
>>
>> -lavima
>>
>>
>> On Tue, Feb 2, 2010 at 11:42 AM, Lluis Sanchez Gual
>> <slluis.devel at gmail.com> wrote:
>> > El dc 27 de 01 de 2010 a les 09:29 +0100, en/na Lars Magnusson va
>> > escriure:
>> >> 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.
>> >
>>
>> > With the changes you introduced and the changes I proposed (get the
>> > project type guid before loading) it is not necessary to use
>> > MSBuildProjectService.LoadItem. You should be able to load and save the
>> > project using the reguilar api.
>> >
>> >> 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.
>> >
>> > I just fixed an issue that might cause this exception. Please update and
>> > try again.
>> >
>> > Lluis.
>> >
>> >
>> >>
>> >> 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.
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> _______________________________________________
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
>
>