Krzysztof, I may be wrong here, but I think the problem is not how many assemblies I have to reference in VS, the problem is how many assemblies I have to distribute with my app, and I totally agree, the less the better for desktop apps, and with MS pushing to use CP assemblies for Windows Forms + WPF development, this is the way it is going. For server applications such as web apps, I don't think (and I may be wrong here) that the same feeling is true.
Cheers John ________________________________ From: Krzysztof Koźmic <[email protected]> To: [email protected] Sent: Wed, 1 September, 2010 2:02:17 PM Subject: Re: Castle.ActiveRecord Client Profile Support > And regarding the number of referenced assemblies, is that really a big >problem? Yes it is for some people apparently. I got very positive feedback on merging Windsor assemblies from 4 to 2 and some people requested merging Core into Windsor so that we have just 1 assembly. I agree we should make it somehow more visible what is the target runtime of the assembly you're dealing with. Roelof - could we put this in the "File Description" or "Product Name" during the build, so that it would say: "Castle Windsor, .NET 4 Client Profile" not just "Castle Windsor" as it is now? cheers, Krzysztof 2010/9/1 John Simons <[email protected]> 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. > -- 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.
