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 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 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 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 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.
