On Sun, Aug 9, 2009 at 9:38 PM, Andreas Nahr <classdevelopm...@a-softtech.com> wrote: > > > Unfortunately that leaves you with no option of avoiding aspnet pulling > > winforms through System.Design. :( > > > And unfortunately, there seems to be no good way to split up the > > mono-web (ASP.NET) package, as the System.Web assembly seems to have > > quite a few responsibilities. > > Well all the Designer Stuff in the *Design assemblies is dynamically binding > at runtime. > So from a purely technical point of view there is no problem in not shipping > the System.Design.dll or something like that with an application that uses > anything from System.Web. > Everything will work as long as you are not using any of the Design stuff > (or using anything that uses the Design stuff). In fact it *should* even > "work" when using the Design stuff, it just won't work the same way as > originally expected. > Afaik currently most of the Web stuff in System.Design is only stubbed out > anyways, so the difference between shipping it or not should (in most cases) > be minimal for *web* applications. >
Nevertheless if mono-web does not include System.Design then it basically beaks MS.NET compatibility. Because then the user will have to know "Oh wait. There is mono-designtime I also have to install". And the worse is that those problems will be very very difficult to track down (missing dynamic dependency). So instead of breaking the out of the box experience so to speak, what about creating a mono-web-lite package without the System.Design/winforms dependency (= don't install System.Design)? That way apps that don't have any direct or indirect deps on System.Design (e.g. Tomboy) can put a dependency on mono-web-lite instead of on mono-web. An idea I just had. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list