I wrote a COM object in c# (a class library that is registered for COM interop), which compiles to a .dll.
I wanted the object to be able to read items from an app.config file (e.g. PmsInterfaceComObject.dll.config). Trouble is, COM interop dll files seem to be hosted by an Application Pool, or other type of .Net executable. Because of this, the configuration provider wants to use the host .Net executable's config file for settings. Not the COM dll's config file.
This is a known issue, this article describes the situation nicely.
I found a way to override the location of the config file at this site. I added some of my own code to discover the location of the running .dll. Here is the result:
AppConfigFilePath = Path
.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase)
.Replace("file:\\", string.Empty)
+ "\\" + Path.GetFileName(Assembly.GetExecutingAssembly().CodeBase) + ".config";
// Force the location of my App.Config file:
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", AppConfigFilePath);
Nice, huh?
Here is another problem/solution:
I moved my COM object (see my previous article) to my client's server. My test classic-asp page failed when trying to do a CreateObject on the COM object. No explanation. No Event Log entry. No nothing. Just a HTTP error 500. Grrr.
I got a little bit more of a clue when I created a .vbs script that did the CreateObject, and ran it using cscript.exe. I got an error message "The system cannot find the file specified". Well, my COM object opens a config file, so I went down that route, with dead ends.
I did a registry search for my COM object.method, and found entries, but no path to where the dll actually lives. I even was able to delete my COM .dll and got the same error. Hmmm, that's a clue.
A couple of Google searches later, I found my answer. I have to register my COM object (written in c#) using regasm *and* use the /CODEBASE argument, which causes the location of the COM .dll to be noted in the registry. DOH!!!
I did that, and now it works.
Now, had I only been told that the error was coming from the .Net run-time, and that it was not finding the COM object dll, and maybe even a hint saying that /CODEBASE may be necessary if the assembly is not in the GAC, then my life would have been soooo much easier. Instead I just wasted a coupla more hours.
Seems I am on a rampage against terse (or none at all) error messages. Come on, people (Microsoft)!!!! It's 2009! Don't make my life as a software developer so dang hard!