We already have the client profile build option which is currently being used for Core and Windsor. Both Core and Windsor have green builds that are conditionally compiled.
On Wed, Sep 1, 2010 at 4:01 PM, Markus Zywitza <[email protected]>wrote: > My opinion is that we should have a seperate build for client profile. > I'm not enough into MSBuild to change the current build configuration, > but I'd expect to have less impact when we are using #if > CLIENT_PROFILE or something similar. > CAR already suffers from being split into a number of assemblies > (incl. NH etc.), we don't need to add another one to the bunch. If the > number of #if blocks are small (and I think there will be only one) > this is perfectly bearable. > Patrick, would you go and make the changes if Roelof can add a client > profile build option? > > -Markus > > 2010/9/1 Jonathon Rossi <[email protected]>: > > With that said Patrick. Would you expect that we would have a > > Castle.ActiveRecord.Web.dll or Castle.ActiveRecord.AspNet.dll and if for > > some reason we had WinForms specific code it would go in > > Castle.ActiveRecord.WinForms.dll? The same thing would happen with > log4net > > (log4net.dll, log4net.Web.dll/log4net.AspNet.dll). > > > > Your points are making things a little clearer now if you categorise > ASP.NET > > as a non-essential optional .NET component. > > > > On Wed, Sep 1, 2010 at 3:12 PM, Patrick Earl <[email protected]> > wrote: > >> > >> Speaking from an entirely different perspective, in applications > >> there's a logical split between the presentation layer and the > >> backend. Clearly Core and ActiveRecord are firmly in the backend > >> space. Excluding Silverlight, the built-in .NET presentation layers > >> are WinForms, WPF, ASP.NET, and MVC. I don't think people would be > >> very happy about including references to System.Windows.Forms, > >> PresentationFramework, or even System.Web.Mvc. ASP.NET support came > >> along first, but what makes it any different from the other > >> presentation layers? Clearly Microsoft thinks it's not part of the > >> core .NET functionality. Though it has a history, it does seem a bit > >> odd that the Castle framework core should need to be tied to a > >> particular presentation layer, via non-essential classes. > >> > >> Patrick Earl > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Castle Project Development List" group. > >> To post to this group, send email to > >> [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<castle-project-devel%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/castle-project-devel?hl=en. > >> > > > > > > > > -- > > Jono > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Castle Project Development List" group. > > To post to this group, send email to > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<castle-project-devel%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/castle-project-devel?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- Jono -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
