HighTechTalks DotNet Forums  

.NET 2.0 - mscoree.dll ignores RuntimeVersion

Dotnet Framework (Interop) microsoft.public.dotnet.framework.interop


Discuss .NET 2.0 - mscoree.dll ignores RuntimeVersion in the Dotnet Framework (Interop) forum.

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Jason Newell
 
Posts: n/a

Default .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-07-2005 , 02:17 PM






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



Reply With Quote
  #2  
Old   
Yves Tourchot
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-08-2005 , 09:12 AM







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

Quote:
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}\InprocServer
32]
Quote:
@="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
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.








Reply With Quote
  #3  
Old   
Phil Wilson
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-08-2005 , 04:15 PM



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

Quote:
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



Reply With Quote
  #4  
Old   
Willy Denoyette [MVP]
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-08-2005 , 04:37 PM




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

Quote:
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
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.




Reply With Quote
  #5  
Old   
Jason Newell
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-09-2005 , 09:25 AM



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:
Quote:
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

Reply With Quote
  #6  
Old   
Willy Denoyette [MVP]
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-11-2005 , 06:41 AM



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

Quote:
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 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



Reply With Quote
  #7  
Old   
Jason Newell
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion - 12-12-2005 , 08:43 AM



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:
Quote:
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 in message
news:%23DXe5SN$FHA.1028 (AT) TK2MSFTNGP11 (DOT) phx.gbl...

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 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




Reply With Quote
  #8  
Old   
Jason Newell
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion (Update) - 12-14-2005 , 07:53 AM



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:
Quote:
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:

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 in message
news:%23DXe5SN$FHA.1028 (AT) TK2MSFTNGP11 (DOT) phx.gbl...

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 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





Reply With Quote
  #9  
Old   
Willy Denoyette [MVP]
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion (Update) - 12-14-2005 , 09:04 AM



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

Quote:
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:
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:

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 in message
news:%23DXe5SN$FHA.1028 (AT) TK2MSFTNGP11 (DOT) phx.gbl...

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 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







Reply With Quote
  #10  
Old   
Jason Newell
 
Posts: n/a

Default Re: .NET 2.0 - mscoree.dll ignores RuntimeVersion (Update) - 12-14-2005 , 10:12 AM






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:
Quote:
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 in message
news:OuMFHXLAGHA.436 (AT) TK2MSFTNGP10 (DOT) phx.gbl...

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:

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:


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 in message
news:%23DXe5SN$FHA.1028 (AT) TK2MSFTNGP11 (DOT) phx.gbl...


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 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







Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.