migration from COM to .NET 
Author Message
 migration from COM to .NET

Hi,
   What are the various options available when talking about migration
from COM to .NET?
   Which option to chose and when?
   Both with reference to VB and VC

Any pointers in this regard will be highly appreciated.

Thanks in advance
PrashanthG



Tue, 18 May 2004 19:03:05 GMT  
 migration from COM to .NET
Aparently, its very easy to migrate COM components to .NET, all you need to
create a .NET wrapper around the existing COM components so that they become
.NET client. In VS.NET it is done automatically when you add a reference to
COM component. Adding reference to COM components is similar to the way you
used to do (or still do) in VB6 etc. You can also create the .NET wrapper by
using a utility provided with .NET SDK called AxImp.exe or TlbImp.exe
(please confirm) - its a command line program.

Interestingly, you can also make .NET components available to your classic
COM applications and environments with another utility that ships with .NET
SDK called TlbExp.exe. This generates a type library information for your
COM components which you then simply register with RegSvr32.exe.

Both of these utilities can be found in the Bin folder in the Microsoft.Net
folder of your system drive (or whereever the SDK is installed on your
machine).

Irfan


Quote:
> Hi,
>    What are the various options available when talking about migration
> from COM to .NET?
>    Which option to chose and when?
>    Both with reference to VB and VC

> Any pointers in this regard will be highly appreciated.

> Thanks in advance
> PrashanthG



Tue, 18 May 2004 21:50:47 GMT  
 migration from COM to .NET
Keep in mind that .NET doesn't provide anything at all like COM+ services so
if you want transaction and role based security there is very little reason
to even use .NET since you will not be making things easier on yourself like
it was originally thought by the developers of .NET. Apparently they are
going to make it self contained in the future but as it stands right it only
provided dynamically bound objects and versioning and nothing else.

Ron A


Quote:
> Hi,
>    What are the various options available when talking about migration
> from COM to .NET?
>    Which option to chose and when?
>    Both with reference to VB and VC

> Any pointers in this regard will be highly appreciated.

> Thanks in advance
> PrashanthG



Wed, 19 May 2004 03:37:56 GMT  
 migration from COM to .NET
Wrong, .NET provides COM+ services through the EnterpriseServices namespace classes.
Take a look at the Framework classes before making such claims.

Willy.

Quote:

> Keep in mind that .NET doesn't provide anything at all like COM+ services so
> if you want transaction and role based security there is very little reason
> to even use .NET since you will not be making things easier on yourself like
> it was originally thought by the developers of .NET. Apparently they are
> going to make it self contained in the future but as it stands right it only
> provided dynamically bound objects and versioning and nothing else.

> Ron A



> > Hi,
> >    What are the various options available when talking about migration
> > from COM to .NET?
> >    Which option to chose and when?
> >    Both with reference to VB and VC

> > Any pointers in this regard will be highly appreciated.

> > Thanks in advance
> > PrashanthG



Wed, 19 May 2004 03:58:37 GMT  
 migration from COM to .NET
Yes, Willy is correct here. .NET fully leverages the COM+ services in this
area.

Ronald Laeremans
Visual C++ compiler team


Quote:
> Wrong, .NET provides COM+ services through the EnterpriseServices
namespace classes.
> Take a look at the Framework classes before making such claims.

> Willy.




Quote:
> > Keep in mind that .NET doesn't provide anything at all like COM+
services so
> > if you want transaction and role based security there is very little
reason
> > to even use .NET since you will not be making things easier on yourself
like
> > it was originally thought by the developers of .NET. Apparently they are
> > going to make it self contained in the future but as it stands right it
only
> > provided dynamically bound objects and versioning and nothing else.

> > Ron A



> > > Hi,
> > >    What are the various options available when talking about migration
> > > from COM to .NET?
> > >    Which option to chose and when?
> > >    Both with reference to VB and VC

> > > Any pointers in this regard will be highly appreciated.

> > > Thanks in advance
> > > PrashanthG



Thu, 20 May 2004 19:05:55 GMT  
 migration from COM to .NET
