Castle.ActiveRecord Client Profile Support
Patrick Earl
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
Fabian Schmied
Just one quick thought: even until one of the two options is
implemented, applications using ActiveRecord can still run on the
Client Framework, as long as they don't actually make use of any
unsupported APIs (eg. the SessionScopeWebModule). A colleague of mine
wrote about this in his blog:
"https://www.re-motion.org/blogs/reflections/archive/2010/08/11/107.aspx".
The trick is to not compile the application for the Client Profile
(otherwise you'll get a compiler error), but instead manually specify
a config file that enables Client Profile support.
Fabian
> --
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
>
>
Michael Maddox
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/
Henry Conceição
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
John Simons
Cheers
John
From: Henry Conceição <henry.c...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Tue, 31 August, 2010 8:13:10 AM
Subject: Re: Castle.ActiveRecord Client Profile Support
>> 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 castle-pro...@googlegroups.com.
> 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 castle-pro...@googlegroups.com.
Patrick Earl
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 <henry.c...@gmail.com>:
John Simons
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 <pat...@patearl.net>
To: castle-pro...@googlegroups.com
Sent: Tue, 31 August, 2010 11:28:31 AM
Subject: Re: Castle.ActiveRecord Client Profile Support
>>> 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 castle-pro...@googlegroups.com.
>> 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 castle-pro...@googlegroups.com.
> 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 castle-pro...@googlegroups.com.
Krzysztof Koźmic
why maintain custom version instead of contributing back your changes?
It's open source - we accept patches, and actually we, means you too :)
I'm divided between the two approaches.
On one hand we specifically migrated from having 4 assemblies for Windsor to having 2, and we maintain two versions - for CP and full .NET
if we were to separate CP assemblies out, we'd end up having 4 of them again.
On the other hand I can see your point and that's what most other projects seems to be doing...
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
Jonathon Rossi
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.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
--
Jono
John Simons
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 <jo...@jonorossi.com>
To: castle-pro...@googlegroups.com
Sent: Wed, 1 September, 2010 11:44:00 AM
Krzysztof Koźmic
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
Patrick Earl
fork I mentioned in a previous message. It obviates the need for more
than a single assembly while still providing support for both the
client and extended frameworks. It would bring Castle.Core back to
just one assembly for .NET and one for Silverlight.
http://github.com/patearl/Castle.Core
I wish we could do the same with ActiveRecord, but I believe the only
thing preventing that is that SessionScopeWebModule is accessed
directly through the config file without a chance to intercept it for
runtime redirection.
Patrick
Patrick Earl
there's a logical split between the presentation layer and the
backend. Clearly Core and ActiveRecord are firmly in the backend
space. Excluding Silverlight, the built-in .NET presentation layers
are WinForms, WPF, ASP.NET, and MVC. I don't think people would be
very happy about including references to System.Windows.Forms,
PresentationFramework, or even System.Web.Mvc. ASP.NET support came
along first, but what makes it any different from the other
presentation layers? Clearly Microsoft thinks it's not part of the
core .NET functionality. Though it has a history, it does seem a bit
odd that the Castle framework core should need to be tied to a
particular presentation layer, via non-essential classes.
Patrick Earl
Jonathon Rossi
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?
Jono
Jonathon Rossi
Your points are making things a little clearer now if you categorise ASP.NET as a non-essential optional .NET component.
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
--
Jono
Markus Zywitza
I'm not enough into MSBuild to change the current build configuration,
but I'd expect to have less impact when we are using #if
CLIENT_PROFILE or something similar.
CAR already suffers from being split into a number of assemblies
(incl. NH etc.), we don't need to add another one to the bunch. If the
number of #if blocks are small (and I think there will be only one)
this is perfectly bearable.
Patrick, would you go and make the changes if Roelof can add a client
profile build option?
-Markus
2010/9/1 Jonathon Rossi <jo...@jonorossi.com>:
Jonathon Rossi
Patrick Earl
Castle.Logging.Services.NLogIntegration and
Castle.Logging.Services.log4netIntegration (since not everyone wants
to use log4net or NLog), for the sake of argument does it not also
make sense to have Castle.Logging.Services.WebIntegration (since not
everyone wants that either)? Though there was no split originally,
there is now a division and I believe Web should be treated as any
other component which people don't necessarily have.
To be clear, I am also willing to do the work to split AR into two
distributions. At least there would be official versions to point
people to, even if they are inconvenient to utilize. For our company,
since we use both the client profile and web with shared libraries, we
will continue to internally patch the ActiveRecord source as we have
always done. We don't want to have the added expense of coming up
with a system to use one dependency chain for one project and another
dependency chain for another.
For example, doing this is not easily supported by VS:
[The arrow indicates a reference. The indentation of the arrow shows
which project is referencing the dependency.]
WpfApp
-> Common.Database.Wpf
-> Common.Database (client)
-> ActiveRecord (client)
WebApp
-> Common.Database.Web
-> Common.Database (client + extended)
-> ActiveRecord (client + extended)
But, doing this is:
WpfApp
-> Common.Database.Wpf
-> Common.Database
-> ActiveRecord
WebApp
-> Common.Database.Web
-> Common.Database
-> ActiveRecord
-> ActiveRecord.Web
Believe it or not, I do generally expect assembly divisions along
major framework alternatives. If you're building a web application,
it's pretty easy to include assemblies related to web stuff. It's
easy to understand that I don't need the WPF or WinForms assemblies
also. It may seem like a proliferation of assemblies, but when the
developer has to pick them, they pick one line that matches their
requirements. For example, I want to use NLog in a WPF app. I pick
the cores, then pick assemblies that are related to NLog and WPF.
Usually frameworks don't need to split too many ways since they're
usually working in one area or another. For example, NLog only split
on Web vs Core.
This pattern of "core assembly + integration assemblies" is very
common. Take these examples:
Castle.Core + (Castle.Logging.Services.Log4NetIntegration,
Castle.Logging.Services.NLogIntegration)
NLog + (NLog.Extended)
NHibernate + (NHibernate.ByteCode.*)
Granted, when additional assemblies can be avoided using relflection,
this is often an easier approach. Sadly, there is one class in AR
that doesn't allow for that. The good news though is that Castle.Core
can provide the best of all worlds, at least simplifying the
distribution of things like NHibernate.ByteCode.Castle.
Patrick Earl
John Simons
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 <krzyszto...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Wed, 1 September, 2010 2:02:17 PM
Krzysztof Koźmic
So now you distribute 1, with proposed model It's more
sent from my HTC Desire
On 01/09/2010 7:32 PM, "John Simons" <johnsi...@yahoo.com.au> wrote:
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 <krzyszto...@gmail.com>Sent: Wed, 1 September, 2010 2:02:17 PM
To: castle-pro...@googlegroups.com
Subject: Re: Castle.ActiveRecord Client Profile Support
> And regarding the number of referenced assemblies, is that really a big problem?
Yes it is for s...
--You received this message because you are subscribed to the Google Groups "Castle Project Developmen...
--
You received this message because you are subscribed to the Google Groups "Castle Project Deve...
John Simons
Cheers
John
Subject: Re: Castle.ActiveRecord Client Profile Support
So now you distribute 1, with proposed model It's more
sent from my HTC Desire
On 01/09/2010 7:32 PM, "John Simons" <johnsi...@yahoo.com.au> wrote:--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 <krzyszto...@gmail.com>Sent: Wed, 1 September, 2010 2:02:17 PM
To: castle-pro...@googlegroups.com
Subject: Re: Castle.ActiveRecord Client Profile Support--
> And regarding the number of referenced assemblies, is that really a big problem?
Yes it is for s...You received this message because you are subscribed to the Google Groups "Castle Project Developmen...
--
You received this message because you are subscribed to the Google Groups "Castle Project Deve...
Krzysztof Koźmic
Not what?
sent from my HTC Desire
On 01/09/2010 7:40 PM, "John Simons" <johnsi...@yahoo.com.au> wrote:
Not for desktop apps.
Cheers
John
________________________________
From: Krzysztof Koźmic <krzyszto...@gmail.com>
To: castle-proj...
Sent: Wed, 1 September, 2010 7:34:40 PM
Subject: Re: Castle.ActiveRecord Client Profile Support
So now you distribute 1, with proposed model It's more
sent from my HTC Desire
>
> On 01/09/2010 7...
You received this message because you are subscribed to the Google Groups "Castle Project Developmen...
John Simons
Cheers
John
Subject: Re: Castle.ActiveRecord Client Profile Support
Not what?
sent from my HTC Desire
On 01/09/2010 7:40 PM, "John Simons" <johnsi...@yahoo.com.au> wrote:--Not for desktop apps.
Cheers
John________________________________
Sent: Wed, 1 September, 2010 7:34:40 PM
From: Krzysztof Koźmic <krzyszto...@gmail.com>
To: castle-proj...
Subject: Re: Castle.ActiveRecord Client Profile Support
So now you distribute 1, with proposed model It's more
sent from my HTC Desire
>
> On 01/09/2010 7...You received this message because you are subscribed to the Google Groups "Castle Project Developmen...
--
You received this message because you are subscribed to the Google Groups "Castle Project Deve...
Krzysztof Koźmic
I fail to see the benefit of the split over having just a targeted cp version
sent from my HTC Desire
On 01/09/2010 7:44 PM, "John Simons" <johnsi...@yahoo.com.au> wrote:
For desktop applications (Windows Forms + wpf) the number of assemblies would be exactly the same as now, 1.
Cheers
John
________________________________
To: castle-pro...@googlegroups.com
From: Krzysztof Koźmic <krzyszto...@gmail.com>
Sent: Wed, 1 September, 2010 7:41:16 PM
Subject: Re: Castle.ActiveRecord Client Profile Support
Not what?
sent from my HTC Desire
>
> On 01/09/2010 7:40 PM, "John Simons" <johnsi...@yahoo.co...
--You received this message because you are subscribed to the Google Groups "Castle Project Developmen...
Michael Maddox
Make it as easy as possible for the ignorant user to be successful.
John Simons
Cheers, John
Krzysztof Koźmic
You use client profile version if you have cp- client app, and you use full version on the server.
What's to support?
Krzysztof Koźmic
I'm -1 for this idea, I agree with Markus.
On 1/09/2010 9:26 PM, John Simons wrote:
Henry Conceição
I'm -1 for this too.
Cheers,
Henry Conceição
Patrick Earl
1. To make a web app, users need to:
Reference ActiveRecord, using the client+extended build (is a
separate download or are there just many folders?).
2. To make a desktop app, users need to:
Reference ActiveRecord, using the client build.
3. Using in a common library, users need to:
Somehow the common library needs to reference the right version.
Perhaps I need to add new configurations to the solution such
as Debug-Client and Release-Client and then manually edit the project
files to use $(Configuration) in the hint paths. Maybe I need to use
some sort of IF logic. I do know it was problematic when we had
SQLite set up with different references based on the configuration.
I'm totally open to suggestions as to how to handle this... I
genuinely don't really know how to do this properly.
Assuming a split between client and extended:
1. To make a web app, users need to:
Reference ActiveRecord.
Reference ActiveRecord.Web.
2. To make a client app, users need to:
Reference ActiveRecord.
3. To make a common library, users need to:
Reference ActiveRecord
It seems to me that training users to manage multiple builds of the
same library is more complicated than having them add an extra
assembly required for some particular piece of functionality.
Patrick Earl
Roelof Blom
so it includes the framework it was built for in the assemblyinfo,
just like in the NAnt days.
I am on holiday and have a barely functioning net connection at best
over here at our italian campsite, so could be a while before i push.
-- Roelof
2010/9/1, Jonathon Rossi <jo...@jonorossi.com>:
> --
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
--
Verzonden vanaf mijn mobiele apparaat
Krzysztof Koźmic
cheers - have an awesome time :)
K
Roelof Blom
It's already done for Core, now I only need to drive around Tuscany to
find an inexpensive uplink :-)
2010/9/2, Krzysztof Koźmic <krzyszto...@gmail.com>:
>> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/castle-project-devel?hl=en.
>> >
>> >
>>
>> --
>> Verzonden vanaf mijn mobiele apparaat
>>
>> --
>> 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 castle-pro...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>
Krzysztof Koźmic
Markus Zywitza
Have a nice holiday and don't even think about commiting anything
while on vacation.
-Markus
2010/9/2 Roelof Blom <roelo...@gmail.com>:
Roelof Blom
on a campsite holiday, in a luxurous kind of mobile home with all
facilities buth internet access ;-)
I've committed and managed to hijack an internet connection so even
pushed my changes... I'll try and not do that again.
-- Roelof
2010/9/2, Markus Zywitza <markus....@gmail.com>:
Patrick Earl
can be supported with just a single assembly and one breaking change.
The breaking change would be that users would need to change this:
<system.web>
<httpModules>
<add
name="ar.sessionscope"
type="Castle.ActiveRecord.Framework.SessionScopeWebModule,
Castle.ActiveRecord" />
</httpModules>
</system.web>
Into this:
public class Global : System.Web.HttpApplication
{
public override void Init()
{
base.Init();
SessionScopeWebModule.Init(this);
}
}
Internally, the web module class would be generated at runtime through
IL emission. Is anyone aware of any showstoppers with this approach?
Is anyone aware of issues with medium trust, signing, or anything like
that?
Does this technique appeal to people more than the last two?
Patrick Earl
Patrick Earl
classes is not allowed in medium trust.
I think I'll just go into a corner and sulk now. :(
Sadtrick Earl
Krzysztof Koźmic
DynamicProxy does work in medium trust from what I understand...
Patrick Earl
a blog post of interest on the topic:
http://blogs.taiga.nl/martijn/2009/06/24/new-adventures-under-medium-trust/
So then, back to my original question. What do people think of this
new approach for maintaining a single assembly for client and full?
Patrick Earl
2010/9/3 Krzysztof Koźmic <krzyszto...@gmail.com>:
Jonathon Rossi
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
--
Jono
Patrick Earl
only a thin IHttpModule wrapper. The rest of the code can remain
largely the same with a few calls changed as demonstrated in this
changeset:
http://github.com/patearl/Castle.Core/commit/654e268f27a3a110b34eca1e8047ab091c1929c6
Standard debugger functionality would be available for everything
except an intentionally small wrapper class that implements
IHttpModule.
Patrick Earl
Patrick Earl
System.Web is HttpContext.Current.Items. The integration surface is
very small.
Patrick Earl
Jonathon Rossi
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 castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
--
Jono