C# for VB.NET Programmers

[Scott McNair]

Is there a good tutorial for VB.NET programmers looking to migrate to C#?
I've found several tutorials that assume that the person is new to
programming in general, and I've found a few that assume that the person is
migrating from C++, but I have yet to find any that cater to the
experienced VB.NET developer.

I've found a quick reference that compare the language structures of the
two (http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html)
but ideally I'd like to find some tutorials as well.

Also, why are C# developers so adamantly opposed to the WITH statement? I
just wrote my first C# web app, and I had about 20 lines of code that all
referred to properties of uwgOrphans.HeaderStyleDefault.Style. I wound up
just hand-keying it all, but in this case a WITH-like statement would have
saved about 700 characters. I've read of alternatives, but they're either
not recommended (in the case of USING) or they don't carry the Intellisense
(in the case of passing it to another method). I'm not looking to gripe or
to start a flame war, I'm just curious as to why C# developers as a whole
don't like the idea of even having it present as an option.

Regards,
Scott McNair

 

[Marina Levit [MVP]]

I developer mostly in VB, but I don't like the 'with' statement either. I've
also found it harder to read the code with the variable name missing. If I
use a variable a lot, I copy it, and paste it so I don't have to type it out
all the time. But for me, having the entire variable there, every time,
makes it far more readable. Plus, I don't like the extra level of indenting
that comes with having a 'with' statement.

 

[Alan Pretre]

Is there a good tutorial for VB.NET programmers looking to migrate to C#?
I've found several tutorials that assume that the person is new to
programming in general, and I've found a few that assume that the person
is
migrating from C++, but I have yet to find any that cater to the
experienced VB.NET developer.

There is a book called "The .NET Languages: A Quick Translation Guide" by
Brian Bischof. It is very helpful for translating the VB.NET stuff into
C#.

http://www.amazon.com/gp/product/18...ef=sr_1_1/102-9426835-7225700?ie=UTF8&s=books

-- Alan

 

[Guest]

