When I compile the CSLA 4.0 source I now see Client, Server and Silverlight folders each of which contain Csla.dll. I'm confused about the addition of the new folder, previously we only had Silverlight vs non-Silverlight builds. I suspect this is related the the .Net 4 Client Profile build target?
Speaking of the CLient Profile target, is there any negative side-effect of me targeting the normal .net 4 target as opposed to the Client Profile?
A brief explanation of what's going on here would be extremely helpful. Sorry if I missed an existing document somewhere. I've looked around and don't see much on this topic other than the version change log.
Thanks!
Will
There are actually only two Csla.dll versions:
However, the Csla.Web and Csla.Web.Mvc projects make use of core Csla.dll, so that assembly gets copied into the Server folder when you build, and I don't know of any way to suppress that behavior.
When you run the installer (instead of building the source yourself), you should find that (at least in the Release folders) the Server folder doesn't contain Csla.dll.
You can target the client profile or full profile in your app as you choose. For smart client apps (WPF and Windows Forms) you should probably target the client profile, since that reduces the amount of stuff a user would have to install to use your app. Why should you force them to install ASP.NET on their client workstation?
For server-side apps (ASP.NET, etc), the full profile is required.
As we go down this path we are running into more questions that we have trouble answering. We have an existing large code base generated against CSLA 3.6. Now we want to use CSLA 4.0 in some new applications. We thought about using the GAC to help control the versioning issues but we don't really like the idea of usign the GAC because we want developers to be able to pull projects from source control and have them come with all binaries required to build. No need to manually install missing assemblies tot he GAC.
Currently, we use a Dependencies folder for all 3rd party dlls and all of our applications reference from that folder. This obviously won't work for us now with CSLA because we need to maintain different versions of CSLA to support old apps that we do not have time to update.
However, we have an issue.
Application 1 References Business Layers A B and C all of which are built around CSLA 3.6.
Application 2 References Business Layers C D and E all of which will be built around CSLA 4.0.
The problem is, if we upadte C to use 4.0 then it breaks Application 1 because doing so would mean application 1 requires a reference to CSLA 4.0 which is not in our scope. What are you guys doing to manage scenarios like this?
Is the GAC our only option and if so, how does the GAC work with the Silverlight/Normal versions of CSLA that we will need since both are named Csla.dll?
One idea I have to to simply start building CSLA into assemblies that contain the version name. So we would have Csla_4_0_0.dll and continue this scheme going forward. I'm sure though that there is a better option. Hopefully you guys can help.
Thanks again,
Will
Normally .NET uses a folder-based referencing scheme, unless you override that with the GAC.
So when you build your app, all required (non-GAC) assemblies are put into your app's execution folder. For a web app this is the \bin folder, for a smart client app it is the folder where your EXE resides.
The idea is that, at runtime, your app is self-contained by referencing only things that are in its execution folder - other than the .NET runtime itself which comes from the GAC.
Why won't that work for you?
Is it because of development-time choices you've made in terms of managing dependent assemblies?
If so, I'd recommend addressing the dev-time issue rather than complicating the runtime deployment story.
It is very much a development time concern.
Large application called Hps.Servicing (.NET 3 and CSLA 3.6) references Hps.Business.Security (.NET 3 and CSLA 3.6).
New Application called Hps.MerchantCenter is built on .NET 4 and CSLA 4 and requires Hps.Business.Security.
Now, if we upgrade Hps.Business.Security we will break Hps.Servicing (which we don't have time for). Or we can't use Hps.Business.Security (which we don't have time for).
It's a fun dilema.
How are you planning to address this at even the .NET level? If you upgrade the Security module to .NET 4 you can't use it in .NET 3? It seems to me like you need to have two versions of the Security model - one for .NET 3 and one for .NET 4?
Then you have the CSLA issue, because in the .NET 4 build of the Security module you want to keep using CSLA 3.x, while the rest of the .NET 4 app uses CSLA 4.
That isn't quite so hard to solve in an interim basis. People solved this when moving from CSLA 1.x to 2.x.
During the migration period change one version (in your case probably the new version) to have a different name and namespace. Like Csla4.dll and Csla4 as the namespace root.
That will allow you to reference both versions of CSLA within the same AppDomain.
It will be somewhat painful during the transition period, because you'll have to re-apply the namespace change to the complete CSLA solution each time you grab newer code from www.lhotka.net...
The other alternative is to do the rename to the 3.6 code, which you won't have to upgrade because 3.6 won't be changing. That'd affect your entire existing codebase though. It would be a one-time change, but might be a big hit?
That actually would probably work out very well. It would just be a matter of updating old project references.
Thanks Rocky, this helps a lot!
Will
Copyright (c) Marimer LLC