Using .NET UI !!!

[Erland]

Hi all,
I have an application to make. I would prefer to make UI of my
application in .NET framework 1.x. My question is can i use UI that was
made in C#( .NET framework 1.x) in Visual Basic 6.0.
To be more specific i would like to create my UI in .NET and would
prefer to write application logic in Visual Basic 6.0 for the UI i made
in .NET. Hence, i want to use my .NET-UI component in Visual Basic 6.0
?
If this is possible then how should i go about it ? Please enlighten
me.
Thanks for your time and concern.
Regards,
-Erland.

 

[Robbe Morris [C# MVP]]

Why would you want to write business logic in COM?
..NET should outperform COM.

You certainly could use COM interop in your .NET
windows forms app but I fail to see the logic in that
in your scenario.

 

[Erland]

Hi Robbe,
So you mean by using COM Interop, i can use make my UI in .NET and then
use that UI in my VB 6.0 ?
Any pointers to books or articles that discuss this issue will be
highly appreciated. Thanks in advance.
-Erland

 

[Guest]

Yes, you can do it compiling the component in a Dynamic Link Library or
Standard Exe, to the same that you can made reference from your project in
Visual Studio and use it.

Visual Studio creates a wrapper of your Library DLL or EXE and allows to
access to the business logic from the UI of your project. You can made a
personal wrapper using TLBIMP, but is more quick with the reference tool in
Visual Studio.

But another possibility exists, you can made a reference to a .NET Assembly,
and I assure to you that he will be more efficient and fast.


Regards,
--
Ronald Ricardo Ramirez Moran
Solutions Architect

Blog:
http://blogs.wdevs.com/DlanorOk

Writing from:
El Triunfo, Guayas, Ecuador

 

[Guest]

You can found information about this on the following sites:

Microsoft VbFusion:
http://msdn.microsoft.com/vbrun/vbfusion/default.aspx

Microsoft Interoperability Site:
http://msdn.microsoft.com/netframework/programming/interop/

Regards,

--
Ronald Ricardo Ramirez Moran
Solutions Architect

Blog:
http://blogs.wdevs.com/DlanorOk

Writing from:
EL Triunfo, Guayas, Ecuador

 

[Willy Denoyette [MVP]]

Why would you want to write business logic in COM?
.NET should outperform COM.

And what exactly are you comparing here?
COM in a model, a set of binary interfaces, .NET is a development framework.
Anyway, if you mean to compare COM classes implemented using a native code
language (say C++) and managed classes, then, COM will mostly always
outperform .NET classes, but again this has nothing to with COM or .NET's
object model, it's about the runtime and it's (expected) overhead.
Take a look at Vista, a bunch of new system services are introduced and most
of them are COM based, that is they are exposed as COM interfcases, did MS
made the wrong choice here performance wise? I guess not.
Sure, I agree that choosing VB6 for new developments is not the right
choice, but this has nothing to do with .NET and outperforming COM.

Willy.

 

[Robbe Morris [C# MVP]]

I was referring to the use of them together. .NET to COM
via COM Interop (particularly a VB 6 dll) should perform
worse than a straight managed code scenario.

--
Robbe Morris - 2004/2005 Microsoft MVP C#
Free Source Code for ADO.NET Object Mapper To DataBase Tables And Stored
Procedures
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp

 

[Willy Denoyette [MVP]]

I was referring to the use of them together. .NET to COM
via COM Interop (particularly a VB 6 dll) should perform
worse than a straight managed code scenario.

--

Hmmm... And I was referring to <.NET should outperform COM.>
Even then, when using COM interop, there are scenarios that interop will
outperform pure .NET. Just consider DirectX, written in highly tuned native
C++ and exposed to managed DirectX (partly written in ME C++) through
IJW/COM interop, do you think a pure managed DirectX would outperform the
tandem managed DX/unmanaged DX? I can tell you it won't. The reason is
simple, in general, native code outperforms managed (JIT'ed code), the time
spent during the managed/unmanaged crossing can easily be compensated by the
faster execution time, especially when you have frequent calls into native
code (Win32 and other native API calls) and/or have to do a lot of floating
point arithmetics. Again, .NET design goal was not to compete with native
code at the execution performance level, it was designed to allow for
easier, faster more secure generic application design/development, with an
acceptable overall execution performance level, I think that most of these
goals are met with the current releases.
Again, I agree you shouldn't start new designs based on VB6, but that
doesn't mean that .NET and managed code languages) is an solution for all
programming problems.
Also, don't think COM is dead (as an interface and component model
certainly not), it's just moved to the system (and higher performance)
level, while .NET might take over some of it's place at the user application
level, you will allways have to consider (be it directly or indirectly) COM
and native code interop in your designs.

Willy.