Our software has been around for a long time. It started life as an ASP application, with all the database logic tucked away in VB6 components, and lots and lots of ASP pages.
Because we invested so much into these VB6 components and also the ASP UI infrastructure, we're still using it today - so we have ASP pages that call VB6 components. Obviously, as we move more and more of the code into .NET, we are relying on Interop more and more to allow us to make use of "new" stuff from existing ASP pages... It was all working well until recently we needed to implement new features that rely on getting data out of the application config file... thats where it all goes bad :(
If you interop from unmanaged code to .NET, .NET will look for an app config that matches the executing process's filename + ".config".
.. which sucks for us. We implemented a cool new permissions checking infrastructure in .NET, and as part of this I wanted to use the SQL Cache Dependency to be able to auto-remove cache data when the underlying data changes. But...SQL Cache dependency relies on configuration data being set in the app config, so when we call through from a VB6 app - it aint gonna work! If called from COM like our .NET code is, the .NET assembly you execute is being executed from the process DLLHOST.exe, which lives in the System32 folder. Therefore the CLR looks for a config file called "DLLHost.Exe.Config" - try pursuading your clients to create that :)
This is a real shame and it stops us from using the SQL Cache Dependency stuff and some other things that are configured using the app config. We can get round it for simple settings like the connection strings, because we create our own classes to process the web.config that we actually do want to use, and that works, but for a lot of stuff that relies heavily on config setup, we can't use it... its a bummer!