VB.NET or C++ .NET for GUI

  • Thread starter Thread starter Pankaj
  • Start date Start date
P

Pankaj

Hi all,
I have write a GUI application(in 4-6 weeks), which is
quite rich in functionality and Uses COM to connect to
other parts of my software.
I have to support 98,2000 and XP and enable software for
multiple languages (Internationalization).

I am trying to find out which one of VB.NET or VC++ .NET
is better. I am new to .NET but know Windows APIs, Visual
C++ 6.0 and VB 6.0 pretty well.

Is VB.NET code only managed ? And do i have to supply the
CLR environment with my executables.

Any help appreciated ? Keeping above aspects in mind,
which is a better option and provides quicker path to good
stable GUI application.

thanks
Pankaj
 
Hi all,
I have write a GUI application(in 4-6 weeks), which is
quite rich in functionality and Uses COM to connect to
other parts of my software.
I have to support 98,2000 and XP and enable software for
multiple languages (Internationalization).

I am trying to find out which one of VB.NET or VC++ .NET
is better. I am new to .NET but know Windows APIs, Visual
C++ 6.0 and VB 6.0 pretty well.

Is VB.NET code only managed ? And do i have to supply the
CLR environment with my executables.

Any help appreciated ? Keeping above aspects in mind,
which is a better option and provides quicker path to good
stable GUI application.

thanks
Pankaj

I have not used C++.NET so can't comment much on that. I've used both
VB.NET and C#.NET.

VB does not offer anything that makes GUI development any easier than C#.
Both have the same great form designer.

C# can run managed and unmanaged code. VB is managed only. So if you
need to write some unmanaged .NET code, you cannot use VB. However, you
can call a COM dll from any .NET language using the Interop namespace.
Interop is not the same as "unmanged". Also you can call PInvoke
platform calls from any of the languages, it is also not considered
"unmanaged".

C# syntax in C++ based, so you should be familiar with it.

The .NET framework will be your biggest learning curve. It is a huge
library full of great features. The framework works in the same way from
any of the .NET languages.

--
Michael Lang, MCSD
See my .NET open source projects
http://sourceforge.net/projects/colcodegen (simple code generator)
http://sourceforge.net/projects/dbobjecter (database app code generator)
http://sourceforge.net/projects/genadonet ("generic" ADO.NET)
 
C# can run managed and unmanaged code. VB is managed only. So if you
need to write some unmanaged .NET code, you cannot use VB. However, you
can call a COM dll from any .NET language using the Interop namespace.
Interop is not the same as "unmanged". Also you can call PInvoke
platform calls from any of the languages, it is also not considered
"unmanaged".

I'm not sure I understand what you mean by "C# can run managed and unmanaged
code. VB is managed only".
Could you developp it a bit?

José
 
I think he meant "unsafe." All code in either C# or VB.Net is managed, but
only C# can use unsafe code. (As far as I know, there's rarely a
compelling need to use unsafe code anyway -- it doesn't provide much
performance benefit.)

Otherwise, I agree 100% with Michael -- either VB.Net or C# would be a great
choice for developing the user interface. Use whichever language you feel
most comfortable with.
 
I think he meant "unsafe." All code in either C# or VB.Net is
managed, but only C# can use unsafe code. (As far as I know, there's
rarely a compelling need to use unsafe code anyway -- it doesn't
provide much performance benefit.)

Otherwise, I agree 100% with Michael -- either VB.Net or C# would be a
great choice for developing the user interface. Use whichever
language you feel most comfortable with.


Yes, I mean "unsafe" code. code in "unsafe" blocks manipulate memory
directly, and that therefore that memory is unmanaged. Or am I mistaken?
 
If you need to get out of managed code, you have to go to C++. If .NET
managed code is okay, VB.NET is easier to write (unless you are a C++ coder,
of course).

there is an article on boostrapping the .NET redistributable with managed
apps, whether they be VB.NET or VC++ .NET. And, yes, you do have to add the
redist to your setup for a managed app.

If you have a lot of COM interaction, I would go C++, or move back to Visual
Studio 6.0.

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

**********************************************************************
Think outside the box!
**********************************************************************
 
Thanks for the response. I have some more queries.
Firstly, I understand using VB.NET means writing managed
code. But with C++ i have a choice of going wither native
or managed. Question is , if i use C++, Are there things
in .NET libraries that radically change/help develop the
GUI application ? like Internationalization stuff....

Secondly if i were to write Managed C++, will my
connectivity to my other COM components (writen in VC 6)
be affected ?

Thirdly since i am comfortable with both VB and VC, is it
just better to choose VB.net since COM problem in VB
doesnt exist, as its all automatic (my COM code works with
a VB 6.0 GUI).

thanks
Pankaj
 
..Net has a lot of resources for internationalization. Check out this MSDN
article and this thread:

http://msdn.microsoft.com/library/d...ide/html/cpcondesigningglobalapplications.asp

