1

My company currently runs a .net/sharepoint intranet and a ColdFusion public website. There is a lot of duplicated functionality and clumsy web service layers used to support the two platforms. Recently we have been exploring using .net classes in our ColdFusion front end which has shown a lot of promise.

There are a few issues related to managing the DLLs though. We are currently just loading the DLL from a directory on the server but it seems that once ColdFusion loads the DLL you can now longer overwrite the DLL without first stopping the Coldfusion .Net service. I noticed that ColdFusion also supports loading classes from the GAC.

For anyone who has gone down this route - how so you manage the DLLs that ColdFusion uses, specifically updating and deploying the DLLs? Should we use the assembly cache? Are there any other gotchas?

Nick Van Brunt
  • 15,244
  • 11
  • 66
  • 92

1 Answers1

2

I would strongly suggest GAC if possible, as long as you're developing the libraries yourself (which you are, thus the need to update them) so you can enforce strongly named assemblies and their dependencies etc.

If you're in control some of the drawbacks of GAC become positives, like the assembly running as it does with the compiled framework rather than the installed one. Removes the chance (even though its unlikely) that a .net framework upgrade is going to adversely affect your code.

Using the GAC is considered best practice to avoid DLL Hell (dependency hell).

http://en.wikipedia.org/wiki/DLL_hell

=)

Nate
  • 2,881
  • 1
  • 14
  • 14
  • How does it affect updating and deploying? – Leigh Jul 13 '11 at 16:53
  • GAC includes versioning information so cached copies shouldn't be an issue unless trying to redeploy an identical version (why?) - in which case you'll have to recycle the worker process. – Nate Jul 13 '11 at 17:05
  • 1
    Put another way, does using GAC help with his problem of overwriting, updating and deploying ".. without first stopping the Coldfusion .Net service" ? – Leigh Jul 13 '11 at 17:12
  • Yes :) ...and even if it didn't and you had to recycle the worker thread (shouldn't need to), it would still be considered a better solution than the nightmare that is DLL dependency. – Nate Jul 13 '11 at 17:20
  • So what exactly would happen if he tried to overwrite a dll that already existed? And in layman's terms, how does one "recycle the worker thread" :) Just trying to get a handle on the differences. – Leigh Jul 13 '11 at 17:25
  • overwrite- 1) you wont be able to because it will be locked or 2) cf will have cached it recyle- depends on the service, to find out where, use http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx - ex: if asp.net you would run iisreset :D – Nate Jul 13 '11 at 17:35
  • Okay, so it would not help with live updating, but may help with versioning? I will have to read up on this, because I did not think it was possible ;) – Leigh Jul 13 '11 at 17:52
  • No, I think it will help with the live updating - the versioning information being included makes it a new assembly, thus you aren't technically overwriting it but declaring a new one. ;) – Nate Jul 13 '11 at 17:54
  • You have done this before? I am still skeptical ;) ie How would CF know which one to use if the class names are still the same. – Leigh Jul 13 '11 at 18:07
  • Because with a GAC pointer, you include the versioning and key, you aren't pointing to a file.dll, you're instead telling the gac what you want, and it's there that the assembly is managed - "System.Windows.Forms, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" isn't going to pull the same assembly as version 1.0.5000.1 so it doesn't have the cf auto-gen-proxy issue :) – Nate Jul 13 '11 at 18:41
  • Yeah, I grok the idea of versioning. The hazy part was how do you say that from CF code :) (Anyway enough comments I guess, SO is starting to complain ... ;) – Leigh Jul 13 '11 at 19:13