Hi,
   I think I was not very clear with my question. RCW( Runtime
callable wrapper) is one option for migration( rather interop). I
wanted to all possible options available for migration.

Thanks
PrashanthG

Quote:

> Aparently, its very easy to migrate COM components to .NET, all you need to
> create a .NET wrapper around the existing COM components so that they become
> .NET client. In VS.NET it is done automatically when you add a reference to
> COM component. Adding reference to COM components is similar to the way you
> used to do (or still do) in VB6 etc. You can also create the .NET wrapper by
> using a utility provided with .NET SDK called AxImp.exe or TlbImp.exe
> (please confirm) - its a command line program.

> Interestingly, you can also make .NET components available to your classic
> COM applications and environments with another utility that ships with .NET
> SDK called TlbExp.exe. This generates a type library information for your
> COM components which you then simply register with RegSvr32.exe.

> Both of these utilities can be found in the Bin folder in the Microsoft.Net
> folder of your system drive (or whereever the SDK is installed on your
> machine).

> Irfan



> > Hi,
> >    What are the various options available when talking about migration
> > from COM to .NET?
> >    Which option to chose and when?
> >    Both with reference to VB and VC

> > Any pointers in this regard will be highly appreciated.

> > Thanks in advance
> > PrashanthG



Fri, 21 May 2004 13:09:11 GMT  
 migration from COM to .NET
There are two possibilities.
1. COM Interop - There is no need to modify the existing code. Just
reference the COM component in the References window, a confirmation
will be asked to create the wrapper classess (RCW). Done.
But remember, this do not run in a managed environment and you lose its
benefits like garbage collection provided by .NET. The performance is
not so good.
2. Writing custom wrapper classes - The COM code can be compiled in .NET
without any compilation problmes, but then when you try to access this
dll from VB.NET or ASP.NET or C#, then you will not be able to access
any of the classes. Ideally, you have to expose all the classes written
in COM to .NET to access it across the lanaguages by writing a wrapper
class (this is very much simillar to the RCW). But why this approach.
You can make use of the .NET framework bebefits, thats it. This
introduces a new layer over COM thereby reduing the performance.

Daniel

Quote:

> Hi,
>    I think I was not very clear with my question. RCW( Runtime
> callable wrapper) is one option for migration( rather interop). I
> wanted to all possible options available for migration.

> Thanks
> PrashanthG


>>Aparently, its very easy to migrate COM components to .NET, all you need to
>>create a .NET wrapper around the existing COM components so that they become
>>.NET client. In VS.NET it is done automatically when you add a reference to
>>COM component. Adding reference to COM components is similar to the way you
>>used to do (or still do) in VB6 etc. You can also create the .NET wrapper by
>>using a utility provided with .NET SDK called AxImp.exe or TlbImp.exe
>>(please confirm) - its a command line program.

>>Interestingly, you can also make .NET components available to your classic
>>COM applications and environments with another utility that ships with .NET
>>SDK called TlbExp.exe. This generates a type library information for your
>>COM components which you then simply register with RegSvr32.exe.

>>Both of these utilities can be found in the Bin folder in the Microsoft.Net
>>folder of your system drive (or whereever the SDK is installed on your
>>machine).

>>Irfan



>>>Hi,
>>>   What are the various options available when talking about migration
>>>from COM to .NET?
>>>   Which option to chose and when?
>>>   Both with reference to VB and VC

>>>Any pointers in this regard will be highly appreciated.

>>>Thanks in advance
>>>PrashanthG



Sat, 22 May 2004 05:26:49 GMT  
 migration from COM to .NET
Hi Daniel,
         Your first point is very much clear. But with regards to your
second point, I did not understand, how to compile a VB code in .Net.
What I saw was when you try to open a VBP in .NET it starts a wizard
for upgrading it to .Net. Though not fully, it will convert a major
chunk of it and the remaning we will have to change based on the
comments it generates for us. Once fully compiled, I think it can be
very much used in any .Net Language.
    Regading writting a wrapper class, what I understand is writting a
wrapper function in .Net for all the functions in COM component and
make use of this assembly for calling the functions in COM Component.
What I am unclear with this is even this will be internally calling
the COM Component and all the marshalling etc will be happening
behind. How is this method better in performance when compared to the
first method.

