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