Hello all together

I am creating a managed plug-in for a com based host application. For the
host application to find the new plug-in, I have to write some bits into the
registry.

The goal is to keep changes to the host application to a minimum (no touch,
it is a third party). I can do this by std. registration of the plug-in I am
working on, so CCW is used and the mscoree.dll is in charge of starting the
runtime and creating a appdomain. Everything fine so fare!


I would like to have a AppConfig file loaded into the AppDomain that is
hosting my plug-in. I dont want to touch the application host AppConfig, I
even dont want to read from its settings. The configuration file I would like
to be loaded into the newly created AppDomain only hold settings for my
plug-in.

The registry entry for my plugin uses the CodeBase entry to point to the
place where the assembly can be found.

I would love to have a entry ConfigFile that informs the mscoree to create a
new AppDomain and load the configuration file for it.

How easy is it to create a smarter mscoree.dll that knows about the
ConfigFile entry in the registry and does create a new AppDomain with the
Configuration file. Is it possible at all.

If someone has done it before or has a proper understanding what it would be
all about, please let me know.


--

[quoted text, click to view]

I'm not sure I understand your question exactly. MSCOREE is provided by the
o/s. It is not modifiable or replaceable.

I can tell you though that I wanted to permit managed plug-ins to be loaded
by a native server of mine. The way I chose to get the application domain
configured the way I wanted it was to use the "hosting" API. It was a bit of
work, but in the end, I got the domain I wanted and the interoperability I
needed.

If you want to go that route take a look at CorBindToRuntimeEx()

http://msdn2.microsoft.com/en-us/library/99sz37yh.aspx

which is what actually starts the CLR in a process.

The hosting overview is here

http://msdn2.microsoft.com/en-us/library/9x0wh2z3.aspx

Regards,
Will

Hy William and thanks to you for the quick reply

Sorry that I did not make myself. I will have a closer look at the API you
pointed out.

It is not my idea to replace mscoree.dll after all, but I would like know if
mscoree.dll would handle some undocumented registry entries. The registration
of a managed assembly points to mscoree.dll as the InprocServer32 default
entry, so mscoree.dll is the one that does some plumbing. The Type must be
loaded, there must be a runtime and a appdomain, the ccw has to be around.
So mscoree.dll does a lot after all but could do more in my opinion. If it
already handels the registry entry for CodeBase that comes with the
registration of a managed com visible type than it would be nice if other
registry entries would the mscoree.dll that it should create a appdomain and
use a configuration file for that appdomain. This could be done in the same
transparent manner as com interop is working now, can it? After the changes
to the API for 2.0 it is no longer possible to set the configuration at
runtime, after the appdomain has been created, is it?

The native server of yours is more or less the thing I will want to program.

If mscoree.dll does not handle then the next best thing for me would be a
"local" replacement of the mscoree.dll. I would then register the com
callable managed assembly as with a InprocServer32 default entry as of
"c:\...\myRuntimeNewAppDomainLoader.dll". If this
"myRuntimeNewAppDomainLoader.dll" be done at all ant could read the registry
entries for the type to be loaded, it could start a new AppDomain with the
right Configuration.

I hope this makes clear what my intention is?

Anyway, I will have a look at the API you pointed out and let you know if
you want how things go on.

Thx
--
Thanks for any feedback


[quoted text, click to view]