Thanks for suggesting the above methods and will appreciate your help
to a greater extent if you can clarify this doubt of mine.

Thanks
PrashanthG

Quote:

> There are two possibilities.
> 1. COM Interop - There is no need to modify the existing code. Just
> reference the COM component in the References window, a confirmation
> will be asked to create the wrapper classess (RCW). Done.
> But remember, this do not run in a managed environment and you lose its
> benefits like garbage collection provided by .NET. The performance is
> not so good.
> 2. Writing custom wrapper classes - The COM code can be compiled in .NET
> without any compilation problmes, but then when you try to access this
> dll from VB.NET or ASP.NET or C#, then you will not be able to access
> any of the classes. Ideally, you have to expose all the classes written
> in COM to .NET to access it across the lanaguages by writing a wrapper
> class (this is very much simillar to the RCW). But why this approach.
> You can make use of the .NET framework bebefits, thats it. This
> introduces a new layer over COM thereby reduing the performance.

> Daniel


> > Hi,
> >    I think I was not very clear with my question. RCW( Runtime
> > callable wrapper) is one option for migration( rather interop). I
> > wanted to all possible options available for migration.

> > Thanks
> > PrashanthG


> >>Aparently, its very easy to migrate COM components to .NET, all you need to
> >>create a .NET wrapper around the existing COM components so that they become
> >>.NET client. In VS.NET it is done automatically when you add a reference to
> >>COM component. Adding reference to COM components is similar to the way you
> >>used to do (or still do) in VB6 etc. You can also create the .NET wrapper by
> >>using a utility provided with .NET SDK called AxImp.exe or TlbImp.exe
> >>(please confirm) - its a command line program.

> >>Interestingly, you can also make .NET components available to your classic
> >>COM applications and environments with another utility that ships with .NET
> >>SDK called TlbExp.exe. This generates a type library information for your
> >>COM components which you then simply register with RegSvr32.exe.

> >>Both of these utilities can be found in the Bin folder in the Microsoft.Net
> >>folder of your system drive (or whereever the SDK is installed on your
> >>machine).

> >>Irfan



> >>>Hi,
> >>>   What are the various options available when talking about migration
> >>>from COM to .NET?
> >>>   Which option to chose and when?
> >>>   Both with reference to VB and VC

> >>>Any pointers in this regard will be highly appreciated.

> >>>Thanks in advance
> >>>PrashanthG



Sat, 22 May 2004 11:55:06 GMT  
 migration from COM to .NET

Quote:
>    I think I was not very clear with my question. RCW( Runtime
> callable wrapper) is one option for migration( rather interop). I
> wanted to all possible options available for migration.

Prashanth,

Quite frankly, there aren't a whole lot of different options to choose from.
Irfan presented the most common ways of interacting between the two
technologies.

After the options that were presented by Irfan:

1. Use the VB Migration Wizard and run an existing VB6 COM project through
it. Then be prepared to wade through and fix the various upgrade errors and
warnings.

2. Write you own custom .NET wrapper for your COM component. I would only
recommend this if you want to add Attributes to your properties and methods
otherwise let VS.NET or the tlbimp.exe and aximp.exe create the wrappers as
it will probably do a much better job.

I don't know what other options you are looking for. Apparently you must
know of a few others that we don't and if that is the case, I would be
interested in hearing about them.

--
Regards,
Cal



Sat, 22 May 2004 13:22:48 GMT  
 migration from COM to .NET
Hi Prashanth,

Quote:
> What I am unclear with this is even this will be internally calling
> the COM Component and all the marshalling etc will be happening
> behind. How is this method better in performance when compared to the
> first method.

Well, the main thing is that a key layer (the ProxyStub) is removed from the
.Net proxy dll that is generated with the TlbImp.exe application. Going
through the ProxyStub layer with calls which pass a large amount of data and
automagically marshalled by the proxy layer does degrade performance
somewhat. This is the quicker and easier migration to .Net, but as with most
things, quicker and easier might not give you all the advantages you want.

