Hi,
I am struggling a bit with CSLA configuration and deployment and was hoping someone might be able to help. So here's what I've got.
How can I set things up so that I can use both sets of objects in my application, both using different versions of CSLA and both using different data portal settings??
Many apologies if this has been asked (and answered) elsewhere... I've had a good scout around and couldn't find anything relevant.
Any help would be greatly appreciated!!
Thank you very much,
James
Well... I can answer one question...
I have multiple objects that some run remote and some run local. I have a base object in my library that is setup as Run Remote and then I have to have every BO that runs local override the DataPortal_XXX methods and mark them as RunLocal.
At least that is what I am doing...
For Multi-Configs... i actually had to create our own config file which at app startup would change the web.config file settings to what we have in our custom config file using the System.Configuration.OpenExeConf... (something like that) method; change the CSLA setting; then saving it.
Not sure if that is the best way... but works great and give a lot flexibilty to changing the Web.Config file CSLA Remoting Tags to what you want them to be... (based on what objects are using it).
Hope that helps, ward0093
Hi Ward0093!
Thanks for the swift reply!
ward0093:
Well... I can answer one question...
I have multiple objects that some run remote and some run local. I have a base object in my library that is setup as Run Remote and then I have to have every BO that runs local override the DataPortal_XXX methods and mark them as RunLocal.
At least that is what I am doing...
Sounds good for now, and I can see it'll work... but I'm then forcing my objects to always be local and can never take advantage of their portability!!! Also, I can see a day very soon when I've got to write some more objects that have to reside on a totally application server (for yet more security reasons).
For Multi-Configs... i actually had to create our own config file which at app startup would change the web.config file settings to what we have in our custom config file using the System.Configuration.OpenExeConf... (something like that) method; change the CSLA setting; then saving it.
Not sure if that is the best way... but works great and give a lot flexibilty to changing the Web.Config file CSLA Remoting Tags to what you want them to be... (based on what objects are using it).
I can see how this works for a "one-off" call at start up, but not how it applies to multiple business objects that you are using constantly at runtime!! So do you change the web.config "on the fly" in your business object then??
I'm looking at an option that involves amending the framework slightly. Not sure if this is a good idea though and it might make more headaches for me as I would have to integrate them into every update that Rocky supplies!! Anyway, here's my idea...
I've created a class called CslaDataPortalConfigPrefixAttribute which takes a string parameter. I can then apply this attribute to all my business object classes. I've then modified Csla/DataPortal/ApplicationContext.vb so that DataPortalProxy and DataPortalUrl are no longer properties but functions which take a type parameter, namely the type of the business object.
These functions then (through a helper) check to see if the type has a CslaDataPortalConfigPrefixAttribute applied to it (or any of its parents). If so, it uses the prefix to build up the key for using in the application settings call.
I've then modified Csla/DataPortal/Client/DataPortal.vb, Csla/DataPortal/Client/RemotingProxy.vb and Csla/DataPortal/Client/WebServicesProxy.vb so that the appropriate types are passed through to ApplicationContext.vb.
I can now add keys as follows:
<
add key="CslaDataPortalProxy" value="Csla.DataPortalClient.RemotingProxy, Csla"/>I've given this a whirl and it seems to work well and gives me pretty much everything I want. It also seems like quite an elegant solution, but I'm worried about future upgrades!!
Any thoughts??
Thanks,
James
Thanks for the link xal... certainly is interesting stuff.
The more I look at my problem, the deeper it seems to get. I just can't work out how to have 2 versions of CSLA running side-by-side in the same app. Even with the techniques I've found, and with those in the article I still can't get it to work with different versions of CSLA.
The only option I can come up with is putting the different versions of CSLA in the GAC.
Hmmm!!!
I'm looking at an option that involves amending the framework slightly. Not sure if this is a good idea though and it might make more headaches for me as I would have to integrate them into every update that Rocky supplies!! Anyway, here's my idea...
I've created a class called CslaDataPortalConfigPrefixAttribute which takes a string parameter. I can then apply this attribute to all my business object classes. I've then modified Csla/DataPortal/ApplicationContext.vb so that DataPortalProxy and DataPortalUrl are no longer properties but functions which take a type parameter, namely the type of the business object.
These functions then (through a helper) check to see if the type has a CslaDataPortalConfigPrefixAttribute applied to it (or any of its parents). If so, it uses the prefix to build up the key for using in the application settings call.
I've then modified Csla/DataPortal/Client/DataPortal.vb, Csla/DataPortal/Client/RemotingProxy.vb and Csla/DataPortal/Client/WebServicesProxy.vb so that the appropriate types are passed through to ApplicationContext.vb.
The simpler solution is to create your own custom data portal proxy that reads your config/context and routes the call to one of the exisint proxy objects. That way you don't need to alter CSLA at all.
You can look at Chapter 4 to see how a data portal proxy is created, and there are some others on the forum that have done similar things.
Copyright (c) Marimer LLC