3

I have a .net component library (dll) that I have successfully COM wrapped (using regasm). The .net component requires configuration information.

In the .Net world this is easily solved via the app.config. I can take the specific settings for this dll and add them to a web.config or exe.config so that when the dll is used in a program or on the web, it can access the necessary configuration information.

So my question is, when called via COM (say through an ASP page or even a VBScript), can I and how would I use the configuration file? Ideally, I would rather not hard code certain items.

rifferte
  • 1,392
  • 1
  • 13
  • 21

3 Answers3

2

See if this helps - Reading dll.config (not app.config!) from a plugin module

Community
  • 1
  • 1
Dipen Bhikadya
  • 3,318
  • 3
  • 21
  • 19
  • 2
    This works if you "own" what's reading the configuration and can ask it to read its config from the object you get back (as opposed to the default config from ConfigurationManager), but if it's a 3rd party component that's reading from (for instance) ConfigurationManager.AppSettings, this doesn't replace the configuration (or lack thereof) that was read when the AppDomain started. – nitzmahone Apr 20 '11 at 22:23
  • Thats a good point Matt. @rifferte, above solutions works only if you can modify COM wrapped dll code. – Dipen Bhikadya Apr 21 '11 at 00:02
  • I can modify the COM wrapped code so this is the direction I will take. Thanks! – rifferte Apr 21 '11 at 19:41
1

The problem is that with default COM activation, your managed component runs in the default AppDomain, which inherits its config name from the hosting .exe (eg, if you're running in cscript.exe, it wants to find cscript.exe.config next to cscript.exe, which you don't own). The easiest way to solve this is to create a managed shim that spins up a new AppDomain, then loads the assembly there, specifies the XXX.dll.config file that you want to use in the AppDomainSetup object, then creates and returns the object in the new AppDomain. This basically means you need to create a little managed factory object that ensures .NET is up and running and that your new AppDomain has been created (preferably only once- use the existing domain if creating a second object in the same process), then returns the managed object hosted in the right place. You can make the process completely transparent if you're willing to write an unmanaged shim that fully implements a COM class factory, but that's a little more advanced...

nitzmahone
  • 13,720
  • 2
  • 36
  • 39
0

Will the caller/creator of the COM object know where the configuration file is? As in, would exposing a "Load(path)" type function do the trick, or do you mean something different?

mrusinak
  • 1,002
  • 1
  • 12
  • 22