On the other hand, using the wrapper method and then determining yourself
which of the data gets marshalled across the managed/unmanaged interop layer
is the ideal, since you can do all your conversions and marshalling yourself
and then just pass the native variables as pointers across no boundary. With
heavy duty stuff this can save an awful lot of clock ticks performance-wise.

--
regards,
Robert Svilpa
Software Design Engineer in Test
Managed Extensions for C++
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. ? 2001 Microsoft Corporation. All rights
reserved.


Quote:
> Hi Daniel,
>          Your first point is very much clear. But with regards to your
> second point, I did not understand, how to compile a VB code in .Net.
> What I saw was when you try to open a VBP in .NET it starts a wizard
> for upgrading it to .Net. Though not fully, it will convert a major
> chunk of it and the remaning we will have to change based on the
> comments it generates for us. Once fully compiled, I think it can be
> very much used in any .Net Language.
>     Regading writting a wrapper class, what I understand is writting a
> wrapper function in .Net for all the functions in COM component and
> make use of this assembly for calling the functions in COM Component.
> What I am unclear with this is even this will be internally calling
> the COM Component and all the marshalling etc will be happening
> behind. How is this method better in performance when compared to the
> first method.

> Thanks for suggesting the above methods and will appreciate your help
> to a greater extent if you can clarify this doubt of mine.

> Thanks
> PrashanthG




- Show quoted text -

Quote:
> > There are two possibilities.
> > 1. COM Interop - There is no need to modify the existing code. Just
> > reference the COM component in the References window, a confirmation
> > will be asked to create the wrapper classess (RCW). Done.
> > But remember, this do not run in a managed environment and you lose its
> > benefits like garbage collection provided by .NET. The performance is
> > not so good.
> > 2. Writing custom wrapper classes - The COM code can be compiled in .NET
> > without any compilation problmes, but then when you try to access this
> > dll from VB.NET or ASP.NET or C#, then you will not be able to access
> > any of the classes. Ideally, you have to expose all the classes written
> > in COM to .NET to access it across the lanaguages by writing a wrapper
> > class (this is very much simillar to the RCW). But why this approach.
> > You can make use of the .NET framework bebefits, thats it. This
> > introduces a new layer over COM thereby reduing the performance.

> > Daniel


> > > Hi,
> > >    I think I was not very clear with my question. RCW( Runtime
> > > callable wrapper) is one option for migration( rather interop). I
> > > wanted to all possible options available for migration.

> > > Thanks
> > > PrashanthG




- Show quoted text -

Quote:

> > >>Aparently, its very easy to migrate COM components to .NET, all you
need to
> > >>create a .NET wrapper around the existing COM components so that they
become
> > >>.NET client. In VS.NET it is done automatically when you add a
reference to
> > >>COM component. Adding reference to COM components is similar to the
way you
> > >>used to do (or still do) in VB6 etc. You can also create the .NET
wrapper by
> > >>using a utility provided with .NET SDK called AxImp.exe or TlbImp.exe
> > >>(please confirm) - its a command line program.

> > >>Interestingly, you can also make .NET components available to your
classic
> > >>COM applications and environments with another utility that ships with
.NET
> > >>SDK called TlbExp.exe. This generates a type library information for
your
> > >>COM components which you then simply register with RegSvr32.exe.

> > >>Both of these utilities can be found in the Bin folder in the
Microsoft.Net
> > >>folder of your system drive (or whereever the SDK is installed on your
> > >>machine).

> > >>Irfan



> > >>>Hi,
> > >>>   What are the various options available when talking about
migration
> > >>>from COM to .NET?
> > >>>   Which option to chose and when?
> > >>>   Both with reference to VB and VC

> > >>>Any pointers in this regard will be highly appreciated.

> > >>>Thanks in advance
> > >>>PrashanthG



Sun, 23 May 2004 04:28:49 GMT  
 migration from COM to .NET
Quote:
> Well, the main thing is that a key layer (the ProxyStub) is removed from
the
> .Net proxy dll that is generated with the TlbImp.exe application. Going
> through the ProxyStub layer with calls which pass a large amount of data
and
> automagically marshalled by the proxy layer does degrade performance
> somewhat. This is the quicker and easier migration to .Net, but as with
most
> things, quicker and easier might not give you all the advantages you want.

