call .net 2.0 assemblies from .net 1.1

  • Thread starter Thread starter Perecli Manole
  • Start date Start date
P

Perecli Manole

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
Click to expand...

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
 
Perecli said:
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
Click to expand...

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/01/call-net-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!
***********************************************
 
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!
***********************************************
 
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!
***********************************************
 
Cowboy said:
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.
Click to expand...
Hey, I did say it wasn't pretty. And mine'll work even when TCP/IP
isn't installed :-)
 
Perecli said:
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
Click to expand...

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?
Click to expand...

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
 
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!
***********************************************
 
Are you saying your company is okay with installing the .NET 2.0 runtime
on their machines, it's just they don't want to upgrade their
applications to v2.0?

Cheers,

Stuart
 
But this is not easy to do from a consumer standpoint. As a component
provider I need to service users that use both framework versions. It seems
the only solution is to so a code split and compile against each version for
every release. This is very time consuming and then what happens when
another version of .NET comes out. Is Microsoft's plan really to have
developers of components have to manage so many different code bases? I find
this hard to belive.

Perry
 
No, I over simplified a little. The users who use my component libraries
(non UI), have applications already written in VS2003 .NET 1.1 and I don't
want to bifurcate my develompment by having multiple code bases to support
these legacy users.

Perry
 
I see a lot of theory but not much implementation specifics on SOA. How
realistic is this today?

Perry
 
Perecli,
In addition to the other comments:

..NET 2.0 will run most .NET 1.1 & 1.0 applications without any problems.

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

In fact most .NET 1.0 & 1.1 apps will/should run under the .NET 2.0 64-bit
edition!

http://blogs.msdn.com/joshwil/archive/2005/05/06/415191.aspx

However due to meta file changes (Generics & such) .NET 1.0 & 1.1 cannot run
..NET 2.0 assemblies.

It would seem to me that if you cut over to 2.0 then your users at the very
least need to verify their applications will run under 2.0 w/o recompiling
per the first link.

Alternatively you could have a single code base with conditional compilation
to isolate the 2.0 code from the 1.1 code, however then you are stuck with
how to fail gracefully under 1.1... If I went the conditional compilation
route I would have a project for each version I was working on, however each
project would be linked to a single copy of the source file. Using Sharing
in VSS would be another option...


--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| 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
|
|
 
Perecli said:
But this is not easy to do from a consumer standpoint. As a component
provider I need to service users that use both framework versions. It
seems the only solution is to so a code split and compile against
each version for every release. This is very time consuming and then
what happens when another version of .NET comes out. Is Microsoft's
plan really to have developers of components have to manage so many
different code bases? I find this hard to belive.
Click to expand...

If they are keen for people to do as you say they would have a document
telling you that .NET is so much better than any other component
framework because .NET allows this feature. They don't.

If Microsoft doesn't shout out that you can do something you can bet the
reason is that you cannot do it, but they won't tell you so in fear of
tarnishing the reputation of their product.

Richard
 
Back
Top