[MonoDevelop] About cyclic dependencies and more

Sat Apr 29 12:11:39 EDT 2006

Hi again. Thanks for your answer Lluis. I reply inline:

Lluis Sanchez escribió:
> Hi!
>
>> Hello MonoDevelopers...
>>
>> When translating MonoDevelop I noticed that there is a string warning
>> the user about the lacking feature of managing cyclic dependencies with
>> MonoDevelop. However, I have tried to make a cyclic dependency and
>> MonoDevelop has not warned me, and instead it has showed me the
>> following exception:
>>
>>> Ocurrió una excepción: Exception has been thrown by the target of an
invocation.
>>>
>>> System.Reflection.TargetInvocationException: Exception has been
thrown by the target of an invocation. --->
MonoDevelop.Projects.CyclicBuildOrderException: Exception of type
MonoDevelop.Projects.CyclicBuildOrderException was thrown.
>>> in <0x00291> MonoDevelop.Projects.Combine:Insert (Int32 index,
MonoDevelop.Projects.CombineEntryCollection allProjects,
MonoDevelop.Projects.CombineEntryCollection sortedEntries,
System.Boolean[] inserted, System.Boolean[] triedToInsert)
>>> in <0x00155> MonoDevelop.Projects.Combine:Insert (Int32 index,
MonoDevelop.Projects.CombineEntryCollection allProjects,
MonoDevelop.Projects.CombineEntryCollection sortedEntries,
System.Boolean[] inserted, System.Boolean[] triedToInsert)
>>> in <0x00155> MonoDevelop.Projects.Combine:Insert (Int32 index,
MonoDevelop.Projects.CombineEntryCollection allProjects,
MonoDevelop.Projects.CombineEntryCollection sortedEntries,
System.Boolean[] inserted, System.Boolean[] triedToInsert)
>>> in <0x000eb> MonoDevelop.Projects.Combine:TopologicalSort
(MonoDevelop.Projects.CombineEntryCollection allProjects)
>>> in <0x0003a> MonoDevelop.Projects.Combine:GetAllProjects (Boolean
topologicalSort)
>>> in <0x000bd>
MonoDevelop.GtkCore.GuiBuilder.GuiBuilderService:UpdateWidgetRegistry ()
>>> in <0x00007>
MonoDevelop.GtkCore.GuiBuilder.GuiBuilderService:OnReferencesChanged
(System.Object sender, MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs
(object,MonoDevelop.Projects.ProjectReferenceEventArgs)
>>> in <0x00036> __ProjectReferenceEventHandler_DelegateFactory:Dispatch
(System.Object )
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object (object)
>>> in <0x00045> MonoDevelop.Core.Gui.GuiSyncContext:AsyncDispatch
(MonoDevelop.Core.Gui.StatefulMessageHandler cb, System.Object ob)
>>> in <0x00070>
__ProjectReferenceEventHandler_DelegateFactory:ProxyCall (System.Object
, MonoDevelop.Projects.ProjectReferenceEventArgs )
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs
(object,MonoDevelop.Projects.ProjectReferenceEventArgs)
>>> in <0x00023> MonoDevelop.Projects.Combine:OnReferenceAddedToProject
(MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in <0x00011>
MonoDevelop.Projects.Combine:NotifyReferenceAddedToProject
(System.Object sender, MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs
(object,MonoDevelop.Projects.ProjectReferenceEventArgs)
>>> in <0x00023> MonoDevelop.Projects.Combine:OnReferenceAddedToProject
(MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in <0x00011>
MonoDevelop.Projects.Combine:NotifyReferenceAddedToProject
(System.Object sender, MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs
(object,MonoDevelop.Projects.ProjectReferenceEventArgs)
>>> in (wrapper delegate-invoke)
System.MulticastDelegate:invoke_void_object_ProjectReferenceEventArgs
(object,MonoDevelop.Projects.ProjectReferenceEventArgs)
>>> in <0x0001d> MonoDevelop.Projects.Project:OnReferenceAddedToProject
(MonoDevelop.Projects.ProjectReferenceEventArgs e)
>>> in <0x0003c>
MonoDevelop.Projects.Project:NotifyReferenceAddedToProject
(MonoDevelop.Projects.ProjectReference reference)
>>> in <0x00070>
MonoDevelop.Projects.ProjectReferenceCollection:OnInsertComplete (Int32
index, System.Object value)
>>> in <0x00075>
System.Collections.CollectionBase:System.Collections.IList.Add
(System.Object value)--- End of inner exception stack trace ---
>>>
>>> in <0x0010e> System.Reflection.MonoMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
>>> in <0x0001a> System.Reflection.MethodBase:Invoke (System.Object obj,
System.Object[] parameters)
>>> in <0x00015> MonoDevelop.Components.Commands.CommandHandlerInfo:Run
(System.Object cmdTarget)
>>> in <0x0035a>
MonoDevelop.Components.Commands.CommandManager:DispatchCommand
(System.Object commandId, System.Object dataItem)
>>
>> Is this the expected behaviour? Should I file a bug for that?
>
> Yes, please.

I have filed it in:
http://bugzilla.ximian.com/show_bug.cgi?id=78174

>
>> I have found this issue when working with the "MonoDevelop.mds" solution
>> file, from which I have found the following issues:
>>
>>
>> - When clicking on "Clean solution" after a compilation has been failed,
>> the following exception arised:
>>
>>> Ocurrió una excepción: Object reference not set to an instance of an
object
>>>
>>> System.NullReferenceException: Object reference not set to an
instance of an object
>>> in <0x0008d> MonoDevelop.Projects.Combine:Clean ()
>>> in <0x00094> MonoDevelop.Projects.Combine:Clean ()
>>> in <0x0001e> MonoDevelop.Ide.Commands.CleanSolutionHandler:Run ()
>>> in <0x0000b> MonoDevelop.Components.Commands.CommandHandler:Run
(System.Object dataItem)
>>> in <0x00056>
MonoDevelop.Components.Commands.ActionCommand:DispatchCommand
(System.Object dataItem)
>>> in <0x0039a>
MonoDevelop.Components.Commands.CommandManager:DispatchCommand
(System.Object commandId, System.Object dataItem)
>
> Please file a bug report for this as well.

http://bugzilla.ximian.com/show_bug.cgi?id=78242

>>
>> - The MonoDevelop.Documentation project depends on MonoDevelop.Projects,
>> which depends also on MonoDevelop.Documentation,
>
> This last reference should be removed.

I will prepare a patch then.

>> so why is here this
>> cyclic dependency? Is desirable to fix the namespaces (adding one more
>> project, I wonder...) so as to remove it? I suppose yes, so as to be
>> able to make a self compilation of MonoDevelop inside MonoDevelop,
>> although I deduce that a whole build is not possible (yet?).
>>
>> - When opening MonoDevelop.mds I have obtained a FileNotFound exception.
>> The fix is to replace "VBNetBinding.mds" by "VBNetBinding.mdp".
>
> The missing mds file is now in SVN.

Well, I think the file was already there, but the file referenced by
Extras.mds was wrong.

>> - Some files referenced in projects are not found (for example,
>> GettextCatalog.cs, but the one that exists is the same file ended wit
>> ".cs.in"). I suppose this is because GettextCatalog.cs must be generated
>> from GettextCatalog.cs.in, am I right?
>
> Yes.
>
>> Would it be possible to
>> pre-generate it before loading and working with the MonoDevelop.mds
>> solution? (BTW, the same happens with AssemblyInfo.cs <->
>> AssemblyInfo.cs.in in the same project:
>> Core/src/MonoDevelop.Core/MonoDevelop.Core.mdp .)
>
> Those files are generated when running the configure script. We can't
> change that.

I see. I have been investigating about all these *.in files in MD and
particularly about this one (GettextCatalog.cs.in) and I see that the
only thing that must be generated by the config script file is a
parameter that is a part of a path. Couldn't this parameter be guessed
in execution time instead of pregenerating a source file? I think this
thing is preventing the more intuitive use of an IDE when using this
files because we break the C# syntax completely when adding parameters
like these (i.e.: @EXAMPLE@). I guess that the last consequence of this
is indeed the inability of MD to compile itself (unless the "autotools"
add-in is developed, am I right?), which BTW is a feature requested in
the TODO list of MonoDevelop.

I suppose that all these questions arise to me basically because of my
lack of experience with developing mainly in UNIX/Linux environments,
where I am noticing there is a lot of script culture, use of
command-line tools (make, automake, ...), etc., which I have almost
never used.

Perhaps someone of you could point me to a good tutorial about this
stuff and then I won't bug this list with my dumb questions anymore :)

>> - It seems that the file Core/src/MonoDevelop.Core/MonoDevelop.Core.mds
>> is not used and the one that is referenced from Core.mds is
>> Core/src/MonoDevelop.Core/MonoDevelop.Core.mdp, so it should be safe to
>> delete it.
>
> Deleted.

Oops, now I can see that there are some assemblies that also include an
.mds file *although* they are not referenced by any file in a parent
folder. Should we delete all those files?

Regards,

    Andrés    [ knocte ]

-- 