Cslalight - CslaDataProvider : ObjectType property that references your CSLA Objects

Jaans posted on Monday, June 15, 2009

I had read somewhere before (and now unable to find the original reference) about being able to specify a reference to your object without all the version and public key information.

This feature is very usefull if your version number changes regularly (like after a daily build). With the Silverlight CslaDataProvider you would then need to update those references everytime your business object assembly version numbers change.

This would be similar to the CslaDataSource for ASP.NET web applications where a strong named Csla Business Object reference could be specified without the Versioning and Public key bits, allowing the reference to remain intact eventhough the version number has since changed.

I'm not sure whether this is still to be done, or has already been implemented (in which case I'm not having any joy on 3.6.2).

RockfordLhotka replied on Wednesday, June 17, 2009

I am pretty sure that change was done in 3.6.2 or maybe 3.6.1.

You still need to provide the assembly name:

"Namespace.Class, Assembly"

I changed the type resolver used by everything in CSLA .NET for Silverlight, so anywhere you specify an assembly it should work.

Please note that this only works if the culture/version/key are neutral. If your assembly is signed then I can't help you, because the actual Silverlight type system does require all the information. So all I'm doing is appending the neutral values if you don't provide specific ones.

In other words, I think you are out of luck.

Jaans replied on Wednesday, June 17, 2009

Aaah! That must it it then - all our assemblies are signed.

Thanks Rocky.

It is a pity, since it works so well with the CslaDataSource in ASP.NET.

Just for my understanding, is it a feature of the type resolver that isn't available in Silverlight that prevents us here?

Regards,
Jaans

RockfordLhotka replied on Thursday, June 18, 2009

Jaans replied on Thursday, June 18, 2009

Thanks... that makes sense.

For us it was more important to have versioning information available on our assemblies since we perform regular updates and have multiple clients on different versions.

I tried a couple of things and came to a technique that will work for our scenario. I thought I would post the idea, should anyone else have the need for it.

Disclaimer: It's slightly convoluted

The general idea is to upon application startup have code modify the ObjectType property of the CslaDataProviders and replace the version number with the one that you need.

Super important note: The version number of the server-side business assembly must match the one used for the client-side silverlight business assembly. This is a requirement outside of this implementation (if you are using versioning).

Given that above version number synchonicity, there are severeal ways you could determine the version number you are to use when programmatically updating the ObjectType property:

1) Have the ASP.NET Server determine it dynamically since you have the full reflection capability available there. Then pass that version information as the InitParameters for the Silverlight application. Then on the client side, in the application startup event you can extract that information and update the ObjectType property of your providers.

2) Hardcode it. Consider using a shared/linked file that specifies the version number so you only specify it once (this is what we do).

3) Synchonize the Silverlight application version number also. In other words, the server-side business assembly, the client-side business assembly and the client-side silverlight application have the same version number. Then you can extract that version number information from the executing assembly (ps. there is a way to get it without using security critical code) and take it from there.

Hope that helps,
Jaans