[MonoDevelop] Patch allowing support for MonoXNA addin

[Lars Magnusson]

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

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