[MonoDevelop] Compiling an add-in with generic methods

Kamil Skalski kamil.skalski at gmail.com
Sat Oct 22 15:40:38 EDT 2005


2005/10/22, Christian Hergert <christian.hergert at gmail.com>:
> It is my understanding that the 2.0 profile libraries are still very
> incomplete. I wouldn't want to hold addin developers back by limiting
> what they can use, especially since we are so close to a complete 1.1

I don't get it. 2.0 libraries are supersets of what 1.1 holds, so
there is not such thing like "limiting". In fact you allow MUCH more
to the developers, apart from using standard 1.1 features, they can
use generics, new classes, new methods, etc. etc.

> profile. Furthermore, 2.0 hasn't even been released by Microsoft yet as

Well, are we talking about compiling monodevelop on windows and MS
NET. or on mono?
Mono has a quite stable implementation of generics and other .NET 2.0
features. And increasing the availability of them to developers could
cause people to report more bugreports to mono team and implement the
lacking functionality.

> a stable platform. It just sounds like even more problems to start with.
> Lets fix the bugs we have now to make the platform actually stable
> before we add more craziness to it.

Ok, this is a valid argument. This is the place for core developers to
decide if they want more time on stabilization or jump into new
possibilities.

I would like to say once again, that switching to gmcs should not
cause any real issues, since mono already supports it.

>
> ~ chris
>
> On Sat, 2005-10-22 at 14:17 +0200, Kamil Skalski wrote:
> > As I mentioned in
> > http://lists.ximian.com/pipermail/monodevelop-list/2005-October/002564.html
> > I was able to compile and run monodevelop with gmcs and have plugins
> > and code completion up and running (including completion over generic
> > types).
> >
> > I am pretty sure that with a little bit more effort (compiling all
> > libraries like monodoc using gmcs and then compiling monodevelop
> > against them) it would be possible to switch monodevelop into 2.0 with
> > minimal changes in its sources.
> >
> > There are several problems there:
> > - by default many necessary mono libraries used by monodevelop are
> > compiled targetting 1.0 profile. Moreover, I don't see an easy
> > mechanism for fixing version numbers - for example there are gtk-sharp
> > and gtk-sharp-2.0, which conforms to version changes of Gtk and are
> > completely different story than .NET 1.1/2.0 versions... so the 2.0
> > profile for gtk would need to be named gtk-sharp2 and gtk-sharp2-2.0,
> > which is ugly. I guess we should bring this issue to the public
> > discussion (maybe also in mono-devel list)
> > - I still have no idea why starting monodevelop compiled with gmcs
> > takes sooooo much time (about 2 minutes)
> > - maybe we should not switch monodevelop to compile only against 2.0
> > version assemblies (so one could still use some 1.1 libraries when
> > developing monodevelop), but in this case the assemblyreferences
> > loading should be rethinked/redesigned/reimplemented.
> >
> > Besides those technical issues, I don't see any reason why monodevelop
> > should not be switched to 2.0 - mono supports it by default, so there
> > shouldn't be any dependency issues.
> >
> > 2005/10/22, Alejandro Serrano <trupill at yahoo.es>:
> > > John Luke escribió:
> > >
> > > >Hello,
> > > >On Fri, 2005-10-21 at 12:43 -0700, Christian Hergert wrote:
> > > >
> > > >
> > > >>We are not currently targeting the 2.0 runtime. Therefore, this will not
> > > >>work. You need to use 1.1 profile assemblies only.
> > > >>
> > > >>~ chris
> > > >>
> > > >>On Fri, 2005-10-21 at 15:49 +0200, Alejandro Serrano wrote:
> > > >>
> > > >>
> > > >>>Hi, I need to compile an add-in using the Generics C# Compiler (gmcs)
> > > >>>instead of normal mcs. My add-in is using generics methods from a
> > > >>>library, so I cannot just use mcs or change to it. My question is: can I
> > > >>>compile the add-in with gmcs and MonoDevelop will recognise it? My first
> > > >>>attempts were not successful, so I need some help.
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >A more sophisticated answer is that AddIns would have to be loaded in
> > > >seperate AppDomains for that to be possible.  Currently, MonoDevelop
> > > >loads all addins in one AppDomain. This is simpler and slightly better
> > > >performing.  There is a fairly good presentation from MS on the
> > > >tradeoffs of these type of things regarding AddIns among the PDC
> > > >presentations which I can't seem to find right now.
> > > >
> > > >So you will either have to wait for MD to switch to 2.0, or try to
> > > >compile it with gmcs and run it hacking around issues you notice.
> > > >
> > > >
> > > >
> > > >
> > > I've tried compiling all MonoDevelop with gmcs, but then it can't load
> > > any plug-in, I don't know why. At first, there was an error with an
> > > specific library load that I managed to resolve, but then any code
> > > completion or code colorizing works.
> > > However, I think MD should switch to the 2.0 runtime, because MD 1.0
> > > will sure target Mono 1.2, that already has generics support and so on,
> > > so everybody could benefit.
> > >
> > >
> > > ______________________________________________
> > > Renovamos el Correo Yahoo!
> > > Nuevos servicios, más seguridad
> > > http://correo.yahoo.es
> > > _______________________________________________
> > > Monodevelop-list mailing list
> > > Monodevelop-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> > >
> >
> >
> > --
> > Kamil Skalski
> > http://nazgul.omega.pl
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> >
>
>


--
Kamil Skalski
http://nazgul.omega.pl


More information about the Monodevelop-list mailing list