Actually, I think we simplifying things even further. At the moment If I give u Castle.Core.dll, u have no idea if it is the full or the cp. (And I'm not even going to discuss if it is SL or not) This way there wouldn't be any confusion.
Also, the number of distributed assemblies will be exactly the same: 1x CP, 1x Web, 1xSL4 instead of 1xFull, 1x CP, 1xSL4. And regarding the number of referenced assemblies, is that really a big problem? Cheers John ________________________________ From: Jonathon Rossi <[email protected]> To: [email protected] Sent: Wed, 1 September, 2010 11:44:00 AM Subject: Re: Castle.ActiveRecord Client Profile Support If we split every assembly into two where it has dependences on the extended profile (even just for 1 class) then don't we complicate things more because people need to remember you need this other assembly with a few extra classes. Doesn't this also confuse the silverlight support every further, since the main DLL will usually have code that isn't supported on Silverlight; then WP7 will another with a subset of Silverlight. On Wed, Sep 1, 2010 at 11:22 AM, John Simons <[email protected]> wrote: I agree with Patrick on this one. >And the scenario Patrick describes is definitely problematic to solve without >separating the web functionality into another assembly. > >I'm also of the opinion that this should be done to Core + Windsor. > >Cheers >John > > > > ________________________________ From: Patrick Earl <[email protected]> > >To: [email protected] >Sent: Tue, 31 August, 2010 11:28:31 AM > >Subject: Re: Castle.ActiveRecord Client Profile Support > > >As an anecdotal note, I'm part of a multi-platform company that builds >both desktop and web applications based on AR. Desktop applications >have been the largest part of what we have produced, creating over 30 >AR desktop applications. We've been using AR, but we have to maintain >our own custom version to support the client profile. Surely other >people have the same issue. This wouldn't be such a large concern, >but we have a modelling product that we wish to generate AR models >for. When providing users with libraries to use with the modeller, it >would be better if we could point them to the untouched libraries for >use within either scenario. > >AR / NHibernate traditionally haven't focused much on usability in the >rich client world, and have stronger web capabilities. Because there >is a barrier to adoption in the client world, the level of adoption >naturally goes down. This will be even more of an issue now that >VS2010 defaults many project types to the client profile. While I >don't really agree with Microsoft's decisions around the client >profile, they have made it an important force in the .NET world. >Windows machines on automatic updates will only install the .NET 4 >client profile automatically. For people that wish to distribute apps >to a wide audience, it's a significant concern. > >Regarding the IFDEF solution, consider if you have a library such as >Common.DB that links with ActiveRecord. Are there good strategies >available for dealing with situations where both web apps and client >apps wish to utilize Common.DB? > >AR basically uses the web portion for linking sessions, but it's >certainly very useful without the web. In fact in our usage of AR we >have never even utilized the built-in web classes, not even when we're >using it with web sites (we have our own scope system for rich client >apps that we also use on the web). > >Hope that didn't sound too much like a rant. :) > > Patrick Earl > >2010/8/30 Henry Conceição <[email protected]>: >> About the split: I think that doesn't makes sense. AR is mostly used >> on web applications, and doing this split would be a useless breaking >> change to the majority of our users. >> >> Maybe an ifdef (excluding the non supported classes/features) can do the >>tricky. >> >> Cheers, >> Henry Conceição >> >> >> >> On Mon, Aug 30, 2010 at 9:19 AM, Michael Maddox >> <[email protected]> wrote: >>> I'd like to see Option 1 happen (split non-client profile code off >>> into Castle.ActiveRecord.Extended). >>> >>> Option 2 feels like it would cause confusion for users. >>> >>> Michael Ketting's blog post mentioned by Fabian seems more like a >>> workaround after the fact than a fundamental solution. It's a useful >>> workaround, but I wouldn't want to encourage it's use when better >>> options are available. >>> >>> -Michael Maddox >>> http://www.capprime.com/software_development_weblog/ >>> >>> On Mon, Aug 30, 2010 at 1:47 AM, Patrick Earl <[email protected]> wrote: >>>> Hi all. >>>> >>>> With NHibernate now supporting the client profile, I'd like to see >>>> client profile support for Castle.ActiveRecord. Unfortunately, as far >>>> as I can see, there's no easy way to do it. SessionScopeWebModule is >>>> an IHttpModule and people configure it by providing the qualified >>>> class name in the httpModule section of the config file. I don't see >>>> how to fix that without moving SessionScopeWebModule to a separate >>>> assembly or using compilation directives. For comparison, NLog has >>>> gone through a similar process and split the web components into a >>>> NLog.Extended to match the split between the client and extended >>>> frameworks. I'd like to suggest a couple possibilities. >>>> >>>> 1. Split off at least SessionScopeWebModule (and potentially other >>>> web things) into a Castle.ActiveRecord.Extended (or >>>> Castle.ActiveRecord.Web) assembly. This would be a breaking change >>>> requiring certain web users to add a reference to the new project. >>>> 2. Use #ifdefs and distribute two different versions of the >>>> Castle.ActiveRecord assembly. One for web, one for not. >>>> >>>> My personal preference is #1, since it is a one time change, even if >>>> it's a breaking change. The second one causes all sorts of >>>> distribution / build headaches as mentioned in my other message >>>> pertaining to Castle.Core. >>>> >>>> What are people's thoughts on this? >>>> >>>> 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]. >>>> 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]. >>> 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]. >> 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]. >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]. >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. -- 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.