http://groups.google.com/groups?hl=...-8&safe=off&selm=umdtH5bsBHA.1860@tkmsftngp04
(Complete thread)


Regarding COM with VB.Net, keep in mind that VB.Net isn't COM-native, like
VB6. Instead, it uses a process called interop to translate between COM and
..Net managed code. This adds some overhead to your COM calls, but not much.
It works rather automatically, so a COM object that works in VB6 should work
fine with VB.Net, C# or (as far as I know) Managed C++.

The only consideration is that some data types have changed in VB.Net, so
you have to remember to use the correct types with your COM objects. For
example, an Integer is now four byes -- equivalent to a Long in VB6.

http://msdn.microsoft.com/library/d...ml/vaconIntroductionToCOMInteroperability.asp

http://msdn.microsoft.com/library/d...en-us/cpguide/html/cpconinteropmarshaling.asp
 
Hi
There is a major difference between the terms
managed/unmanaged and unsafe.

<B>Managed code</B> is that code which executes under the
supervision of the CLR. The CLR is responsible for various
housekeeping tasks, like:
managing memory for the objects
performing type verification
doing garbage collection
Any code that targets the CLR to make use of these
features in Managed Code and can be written in any
language like C#, VB.Net, MC++, Fujitsu Net Cobol, Eiffel
etc...

On the other hand, <B>unmanaged code</B> is that code
which executes outside the context of the CLR. The best
example of this is our traditional Win32 DLLs like
kernel32.dll, user32.dll, and the COM components installed
on our system. How they allocate memory for their usage,
how memory is released, how (if any) type verification
takes places are some of the tasks that are undertaken by
them on their own. A typical C++ program which allocates
memory to a character pointer is another example of
unmanaged code because you as the programmer are
responsible for:
calling the memory allocation function
making sure that the casting is done right
making sure that the memory is released when the work is
done
If you notice, in the managed world, all this housekeeping
is done by the CLR, as explained above, relieving the
programmer of the burden.



<B>Unsafe code</B> is a kind of cross between the managed
and unmanaged codes
It executes under the supervision of the CLR, just like
the managed code, but lets you address the memory
directly, through the use of pointers, as is done in
unmanaged code. Thus, you get the best of both worlds. You
might be writing a .NET application that uses the
functionality in a legacy Win32 DLL, whose exported
functions require the use of pointers. That's where unsafe
code comes to your rescue

So
a) Both VB.Net and C# produce IL and IL is definitely run
under the managed context.
b) In the case of win32 or COM they run outside the
managed environment.
c) Unsafe code can be written in C#(using unsafe blocks)
but NOT in VB.Net. this is the only difference btwn the
two in this context
d) Unsafe Code also runs inside the managed environment
(remember UnSafe Code is written inside a C# program and
C# code always runs as managed code), but as a deviation
from a normal managed code, it allows use and manipulation
of pointers, which makes it powerful(and dangerous if u
dont know wat u r doing). As you use direct manipulation
of pointers, you normally pin(fix) the memeory location of
the variable inside unsafe code(lest the CLR mess up with
the reference during GC and heap compact operation and u
ask "who moved my cheese" :) )

Now back to the original question. Though i have worked
on java for quite some time and C# was easy for me to use
(semantics-wise), i still remain(n honoured to be) a VB
Buff. lets map the technical capabilities to the
requirements now..

a) Learning Curve : If ur developers are with VB
background, then stick to VB.Net(forget those holier-than-
thou guys who smirk at VB programmers...) But if ur dev
base is java familiar go ahead with C#(its as good, after
all MS made both the languages :) )

b) COM Interop & Late Binding : If you are using COM, one
thing tht might need in your programs is the concept of
late binding. If so VB.Net is the way to go as it fully
supports late binding, whereas achieving it in C# is a
pain in the butt

c) UI : Somehow i always feel that UI designed in VB.Net
is more user-friendly(and aesthetic) than a form designed
in C#. Probably this is just coz im nostalgic, but still
my feeling is strong in this regard

d) UnManaged Code : If you are going to call UnManaged
Code like Win32 APIs(NOT COM components, as COM interop is
supported in both C# and VB.Net), then C# is th way to go

e) Unsafe Code : As explained C# is the way to go

hth

regards,

sr
 
Good information, SR. I'm coming from a VB6 background, so I also have a
preference for VB.Net -- I think the IDE is a bit better with intellisense
and background compilation.

Only one question -- why do you believe that C# is better for API calls?
AFAIK, every API call runs equally well with VB.Net. (I've run a few
without any problems, although I try to avoid them unless necessary.)



Hi
There is a major difference between the terms
managed/unmanaged and unsafe.

