There are some features that I want to use from .NET 2.0 but my company is
not ready to do the shift yet. I have incapsulated these functions in a .NET
2.0 assembly that I want to call from our existing .NET 1.1 application.
When adding the reference to the .NET 2.0 assembly in VS 2003 the IDE
complained that the assembly is not recognizable.
What I am doing wrong?

Thanks
Perry

> There are some features that I want to use from .NET 2.0 but my
> company is
> not ready to do the shift yet. I have incapsulated these functions in
> a .NET
> 2.0 assembly that I want to call from our existing .NET 1.1
> application.
> When adding the reference to the .NET 2.0 assembly in VS 2003 the IDE
> complained that the assembly is not recognizable.
> What I am doing wrong?
> Thanks
> Perry

Even if you could load more than one CLR in a process, how is the 1.1 runtime
going to know what to do with the 2.0 code

Well, you can call .NET 1.1 and 2.0 assemblies from VB 6.0 or any COM
framework which is much older. It only stands to reason that there should be
a way to call .NET 2.0 assemblies from .NET 1.1 which is much newer and much
closer in design than COM is. Maybe some kind of wrapper is needed. Anyone
have any advice on how to do this?

Perry


"chris martin" <chris_m|NOSPAM|@caliber|SPAM|web.com> wrote in message
news:(E-Mail Removed)...
>> There are some features that I want to use from .NET 2.0 but my
>> company is
>> not ready to do the shift yet. I have incapsulated these functions in
>> a .NET
>> 2.0 assembly that I want to call from our existing .NET 1.1
>> application.
>> When adding the reference to the .NET 2.0 assembly in VS 2003 the IDE
>> complained that the assembly is not recognizable.
>> What I am doing wrong?
>> Thanks
>> Perry
>
> Even if you could load more than one CLR in a process, how is the 1.1
> runtime going to know what to do with the 2.0 code?
>
>

Perecli Manole wrote:
> Well, you can call .NET 1.1 and 2.0 assemblies from VB 6.0 or any COM
> framework which is much older. It only stands to reason that there should be
> a way to call .NET 2.0 assemblies from .NET 1.1 which is much newer and much
> closer in design than COM is. Maybe some kind of wrapper is needed. Anyone
> have any advice on how to do this?
>
> Perry
>

I *think* you could do it by adding a COM reference to the CLR and
hosting the 2.0 CLR, then creating a new AppDomain inside that and
loading the 2.0 assembly into it. It ain't going to be pretty, and
you'll have lots of cross-AppDomain issues, I predict.

If you do want to go that route, I'd suggest looking at this:

http://www.danielmoth.com/Blog/2005/...-from-vb6.html

which was posted in response to my enquiry some time back about hosting
the CLR in VB6.

Damien

You can't do it the way you are attempting. When you make a reference, the
new assembly runs in the same app domain as the calling assembly. This
means, it must be compiled in the same version.

To have 1.1 and 2.0 coexist, you need to have the 2.0 stuff running in a
different app domain. Period.

Options:
1. Web services - when I say this, I mean ASMX or Remoting, as they are
essentially two peas in the same pod (drop HTTP (and IIS in most instances)
and you have Remoting)
2. Enterprise Services (COM+) - Yuck, but there are ways to get this to
work.
3. Windows Service - You still need an interface, so this is only a partial
solution.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
"Perecli Manole" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> There are some features that I want to use from .NET 2.0 but my company is
> not ready to do the shift yet. I have incapsulated these functions in a
> .NET 2.0 assembly that I want to call from our existing .NET 1.1
> application. When adding the reference to the .NET 2.0 assembly in VS 2003
> the IDE complained that the assembly is not recognizable.
> What I am doing wrong?
>
> Thanks
> Perry
>

You can call .NET from COM as there is an app domain shift. COM cannot hold
assemblies in the same app domain, so there is a marshall (called Interop)
to move from world to world. It can be pictured like this:

----------------- -------------------
| COM | | .NET |
----------------- -------------------

While it appears you are simply making a call to a .NET component from COM,
you are actually calling a COM based wrapper that contacts the .NET world to
talk.