> On the other hand, using the wrapper method and then determining yourself
> which of the data gets marshalled across the managed/unmanaged interop
layer
> is the ideal, since you can do all your conversions and marshalling
yourself
> and then just pass the native variables as pointers across no boundary.
With
> heavy duty stuff this can save an awful lot of clock ticks

performance-wise.

Robert,

Are there any good article on creating a COM wrapper by hand? I have looked
all over the place but haven't found anything but small code snippets.

Thanks,

Cal



Sun, 23 May 2004 04:47:01 GMT  
 migration from COM to .NET
Hi Cali,
I'm going to pull a cop out here and just give you the answer David Wolfram
gave to another contributor to this forum. The example given below really
isnt much different than wrapping a COM class, you just need to write your
wrapper referencing the class and then marshalling the data from within.:

The Managed Extensions for C++ Migration Guide Part I in the online help
contains a running example of wrapping an unmanaged C++ class using Managed
Extensions.

It can be found by starting the IDE and navigating to
ms-help://MS.VSCC/MS.MSDNVS/vcmxspec/html/vcManExMigrationGuidePart1_Start.h
tm, or look for it in the contents under Visual Studio .NET -> Visual C++ ->
Managed Extensions for C++ Programming.

Also:

Accessing COM Objects from the Runtime.
ms-help://MS.VSCC/MS.MSDNVS/vcmxspec/html/vcmg_AccessingCOMObjectsfromtheRun
time.htm

It uses the JrnlPost sample:
ms-help://MS.VSCC/MS.MSDNVS/vcsample/html/vcsamJrnlPostSample.htm.

that wraps the underlying C++ class of a COM object.

Please let us know if you have further questions.

--
David Wolfram
Visual C++ Compiler Team

--
regards,
Robert Svilpa
Software Design Engineer in Test
Managed Extensions for C++
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. ? 2001 Microsoft Corporation. All rights
reserved.


Quote:
> > Well, the main thing is that a key layer (the ProxyStub) is removed from
> the
> > .Net proxy dll that is generated with the TlbImp.exe application. Going
> > through the ProxyStub layer with calls which pass a large amount of data
> and
> > automagically marshalled by the proxy layer does degrade performance
> > somewhat. This is the quicker and easier migration to .Net, but as with
> most
> > things, quicker and easier might not give you all the advantages you
want.

> > On the other hand, using the wrapper method and then determining
yourself
> > which of the data gets marshalled across the managed/unmanaged interop
> layer
> > is the ideal, since you can do all your conversions and marshalling
> yourself
> > and then just pass the native variables as pointers across no boundary.
> With
> > heavy duty stuff this can save an awful lot of clock ticks
> performance-wise.

> Robert,

> Are there any good article on creating a COM wrapper by hand? I have
looked
> all over the place but haven't found anything but small code snippets.

> Thanks,

> Cal



Sun, 23 May 2004 07:43:52 GMT  
 migration from COM to .NET

Quote:
> I'm going to pull a cop out here and just give you the answer David
Wolfram
> gave to another contributor to this forum. The example given below really
> isnt much different than wrapping a COM class, you just need to write your
> wrapper referencing the class and then marshalling the data from within.:

Robert,

Links are always a great starting point!

Thanks,
Cal



Sun, 23 May 2004 07:57:32 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Migration to .NET:ASP.NET with ADO

2. Migration: HowTo replace VB6-Helpsystem with VB.NET-HelpProvider

3. Migration from VB6 to VB.NET

4. The Visual Basic 6.0 migration tool is not installed on this computer (VS.NET Pro)

5. Migration from VB to VB.Net

6. Calling COM EXE from VB.NET Service leaves COM EXE in Memory

7. Automation error referencing .net dll from com (com interop)

8. news:3qgju8$j7m@ixnews3.ix.netcom.com

9. Severe VB.NET COM/.NET Interop Limitation

10. Using .NET generated COM DLL in Excel

11. Office COM Add-In and VB.NET

 

 
Powered by phpBB® Forum Software