COM+/Enterprise Services Configuration

COM+ application components can be configured two ways. They can be configured to run as library applications (in-process) or as a Server application (out of process). Having a library component isn’t a problem since it is running with the application domain as the calling application. However, getting configuration settings into a Server application can be a challenge. So much so, that I typically recommend running a COM+ applications as a library application.

So why is configuration so difficult for server application? Well I’m glad you asked. It’s because the server application is running in a process called dllhost.exe. This process lives in the {Windows}\System32\ directory. The .NET framework “automagically” loads the configuration file named dllhost.exe.config to get the configuration settings as long as it is in the System32 directory. This works great until you have 2 Server components that need different configuration settings. Do you see the problem? 2 Processes – 1 Configuration file. Plus most IT departments freak out (with good reason) when you need to deploy a file to the System32 directory.

If you’ve read this far you’ll find the purpose for this post. I had a colleague send me a link that documents how to use the new options in COM+ 1.5 to use the application directory. This is the only time I’ve heard about using the application.manifest and the application.config files.

http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=0615b3cc-0fbf-4cf5-9d49-ae95b50f7e8d

 

Database Triggers Rant

The reasons I don't like database triggers:

1.) They are very difficult to debug
2.) They are a type of "magic" within a system. "Magic" is when something happens when I run code that I don't see in the code.
3.) They are not intuitive.

I find that database triggers get used in an organization when one or more of these things happen:
1.) A DBA has been tasked with writing application code
2.) The code is more difficult to change than it is to debug a database trigger
3.) The deployment process for code is significantly longer than the deployment process for SQL changes