Scott,
Actually I believe one of the best tutorials on moving from VB.NET to C# is
to use Reflector and decompile your VB.NET Stuff into C#. Not only great
practice, but it will instantly make you fully aware of the vagaries of
vb.net (especially if Option Strict and Option Explicit weren't set to "On"!
Peter

 

[Brian Gideon]

Is there a good tutorial for VB.NET programmers looking to migrate to C#?
I've found several tutorials that assume that the person is new to
programming in general, and I've found a few that assume that the person is
migrating from C++, but I have yet to find any that cater to the
experienced VB.NET developer.

I've found a quick reference that compare the language structures of the
two (http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html)
but ideally I'd like to find some tutorials as well.

I'm not sure you even need a tutorial. Since you're coming from VB.NET
you already know everything about the framework. You just need to pick
up on a new syntax and language features. The C# specification would
be a good starting point. One language feature you have in C# that you
didn't have in VB.NET is anonymous methods and closures. A good
tutorial on that might be beneficial.

Also, why are C# developers so adamantly opposed to the WITH statement? I
just wrote my first C# web app, and I had about 20 lines of code that all
referred to properties of uwgOrphans.HeaderStyleDefault.Style. I wound up
just hand-keying it all, but in this case a WITH-like statement would have
saved about 700 characters. I've read of alternatives, but they're either
not recommended (in the case of USING) or they don't carry the Intellisense
(in the case of passing it to another method). I'm not looking to gripe or
to start a flame war, I'm just curious as to why C# developers as a whole
don't like the idea of even having it present as an option.

I don't think it's really needed. If long variables become cumbersome
to type you can always alias them by declaring a shorter variable name
that references the same object. I always try to use the actual
variable name though. It may require more typing, but it's also more
readable.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Is there a good tutorial for VB.NET programmers looking to migrate to C#?
I've found several tutorials that assume that the person is new to
programming in general, and I've found a few that assume that the person is
migrating from C++, but I have yet to find any that cater to the
experienced VB.NET developer.

I've found a quick reference that compare the language structures of the
two (http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html)
but ideally I'd like to find some tutorials as well.

Find a good VB.NET to C# converter and use that.

If in doubt write the VB.NET, translate and view the generated code.

Also, why are C# developers so adamantly opposed to the WITH statement? I
just wrote my first C# web app, and I had about 20 lines of code that all
referred to properties of uwgOrphans.HeaderStyleDefault.Style. I wound up
just hand-keying it all, but in this case a WITH-like statement would have
saved about 700 characters. I've read of alternatives, but they're either
not recommended (in the case of USING) or they don't carry the Intellisense
(in the case of passing it to another method). I'm not looking to gripe or
to start a flame war, I'm just curious as to why C# developers as a whole
don't like the idea of even having it present as an option.

Dont ask me.

I like the WITH (even though I have mostly used it in Pascal).

Arne

 

[clintonG]

Very pragmatic choice you've made...

O'Reilly's "C# & VB.NET Conversion Pocket Reference" covers syntax, grammar
and usage.
I wouldn't rule out the QuickStarts either as you can toggle between C# and
VB.NET right in the page.

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP 43°2'17"N 88°2'37"W : 43°2'17"N 88°2'37"W

 

[Guest]

Find a converter you like.
One that knows that:
"is" is not equivalent to "Is"
"typeof" is not equivalent to "TypeOf"
"!" is not always the proper equivalent to "Not" (sometimes you need "~")
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
C# Code Metrics: Quick metrics for C#

 

[Jon Skeet [C# MVP]]

Also, why are C# developers so adamantly opposed to the WITH statement?

Because it makes it less clear what's going on.

I just wrote my first C# web app, and I had about 20 lines of code that all
referred to properties of uwgOrphans.HeaderStyleDefault.Style. I wound up
just hand-keying it all, but in this case a WITH-like statement would have
saved about 700 characters.

So create a new variable which refers to
uwgOrphans.HeaderStyleDefault.Style, and then do all of your operations
using that variable.

I've read of alternatives, but they're either
not recommended (in the case of USING) or they don't carry the Intellisense
(in the case of passing it to another method).

There's nothing wrong with using a helper variable - although making it
as short as possible would go against readability. We'd have to see the
exact code to know quite what the best solution would be, of course.

 

[Jon Skeet [C# MVP]]

I'm not sure you even need a tutorial. Since you're coming from VB.NET
you already know everything about the framework. You just need to pick
up on a new syntax and language features. The C# specification would
be a good starting point. One language feature you have in C# that you
didn't have in VB.NET is anonymous methods and closures. A good
tutorial on that might be beneficial.

I wish C# really had closures. Anonymous methods are close, but you
need an appropriate delegate to start with. That makes life a bit more
restrictive than in languages such as Groovy and Ruby, as well as
making features like currying unlikely.

Maybe some time we'll get full closures...

 

[Barry Kelly]

I wish C# really had closures. Anonymous methods are close, but you
need an appropriate delegate to start with. That makes life a bit more
restrictive than in languages such as Groovy and Ruby, as well as
making features like currying unlikely.

In C# 3.0, from what I see, the overloaded generic Func<...> types are
effectively a way of getting around the type-by-name problem with
existing delegate types, but they won't help with all the existing
delegate definitions - you'd have to use the Func<...> etc. everywhere a
custom delegate is used now.

Perhaps it could be fudged with an automatic coercion based on
underlying compatibility.

The looseness of Ruby / Groovy etc. comes more from duck typing than it
does from their implementation of closures being different from C#'s.

Maybe some time we'll get full closures...

C# does have full closures. What it doesn't have is an easy way to
convert delegates, even where they're structurally compatible.

-- Barry

 

[Jon Skeet [C# MVP]]

In C# 3.0, from what I see, the overloaded generic Func<...> types are
effectively a way of getting around the type-by-name problem with
existing delegate types, but they won't help with all the existing
delegate definitions - you'd have to use the Func<...> etc. everywhere a
custom delegate is used now.

I can't remember off-hand - are they just declared to return object? I
need to have another look at exactly what can be done easily with
anonymous methods...

Perhaps it could be fudged with an automatic coercion based on
underlying compatibility.

The looseness of Ruby / Groovy etc. comes more from duck typing than it
does from their implementation of closures being different from C#'s.

Well, there's no "general" closure-type - unless you count MethodInfo,
and even that doesn't allow for the kind of "runtime overload" that
Groovy's closures provide (which, I agree, is due to duck typing).

C# does have full closures. What it doesn't have is an easy way to
convert delegates, even where they're structurally compatible.

I think it depends on exactly what we mean by "having closures", and
that's not a debate which is particularly useful

 

[Barry Kelly]

I can't remember off-hand - are they just declared to return object? I
need to have another look at exactly what can be done easily with
anonymous methods...

The return type and the parameter types are all generic parameters, so
given a Func<...> generic overload with enough generic parameters (I
think they go up to 9 or 10 or so), it can match any method signature.
Thus, with implicit conversions, it would be possible to write
relatively general library routines that did things like currying etc.
(You'd still need a bunch of overloads, but you'd only have to do it
once...)

Well, there's no "general" closure-type - unless you count MethodInfo,
and even that doesn't allow for the kind of "runtime overload" that
Groovy's closures provide (which, I agree, is due to duck typing).

Well, you could just about do that with 'params object[] args' if you
needed to, and is something I've done in the past.

I think it depends on exactly what we mean by "having closures", and
that's not a debate which is particularly useful

Well, I think closures are historically based around the closure of the
lexical scope - that variables in the outer scope are captured by the
closure and live on as long as the created closure does.

-- Barry

 

[Michael D. Ober]

I don't know if this is true in VB 2005, but in VB 6 using the with ... end
with block actually improved the speed of a program and was one of the
performance suggestions from Microsoft.

Mike Ober.