We need to GAC the CSLA binaries and I'm having trouble figuring out how to GAC Csla light when there are two binaries names Csla.dll?
Have any of you had to do this? gacutil simply overwrites the last one in with the current one. I need BOTH binaries in the GAC for our development machines.
Thanks for any help,
Will
Can you even put the SL assembly in the GAC? There is no GAC concept in SL.
Well, I guess that was part of the question.
I know as far as the clients using the Silverlight that the GAC wasn't an option. What we were after is a way to handle our dependencies while developing.
I know that silverlight dlls can be added to the gac (I've added the cslalight dll to the gac just fine and it works). The problem is when I add the normal csla.dll to the gac it overwrites the cslalight (which makes sense because they are the same name and version). I was just thinking there was something special we had to do to get them in the gac side-by-side.
Looks like we might need to investigate another avenue, which you told me about a few months ago and that's recompiling csla 3.8.3 into an actual csla_3_8_3.dll and updating all the namespaces therein. Then update all of our code to use the 3.8.3 dll so that we can move forward with csla 4.0 libraries.
Breaking changes are very pianful. :(
Will
Rocky.
Does the csla assembly name matter? For instance, if I build as csla.dll and csla.silverlight.dll but leave all the internal namespaces the same, will it have any negative impact?
Thanks,
Will
The assembly names on client and server must match exactly for the data portal to work. That includes the signing key, assembly name, etc.
What is your motivation for putting the SL assemblies in the GAC? You aren't running them on the server, and the only real value of putting assemblies in the GAC is so they are loaded into physical memory exactly one time and are then shared across Windows processes and .NET AppDomains. That can never happen with an SL assembly, so I'm really struggling to see the value here.
I just wrote a quick test and it resulted in exactly what you said, if the assembly names don't match the objects won't work over the data portal. :(
It's an issue of versioning that we are facing. We have a rather large Csla 3.8.3 codebase with which Csla 4.0 is not backwards compatible.
So, we need a way to reference different versions of CSLA. It may all turn out to be moot as we are basing this effort on this assumption:
Given
BusinessLayerA -- Csla 3.8.3
BusinessLayerB -- Csla 4.0+
we assume WebApplicationC would be able to consume BusinessLayerA AND BusinessLayerB even though they depend on different versions of Csla.
Is this even a valid assumption? It was next in line for me to test and verify but maybe you already have a definitive answer?
If not, the entire point is moot and our ONLY real option would be to do whatever is necessary to make our existing codebase compatible with Csla 4.0+ (not a very palatable solution and would set us back MONTHS from using Csla 4 and the new stuff I've worked on with Blake over at CodeSmith). :(
Unless you have a better option?
We considered recompiling Csla 3.8.3 into a Csla_3_8_3.dll and updating all of our code to use that dll and new namespace but that effort would be very large and it's not something we want to even consider unless it is the ONLY option.
Thanks,
Will
I also just verified that compiling normal csla as version 4.1.0 and the silverlight as version 4.1.0.1 will not work. It compiles fine but upon execution throws an exception. :(
More sad by the hour.
Will
Copyright (c) Marimer LLC