[MonoDevelop] Patch allowing support for MonoXNA addin

Lars Magnusson lavima at gmail.com
Thu Mar 4 01:32:55 EST 2010 

I just wanted to check on the progress.. I'm prepared to make further
changes if they are needed.

-lavima

On Tue, Feb 9, 2010 at 10:00 AM, Lars Magnusson <lavima at gmail.com> wrote:
> 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
>>
>>
>>
>

More information about the Monodevelop-list mailing list