If you want to code the inner workings to make .NET 1.1 talk to .NET 2.0,
you can create a cross .NET version Interop, but it will have to be coded to
make the referencing available the way you want. Web Services (ASMX or
Remoting) is an easier solution.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
"Perecli Manole" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Well, you can call .NET 1.1 and 2.0 assemblies from VB 6.0 or any COM
> framework which is much older. It only stands to reason that there should
> be a way to call .NET 2.0 assemblies from .NET 1.1 which is much newer and
> much closer in design than COM is. Maybe some kind of wrapper is needed.
> Anyone have any advice on how to do this?
>
> Perry
>
>
> "chris martin" <chris_m|NOSPAM|@caliber|SPAM|web.com> wrote in message
> news:(E-Mail Removed)...
>>> There are some features that I want to use from .NET 2.0 but my
>>> company is
>>> not ready to do the shift yet. I have incapsulated these functions in
>>> a .NET
>>> 2.0 assembly that I want to call from our existing .NET 1.1
>>> application.
>>> When adding the reference to the .NET 2.0 assembly in VS 2003 the IDE
>>> complained that the assembly is not recognizable.
>>> What I am doing wrong?
>>> Thanks
>>> Perry
>>
>> Even if you could load more than one CLR in a process, how is the 1.1
>> runtime going to know what to do with the 2.0 code?
>>
>>
>
>

Spooky! :-)

SOA is a better option than trying to host a different app domain. Sure, it
adds overhead (so does the different app domain model), but the plumbing is
already envisioned.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
"Damien" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Perecli Manole wrote:
>> Well, you can call .NET 1.1 and 2.0 assemblies from VB 6.0 or any COM
>> framework which is much older. It only stands to reason that there should
>> be
>> a way to call .NET 2.0 assemblies from .NET 1.1 which is much newer and
>> much
>> closer in design than COM is. Maybe some kind of wrapper is needed.
>> Anyone
>> have any advice on how to do this?
>>
>> Perry
>>
>
> I *think* you could do it by adding a COM reference to the CLR and
> hosting the 2.0 CLR, then creating a new AppDomain inside that and
> loading the 2.0 assembly into it. It ain't going to be pretty, and
> you'll have lots of cross-AppDomain issues, I predict.
>
> If you do want to go that route, I'd suggest looking at this:
>
> http://www.danielmoth.com/Blog/2005/...-from-vb6.html
>
> which was posted in response to my enquiry some time back about hosting
> the CLR in VB6.
>
> Damien
>

Cowboy (Gregory A. Beamer) wrote:
> Spooky! :-)
>
> SOA is a better option than trying to host a different app domain. Sure, it
> adds overhead (so does the different app domain model), but the plumbing is
> already envisioned.
>
Hey, I did say it wasn't pretty. And mine'll work even when TCP/IP
isn't installed :-)

Perecli Manole wrote:
> Well, you can call .NET 1.1 and 2.0 assemblies from VB 6.0 or any COM
> framework which is much older. It only stands to reason that there

No. It does not stand to reason.

> should be a way to call .NET 2.0 assemblies from .NET 1.1 which is
> much newer and much closer in design than COM is. Maybe some kind of
> wrapper is needed. Anyone have any advice on how to do this?

Well .NET 2.0 code is not backward compatible with 1.1, so I would not
want to host different versions of the runtim,e in the same process. The
'solution' of using a new appdomain is also dodgy since all appdomains
share the same managed heap. Also threads in a managed process are free
to execute in any app domain - yes, the data is marshalled and the
context is applied, but the *same* thread is used. Threads in .NET
version 2.0 are different to version 1.1, so there is an
incompattibility there. Cowboy's suggestion is best - put the .NET code
into a separate process and access with some interprocess mechanism.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

I see very few computers that do not have TCP/IP installed, but I am sure
tehre are some. :-)

My suggestion would be package the functionality as a larger service. Either
that, or avoid using 2.0 bits until the company goes to 2.0 (may be the best
option, as it avoids firing due to insubordination). But, I do like the idea
of wrapping the app domain (interop for .NET); it is just cause I am a geek.
;->

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
"Damien" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Cowboy (Gregory A. Beamer) wrote:
>> Spooky! :-)
>>
>> SOA is a better option than trying to host a different app domain. Sure,
>> it
>> adds overhead (so does the different app domain model), but the plumbing
>> is
>> already envisioned.
>>
> Hey, I did say it wasn't pretty. And mine'll work even when TCP/IP
> isn't installed :-)
>