[MonoDevelop] Patch allowing support for MonoXNA addin

[Lluis Sanchez Gual]

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