I have a .NET Assembly that is configured as an Addin for a 3rd party
application via regasm.exe. My addin has worked in .NET 1.1 for over a
year now. I loaded .NET 2.0 Framework and pieces of my addin now fail.
Using RuntimeEnvironment.GetSystemVersion(), I discovered that my
addin is actually running in v2.0.50727 of the framework.

mscoree.dll is responsible for loading of the framework runtime.
Examining the registry entries created by regasm.exe, you'll see the
following.

[HKEY_CLASSES_ROOT\CLSID\{35224D40-BEE5-4397-97D1-3FA9A662DB54}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="MyAddin.Addin"
"Assembly"="MyAddin, Version=1.0.2167.24515, Culture=neutral,
PublicKeyToken=null"
"RuntimeVersion"="v1.1.4322"


Notice that the RuntimeVersion is specified correctly. So my question
is, does mscoree.dll not honor the RuntimeVersion specified by the
addin? If the answer is yes, it is possible, can someone please explain
to me what I need to do to make this happen.

The only alternative at this point that I can think of is using a C++
shim to control the loading of my addin. Very feasible but I'd at least
like to know why I am experiencing this problem.

Thanks.

Jason Newell

"Jason Newell" <nospam (AT) nospam (DOT) com> wrote

32]
Don't forget that only one version of CLR could be loaded into a given
running process.

So if yours "3rd party application" has already loaded a CLR - say v2.0 -
when yours
addin is loaded; your addin will then run under that CLR version.

A possible scenario here is that the client process is already running with
the 2.0 framework. You can't have two frameworks in the same process, so
your addin gets to run with whatever the client has already loaded. So if
you run Process Explorer or something that lists Dll paths, you might find
that the client has already loaded 2.0 before your Dll gets referenced. I
don't think a shim Dll would help - I suspect you'd be told that you can't
load 1.1 because 2.0 is already being hosted.
--
Phil Wilson [MVP Windows Installer]
----
"Jason Newell" <nospam (AT) nospam (DOT) com> wrote

"Jason Newell" <nospam (AT) nospam (DOT) com> wrote

If the third part application is a native COM client, the latest installed
version of the CLR and the framework will be loaded, this is by design.
This is done to guarantee that v2 add-in's as well as older version add-in's
can load and run in the same process.
What you could do is solve the issue(s) you have when running your addin-in
using v2 of the framework, another option is to write a shim that loads v1.x
in the hosting process, but remember that doing so will prevent you to
load/run vnext. add-in's in the same process.

Willy.

Thanks for your replies.

One thing that I've found out is that you can specify the
supportedRuntime attribute in the unmanaged hosts .exe.config file as
shown below.

<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>

I found this information here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/sidexsidenet.asp

This allowed my addin to load into the 1.1 CLR. Not a good long term
solution for the unmanaged host though and I'm sure they wouldn't
support me messing with their .exe.config file. I cannot dictate which
runtime their application supports.


This leads me back to the COM Add-in Shim. I've read much about
shimming by google'n. I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnoxpta/html/odc_comshim.asp
which is an Office XP Add-in Shim written in C++. I've taken this
example and ported it to my 3rd party unmanaged host's COM API instead
of using the Office API. The staus on that is the 3rd party unmanaged
host is now calling my shim. Now I'm working on getting my shim to load
my .NET addin.

Make sense? I know, my brain is fried too.


Jason Newell







Jason Newell wrote:

I don't believe that works for v2 of the runtime, did you try this?, the
page you are refering to talks about v1.0 and v1.1, these are not distinct
versions.

Willy.

"Jason Newell" <nospam (AT) nospam (DOT) com> wrote

Willy,

I didn't have time to work on it over the weekend but I should have an
answer this week sometime. The key to the addin shim is hosting your
own application domain. They accomplish this in the example by calling
CorBindToRuntimeEx() which allows you to specify which version of the
CLR to load. I see nothing reading
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/grfuncorbindtoruntimeex.asp
that would make me think it wouldn't work if 2.0 is installed. What in
particular are you thinking won't work?

I might mention that the testing that I have done, I had v1.1 & v2.0
installed and when running the shim example, I was able to call
CorBindToRuntimeEx() specifying v1.1 and I got no errors.

Thanks

Jason Newell



Willy Denoyette [MVP] wrote:

An update on this project.

Here is what I have installed on my machine.
- Windows XP SP2
- .NET Framework v1.1
- .NET Framework v2.0
- Visual Studio .NET 2003
- C# Express 2005

I created a C++ 7.1 COM Shim addin for my 3rd party application and used
parts of the C++ Office Shim addin that I needed. When the C++ Addin
Shim gets loaded, it loads CLR v1.1, creates an application domain, then
loads the real .NET addin. Worked perfect.

Here is a small snippet of code that I modified to load a specifc
version of the CLR. Notice that I added the szCLRVersion parameter.

HRESULT CCLRLoader::LoadCLR(LPCWSTR szCLRVersion)
{
HRESULT hr = S_OK;

// ensure the CLR is only loaded once.
if (m_pHost != NULL)
return hr;

// Load runtime into the process ...
hr = CorBindToRuntimeEx(szCLRVersion,
0,
STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN |
STARTUP_CONCURRENT_GC,
CLSID_CorRuntimeHost,
IID_ICorRuntimeHost,
(PVOID*) &m_pHost);

// couldn't load....
if (!SUCCEEDED(hr))
{
return hr;
}

// start CLR
return m_pHost->Start();
}

Jason Newell


Jason Newell wrote:

This might work for you, but if you also need to load a v2 add-in in the
same process it won't work, you can only have one version of the CLR loaded
at any time and a v2 add-in needs the v2 CLR.
The real solution is to make sure your v1 add-in's do work on v2 of the
framework.

Willy.


"Jason Newell" <nospam (AT) nospam (DOT) com> wrote

Willy,

Point taken.

I tested the scenerio you described and you are 100% correct. I work
closely with the 3rd party vendor developers and I've been trying to
help them with how to deal with managed COM addins and multiple versions
of the framework installed on the same machine. Your input is much
appreciated.

Sounds like it's much simpler to just code the darn thing in C++ and be
done with it. I'm very much a .NET advocate but this has been very
challenging on my soul ;-).

Jason Newell

Willy Denoyette [MVP] wrote: