I recall thinking that would come up but for whatever reason I didn't deal with it in the original patch. I just pushed a version that should deal with that problem. The trick utilized is new to me, so if anyone has any better ideas I'm welcome to hear them.
http://github.com/patearl/Castle.Core/commit/c264dd7ecbf1ba3c39219563cd879fa29a6c1d29 Patrick Earl On Sun, Aug 29, 2010 at 4:15 PM, John Simons <[email protected]> wrote: > Hi Patrick, > > The idea is good, but at the moment you have hardcoded the loading of > System.Web to .Net 2.0, how about .Net 4.0? > > Cheers > John > > ________________________________ > From: Patrick Earl <[email protected]> > To: [email protected] > Sent: Mon, 30 August, 2010 7:41:16 AM > Subject: Castle.Core Client Profile Support > > Hi. > > Just to get some administrivia out of the way, I tried submitting a > pull request as detailed on this page: > > http://stw.castleproject.org/(S(su2mgm45fclhqe55veo40545))/How-to-submit-a-fix-to-any-Castle-Project.ashx > Unfortunately, no default recipients were checked and GitHub wouldn't > let me send it without one. Not being sure who to send it to, it's > coming here instead. > > I've created a changeset that allows Castle.Core to support the client > profile and full profile without forcing the distribution of two > separate versions. This has the following benefits. > > 1. Users don't need to be educated on the selection of one assembly or > another. > 2. Users don't need to create a more complicated build process that > selects between client / full for their own projects and libraries. > 3. Reduced complexity of build / distribution process for Castle.Core. > 4. Simplified compile checks (can leave client profile target > enabled) ensure that new code works with client profile. > 5. Other projects, such as NHibernate, don't need to decide upon or > distribute multiple versions to suite both profiles. > 6. The link between Castle.Core and System.Web is quite small > (WebLogger only depends on 6 properties / methods from 2 classes in > System.Web). > > It has the following drawbacks: > > 1. There is more code, though this is mitigated through the use of a > common tested reflection helper. > 2. There is a small performance penalty when using the WebLogger class. > > The code can be found on a fork here: > > http://github.com/patearl/Castle.Core/commit/654e268f27a3a110b34eca1e8047ab091c1929c6 > > Given the tremendous benefits and minor drawbacks of this approach, I > would highly recommend this code be applied. If there's anything I > can do to make this happen more smoothly, please let me know. > > -- > 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.