<B>Managed code</B> is that code which executes under the
supervision of the CLR. The CLR is responsible for various
housekeeping tasks, like:
managing memory for the objects
performing type verification
doing garbage collection
Any code that targets the CLR to make use of these
features in Managed Code and can be written in any
language like C#, VB.Net, MC++, Fujitsu Net Cobol, Eiffel
etc...

On the other hand, <B>unmanaged code</B> is that code
which executes outside the context of the CLR. The best
example of this is our traditional Win32 DLLs like
kernel32.dll, user32.dll, and the COM components installed
on our system. How they allocate memory for their usage,
how memory is released, how (if any) type verification
takes places are some of the tasks that are undertaken by
them on their own. A typical C++ program which allocates
memory to a character pointer is another example of
unmanaged code because you as the programmer are
responsible for:
calling the memory allocation function
making sure that the casting is done right
making sure that the memory is released when the work is
done
If you notice, in the managed world, all this housekeeping
is done by the CLR, as explained above, relieving the
programmer of the burden.



<B>Unsafe code</B> is a kind of cross between the managed
and unmanaged codes
It executes under the supervision of the CLR, just like
the managed code, but lets you address the memory
directly, through the use of pointers, as is done in
unmanaged code. Thus, you get the best of both worlds. You
might be writing a .NET application that uses the
functionality in a legacy Win32 DLL, whose exported
functions require the use of pointers. That's where unsafe
code comes to your rescue

So
a) Both VB.Net and C# produce IL and IL is definitely run
under the managed context.
b) In the case of win32 or COM they run outside the
managed environment.
c) Unsafe code can be written in C#(using unsafe blocks)
but NOT in VB.Net. this is the only difference btwn the
two in this context
d) Unsafe Code also runs inside the managed environment
(remember UnSafe Code is written inside a C# program and
C# code always runs as managed code), but as a deviation
from a normal managed code, it allows use and manipulation
of pointers, which makes it powerful(and dangerous if u
dont know wat u r doing). As you use direct manipulation
of pointers, you normally pin(fix) the memeory location of
the variable inside unsafe code(lest the CLR mess up with
the reference during GC and heap compact operation and u
ask "who moved my cheese" :) )

Now back to the original question. Though i have worked
on java for quite some time and C# was easy for me to use
(semantics-wise), i still remain(n honoured to be) a VB
Buff. lets map the technical capabilities to the
requirements now..

a) Learning Curve : If ur developers are with VB
background, then stick to VB.Net(forget those holier-than-
thou guys who smirk at VB programmers...) But if ur dev
base is java familiar go ahead with C#(its as good, after
all MS made both the languages :) )

b) COM Interop & Late Binding : If you are using COM, one
thing tht might need in your programs is the concept of
late binding. If so VB.Net is the way to go as it fully
supports late binding, whereas achieving it in C# is a
pain in the butt

c) UI : Somehow i always feel that UI designed in VB.Net
is more user-friendly(and aesthetic) than a form designed
in C#. Probably this is just coz im nostalgic, but still
my feeling is strong in this regard

d) UnManaged Code : If you are going to call UnManaged
Code like Win32 APIs(NOT COM components, as COM interop is
supported in both C# and VB.Net), then C# is th way to go

e) Unsafe Code : As explained C# is the way to go

hth

regards,

sr
 
Hi

"d) UnManaged Code : If you are going to call UnManaged
Code like Win32 APIs(NOT COM components, as COM interop is
supported in both C# and VB.Net), then C# is th way to go"
--->
Sorry !!! Correction. It should have been MC++ instead
of C#. Robert -> Thanx for pointing out. Now lemme
explain why i recommend MC++ more than C#/VB.Net

Both C# and VB.Net can very well call the win32 dll
functions, through PInvoke(VB.Net using the Declare
Statement and in C# using the DLImportAttribute
[incidentally u can use DLLImportAttribute in VB.Net also])
PInvoke provides a direct way to use C-style functions in
existing native DLLs in a managed application.

MC++ also can use PInvoke(DLLImportAttribute Class), but
another feature called IJW("It Just Works") takes the cake.

In contrast to languages like C# and Visual Basic where
explicitly using the PInvoke mechanism is the only option,
developers using Managed Extensions for C++ generally do
not have to do this extra work and can just call unmanaged
APIs by including the header file and linking with the
import library. This feature is called "It Just Works," or
IJW. Do note that both IJW and the DLLImport PInvoke
attribute use the same underlying mechanism

So what i wanted to say was that if u want to call win32
dll functions a lot, you can use MC++ IJW feature instead
of writing a lot of the messy function signatures in your
managed code (in fact the recommended, but not mandatory,
way is to write a wrapper class for your unmanaged api dll
and then use the wrapper in your C# / VB.Net code). So if
your managed code uses a lot of unmanaged api dlls try to0
go for MC++

oops!!! guess this thread has deviated quite a bit from
wat pankaj originally wanted... Sorry !!!! pankaj. However
check out the other points tht i have mentioned

hth

regards,

sr
 
Back
Top