[MonoDevelop] Patch allowing support for MonoXNA addin

[Lluis Sanchez Gual]

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