 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2005call .net 2.0 assemblies from .net 1.1
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 [quoted text clipped - 7 lines] > 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 >> There are some features that I want to use from .NET 2.0 but my >> company is [quoted text clipped - 10 lines] > 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 [quoted text clipped - 3 lines] > > 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/01/call-net-from-vb6.html which was posted in response to my enquiry some time back about hosting the CLR in VB6. Damien 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.  SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think Outside the Box! *********************************************** >> 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 [quoted text clipped - 20 lines] > > Damien > 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 :-) 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. ;-> SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think Outside the Box! *********************************************** >> Spooky! :-) >> [quoted text clipped - 6 lines] > Hey, I did say it wasn't pretty. And mine'll work even when TCP/IP > isn't installed :-) How do I go about doing that. Any papers on this? Perry >I see very few computers that do not have TCP/IP installed, but I am sure >tehre are some. :-) [quoted text clipped - 15 lines] >> Hey, I did say it wasn't pretty. And mine'll work even when TCP/IP >> isn't installed :-) I see a lot of theory but not much implementation specifics on SOA. How realistic is this today? Perry > Spooky! :-) > [quoted text clipped - 26 lines] >> >> Damien 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. SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think Outside the Box! *********************************************** > 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 [quoted text clipped - 18 lines] >> 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 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 Signaturehttp://www.grimes.demon.co.uk/workshops/fusionWS.htm http://www.grimes.demon.co.uk/workshops/securityWS.htm 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 >> 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 [quoted text clipped - 16 lines] > > Richard > 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 [quoted text clipped - 3 lines] > plan really to have developers of components have to manage so many > different code bases? I find this hard to belive. 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 Signaturehttp://www.grimes.demon.co.uk/workshops/fusionWS.htm http://www.grimes.demon.co.uk/workshops/securityWS.htm 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. SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think Outside the Box! *********************************************** > 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 [quoted text clipped - 5 lines] > Thanks > Perry 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 > 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 [quoted text clipped - 5 lines] > Thanks > 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 > 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 [quoted text clipped - 13 lines] >> Thanks >> 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... SignatureHope 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 [quoted text clipped - 5 lines] | Thanks | Perry Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.