GAC and CSLA.NET

What problem are you having adding Csla.dll to the GAC?

I recommend against the GAC in general. This is because I very much think you should only use a technology because you need its features. So you should only use the GAC because you specifically need something it gives you, and because you can live without the things it takes away.

The GAC takes away registry-free installation. To me that is a huge loss, not only for client apps, but also for server apps. No longer can you simply copy the dll to the target location and use it. Now you have to log into the machine and run a registration step. But for you this may be a non-issue, and you may feel no loss.

But even so, the GAC introduces complexity, and so should only be used if you need what it offers.

And what it offers, primarily, is that the dll will be loaded into physical RAM just once for the machine. This is only important if your dll is used by multiple processes on the machine. On a client, this only typically happens for the .NET runtime and for a handful of UI controls. On the server it can happen for your framework assemblies, but virtually never for app-specific assemblies, since they are per-virtual root and thus are per-process. So the GAC doesn’t offer its key value to most of the assemblies people create.

The GAC also offers COM-like versioning: the ability to force an application to upgrade to a newer assembly even if it hasn’t been tested against that assembly. To me this is not a positive: it brings the DLL Hell of COM into the .NET world. But to some, very small number, of organizations who had (and have) the iron discipline to make COM versioning actually work to their benefit, then this aspect of the GAC is a positive. But to the vast majority of organizations where DLL Hell was a very real, and very bad thing, this use of the GAC is most certainly a negative feature.

In short, for most organizations, the only value to the GAC is if they have a shared framework that is used across many processes (virtual roots on a web server), and where that assembly is physically large enough  that it actually matters to save RAM by loading it only once into physical memory.

Against that you must weigh the costs of loss of easy deployment, increased complexity and potential to re-engage COM-like versioning and DLL Hell.

The result, to my mind, is that the GAC is almost never of value to the vast majority of assemblies or applications.

Rocky

Hi!

My program includes two part: client and server(.Net Remoting). I want to share a value for many clients, data that flows from client to server and then from server back to client and “many other clients” that connected to server, changes on either end are carried across the network.

Do Global Context support?

Thanks.

No, nothing in Csla.ApplicationContext is designed to solve that problem.

You may consider using the ASP.NET Application object, assuming you have just a single application server.

If you have, or might have, a cluster of application servers though, the problem clearly becomes more complex because you need some way to share that value across all your servers. The obvious answer in that case is the database.

Rocky

If there’s a simple change like that, which wouldn’t require the use of the GAC, I will certainly consider putting into the official code.

I am curious what the problem is – why doesn’t it work as-is?

Rocky

 Not to argue, but I would doubt you are able to run CSLA 2.0 "bone stock" on the client side without a copy in the "bin" folder. Our mileages must truly be varying.

   I have a solution which involves a change to one line of code in a CSLA class that allows a true GAC reference on the client side to work. Nobody seems to want it but me, so I'll refrain from posting it unless requested.

   Thanks for giving me a place to soundboard this problem. The journey to a solution has been much less lonely being able to post here.