We Keep Coding

Language choices when porting a classic asp app to .NET

First, let me ask you to consider this as a real question, and not a subjective one.
That out of the way, here's my situation: We are looking to port our existing classic ASP application to .NET, but we're unsure of what language to use for the new app.
I personally would 'prefer' C#, as I'm more familiar and comfortable with that languages way of doing things, but, the original code is VBScript, so it would possibly be easier to port to VB.NET ... One possible situation I fear would be that, because the code is so similar between the two variants of VB, that we might end up getting stuck on something that is not similar between the two, even though it looks like it would work. A shift to a wholly different language might avoid that kind of situation.
Does anyone have any practical examples of this kind of situation? Insights to illuminate the issue with? Do the potential benefits of a complete paradigm shift outweigh the gains from a high degree of 'copy-and-paste-ability' ?

I have used C#.NET and just recently learned VB.NET and I have to say that once you get around the small syntactical differences, VB is also a very good language. So for you, this is a win win.
That being said, I think a syntax change will help protect the project from any careless copy pastes from the old dirty code base. I believe a fresh start with a fresh language is your best bet for a top notch re-write.

There are 10X as many questions re: C# as there are VB.NET on StackOverflow. That seems to indicate there are more developers using C#, or perhaps a more thriving community (or maybe it just means C# is harder or C# developers don't know as much).
Any gains made due to the similarity of VBScript to VB.NET are far outweighed by the fact that you need to learn the new data types, .NET namespaces, and a new style of web development using webforms or MVC (my preference).
For this reason I think the choice of language should be made independently of what was used before.

3 years ago I had to make this same decision. My preference would have been C# but we ultimately went with VB.Net because that was the closest language available to the developer base we had. All of the developers had experience with VBScript, so learning VB.Net was easier for them. While the framework is the framework and the rest is just syntax and best practices, you'd be surprised the difference in learning curve just by adding a few curly braces for VB developers (the reverse seems to be exactly the same for C# developers going the other way with an itchy semi-colon finger, learning new keywords and relearning event syntax).
You should look at your developer pool and consider what is the easiest for your team to perform development and maintenance. If this is not a serious criteria (because the developers are proficient equally in both), then I would recommend a C# approach. The primary reason is that the VBScript will be relying on outdated methodologies, but converting to VB.Net will not necessarily throw exceptions for these methods whereas C# will. It will also force you to touch every aspect of your application, which (while tedious) will provide your team an opportunity to evaluate how older methods may be refactored into more efficient processes.
Just keep in mind - the "easiest" seeming solution seldom is.

When moving to ASP.NET, I believe that less focus needs to be on the page itself, and more on how you're going to write the business logic. This is a subjective question because different units will have different results.
That said, always play to your strengths. If your team is more familiar with C# than VB.NET, use C#. If they're more familiar with VB.NET, use VB.NET. If they have no real .NET Experience, then you probably want to set up some sample projects with which they can play to see which will be easier to learn. You want the most bang-for-your-buck, and that means making sure the team is as comfortable as possible.
Further, I wouldn't worry too much about copy & paste code, as there are enough differences that any professional developer (as in one who acts professional, not just one who gets paid) will see how much he/she is changing and go back through the rest of the code to ensure it is working properly.

The difference between an ASP.NET and Classic ASP application is already so big, that it will not be an easy copy/paste port anyway.
So I think you should go for the language that you feel most comfortable with (and as another answer suggests, there is a much larger community using C# than VB.Net).

Why are you rewriting the application? What are the short and long term objectives you hope to achieve through this change?
At a high level there is not much to choose between VB and C# - both are extremely functionally rich labguages that compile to teh same IL code.
Personally I moved to C# a few years ago because the vast majority of code examples found on the net are in C#, and the programmer's best friend is the internet where you may just find that nugget of useful information that save you hours of head scratching.
In your situation, by fircing yourself to rewrite the code in a different language will force you to possible rething the implementation and therefore review carefully the code and functionality required - if yuo have the time and budget. If you are up against tight deadlines then VB would be the natural choice, but may negate the benefiots if the rewrite.

I have been in exactly this position, and I urge you not to translate the app in two ways at once--from VB to C# and from classic ASP to ASP.NET.
You have chunks of business logic in your code that will not need to change much, so why change it? You are guaranteed to introduce new bugs in the translation.
I can't count how many times I thought, "this looks exactly the same, why isn't it working?"
Just adapting your code to the new codebehind pattern will be challenging enough. A vast and worthwhile improvement, of course, but not trivial.

VB.NET and C# are so incredibly similar that technically the choice is almost irrelevant. Each language has some minor things they excel in, but overall, the two are practically identical, just with wildly different syntax.
With that said, I highly recommend going with C#, just because it's the language the .NET community really got behind. It will have the most books, websites, blogs, forums, you name it. Not having to translate the oodles of examples out there on the net into VB.NET alone makes C# a better choice. I think in my 10 years of being a .NET developer, I could count the number of people I've ran into that genuinely chose VB.NET on one hand. Most people that are using VB.NET are using it in a "stop gap" fashion, with the intention of ultimately going to C#.

Many people go for C# because they think that VB.Net and C# is only syntactically different which is just not true. VB.Net has better features for handling interactions with COM components for example, like optional parameters (these are now available in C# 4.0). But there are catches too in a line by line conversion of VB to VB.net. A very simple example is the array index. If I'm not mistaken array indexes start from 1 in vb and in vb.net it starts from 0 which causes horrible bugs. Overall, I'd definitely consider going for VB.Net even though I work basically in C#.

Convincing legacy application VB6 developers to make the switch to C#

I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.
My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.
One of the developers today specifically asked "why should we switch to C#?"
I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.
So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.
Looking forward to your input!

As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!
I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?
Why switch to .NET over VB6:
Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.
I do not believe you can create a 64-bit native application in VB6. That rules out a lot.
No new enhancements are being made to VB6.
OK, there are so many reasons I can think of, I'll probably just stop there.
Why switch to C# instead of VB.NET
Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.
It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.
In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.
Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).
VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.
I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...
As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...

I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.

This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:
C# / VB.NET comparison
As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:
Wikipedia article listing advantages of C# over VB and vice versa

The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.
Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.

"Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts." (#Markle)
I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)
I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."

I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.
A quick search on SO careers:
92 job postings for c#
11 job postings for vb.net
1 job posting for vb6

reasons why VB6 developers should switch to C#
Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:
C# developers get paid more than VB.NET developers, for doing exactly the same thinking, just typing different source code after doing that thinking
Also
ReSharper for C# is better than ReSharper for VB.NET

Other than technical / social advantage is more business oriented,
Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon.
Moving to a new platform in this case make more business sense.
Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.
Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.
On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.

The biggest advantage C# has over VB6 proper has got to be inheritance.
(OK, to be fair it's my personal favourite, so I am totally biased.)
Other advantages:
Formal accessors
Exception types (I don't think VB6 has exception types, but please correct me if I'm wrong)
Generics
Lambda expressions
And the following are more related to the .NET platform than languages themselves:
Very rich library
Visual Studio refactoring and other goodies
Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897

VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.
I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.

Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
That proves nothing.
VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing.
But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone).
The market pretty much demands C# over VB.net.

Going from C# to VB.NET - Resources?

Though I have worked with Visual Basic in the past (VB 4, 5, and 6), ever since the .NET framework was first released I have been working in C#. For an upcoming project I am being asked to work in VB.NET so I am trying to come up to speed with VB.NET. Can anyone recommend any resources (books, articles, etc ..) targeted towards C# developers who are looking to quickly become familiar with VB.NET?
EDIT: I feel I should emphasize, due to certain comments, that I am not trying to compare the various worth of each language (C# vs. VB.NET). Such a comparison wold be subjective in so many ways. Rather, I am saying I myself am not that versed in VB.NET and am looking for resources that would enable me to learn VB.NET considering my experience is with C#.

Never, ever forget this when you're doing boolean logic:
AndAlso instead of And
OrElse instead of Or

Just dive in. Seriously, that is the best way to learn. Functionally, they are mostly the same these days.
For me, the major differences are
lack of support for iterators (yield return) in VB.Net (coming in the next version)
XML literals in VB.Net are not available in C#. As a C# developer, many times I prefer VB when working with XML these days...
linq query syntax behaves differently in VB (richer at first sight in VB, but much more consistent in C#)
Other than that, it's mostly just syntax
Oh, and don't forget to put Option Strict and Option Infer on... If you need dynamic, you can 'sort of' get the same by turning off Option Strict (I recommend doing this at the file level).

Here is a link that compares the two languages: http://www.harding.edu/fmccown/vbnet_csharp_comparison.html
In truth with .Net 4.0 they are pretty much the same. The syntax is different (obviously), but their functionality is nearly identical. This is now by design, Microsoft plans on co-evolving them from now on, so new features will be added to both.

I work with both, if you know C# and know VB6 syntax, it'll be easy to pick up (I started with C# since I have more of a C++ background, but I also had some VB6 so it was very easy to start working on VB.Net as well).
There's a few things you'll have to look up every now and then but as Kevin says, they're more or less the same language. And anyway, the languages themselves aren't that big so aren't very difficult to learn, it's learning the .Net Framework that takes a lot of time, so you know what's already written and where to find it, and your knowledge of that transfers across.

go to msdn Visual Basic Developer Ceneter , you'll find tons of information there
http://msdn.microsoft.com/en-us/vbasic/default
here is a learning guide
http://searchwindevelopment.techtarget.com/tutorial/Choosing-VBNET-or-C-Learning-Guide

Google is good for checking syntax differences (search "C# keyword equivalent in vb.net"). MSDN is good about having code examples in both VB and C# too.
This online conversion tool can often be helpful too.

Besides the short circuit operators, one thing that can trip you up is not initializing your variables. It seems like you don't have to, but if you are in a loop you actually do have to.

F# or C# for personal Silverlight project?

I'm about to start working on a rich-internet-application project for a student organization at my university. I will be the only programmer, and what technologies to use is totally up to me. I've already decided on going with Silverlight, but I'm not sure whether to use C# or F#. Here are some of the things I'm keeping in mind:
C#:
I already know it and have used it extensively with Silverlight at work. I have no F# and little general FP experience.
Some say the OOP paradigm works better for complex stateful UIs.
Maintenance: I'll be in school for three more years, but after that if the app is still in use they may have a better time finding someone else to maintain it if I use a more common language.
C# experience is probably more valuable in the "real world".
F#:
The main reason is I want to learn something new. Functional programming languages seem pretty cool (I find myself using the FP features of C# very often, and think they're the biggest improvement in C# 3.0). I think I'd have a lot more fun if I used F#, but am I being unrealistic in thinking the cost in time and effort might not outweigh the benefits?

In my opinion, when you are a student, you should be trying to put your fingers in as many pots as possible.
The more languages you play with, the more understanding you will have of the "best" ways of doing things in a specific language.
As for "experience" being more valuable in the "real world". Personally I only ever consider true commercial experience when looking at potential candidates. Experience in a language when you're in a job and being paid is extremely different to experience in using a language when learning / studying it. Things you do whilst studying are about gaining skills and knowledge whereas things you do in a commercial environment give you experience in solving real life problems.
Bottom line... play with the cool stuff whilst you still can!

Because you expect to create something useful that will live past your tenure as maintainer, I would suggest writing the majority in C#. What you can do to scratch your new-technology-itch, though, is pull out distinct, well-defined components that don't interact directly with the UI and write those in a separate F# assembly.
I've done something similar with a project that I've open sourced in the past. My fundamental UI logic (in this case, the V-VM parts of the M-V-VM) were in C# because it works so well with WPF technologies. Then, certain functionally-oriented components of the Model itself I broke out into a separate assembly and wrote in F# just to get some limited exposure to the language.
It's not a jump-with-both-feet approach to learning technology, so I probably didn't learn as much as I could have. An F#-only project wouldn't have taught me nearly as much about exposing F# functionality to the greater .Net world in a friendly way, either, though.
No matter what, the key in a situation like this is for you to have fun and enjoy what you're doing. :)

You can make F# business logics project (a dll).
And then the user interface in C#. And in user interface project you can add a reference to the F#-library.
This is a good solution in general when using Silverlight: The power of F# is (functional) programming but currently C# will have a better tool-support.

I know it's not in your list, but if you're interested in learning something new, you might consider GWT - You write your client in Java (which ought to be an easy jump from C#), and then the compiler turns the client side into JavaScript. Should be a bit more cross-platform compatible than Silverlight, and it's an interesting fusion of technologies (CSS, JavaScript, and Java aren't going anywhere in the near future).

I just gave a talk about programming reactive Silverlight applications in F# at London F# user-group meeting. The recording of the talk (and samples) are available here, so you can take a look at that.
Here are a few points you could consider:
I think F# has some very nice features that make programming this kind of applications more elegant than in C# (for example, you can nicely model program as a state machine and encode this direcly in code).
F# is still relatively new, but I believe that there is a decent chance that finding someone familiar with F# after three years will be much easier than today (and finding younger students who are interested to learn something new should be easier :-)).
I was surprised that there is already quite a demand for good F# programmers in the London area. This will be probably different in different places, but I think that F# is becoming a "nice-to-have" feature on CV for some jobs.

I'm presuming that this will be used in an intranet environment. Otherwise, I'd question whether the choice of Silverlight is really the best due to market penetration.
The second point I'd raise is that one of the really key skills for most web developers is Javascript. (Nowadays, that would be Javascript with a library like JQuery to manipulate the DOM, simplify AJAX, etc.) unless the application is particularly complex, there might be some merit in considering DHTML+Javascript as a starting point, and only looking at other technologies if it proves too much for that.
However, if you're set on going down the Silverlight route, then C# is by far the most likely to be supported. If you're still learning, then it's also the route that has the best documentation. F# has some excellent documentation around, but unfortunately not nearly as much as for C#.
You briefly mention the time and cost commitment. Unless you're quite comfortable with functional programming, F# is liable to take significantly longer, in part due to unfamiliarity and in part due to the amount of reference documentation to help you on your way.
While it it undoubtedly good to have knowledge of a range of programming languages under your belt, what's more valuable to most employers is a solid understanding of their language of choice - so diversifying too much can miss that. When looking to learn an unfamiliar programming language starting with something like solving Project Euler problems may present a better way of starting out, rather than diving straight into a major project with a new language. If you start in C#, you can always create an F# project that implements functions more suitable for its focus, and reference it from the C# one, to dip your toe in its waters while not automatically committing a lot of additional time to it.

ASP.NET - C# vs VB.NET - Indirect differences and things you might not initially consider

I'm not interested in starting another "who has the bigger member" VB vs C# debate (https://stackoverflow.com/questions/158229/what-are-the-pros-of-vb-net seems to cover that already) though I am interested in indirect differences which may influence developing in one vs the other. All my commercial .NET development was desktop apps in VB until the last 3 months where I had a web project and decided it was a good opportunity to force myself to learn C#. In the course of doing so I've noticed a few non-technical differences:
A lot more mature open source apps and thorough examples are available in C# than for VB.
Third party vendors of add-ins for things like refactoring and documentation tend to support C# better than VB (if at all), with VB support for similar features from comparable C# versions often lagging behind or absent.
ASP.NET jobs targeting C# seem to pay around 15-20% more on average than otherwise identical jobs in VB (at least in Australia, looking on seek.com.au and careerone.com.au for reference).
The jump to ASP.NET, MVC and C# presented a lot of speed humps at once but I think was well worth it. The decision I need to make now is whether to put more energy into pursuing C# for future .NET development or if I might as well stick to VB. Are there any other points of difference between the language (other than direct language feature comparisons already covered) that one should consider in this instance?

I find that VS does more automatic code completion for VB than C#.
It's very useful to know both languages and I personally have to get better acquainted with C# so that I'm comfortable applying for C# jobs which should triple my options.

At the Microsoft 2009 Mix Web
developer conference, all the
presentations that I attended
included code examples in C#, not VB.
In StackOverflow, notice how
questions tagged c# largely outnumber vb.net and
vb.
John Skeet wrote C# in Depth, not VB in Depth.

One thing that has been widely stated when I have participated in hiring (both as a hiring manager, as well as a candidate) is that C# and Java are close enough that converting a candidate from one to the other is fairly easy, and that this is not true for a VB.NET candidate to C#, or Java. This statement has even been extended to C++, saying training a C# or Java developer (to code in C++) is easier than a VB.NET developer.
Though I tend to disagree (I think it is more about how the person sees programming in general) I know that several large, reputable firms will accept candidates for C# or Java jobs that list C++, C# or Java experience. These same firms will in general not look at candidates who only list VB.NET, or list VB.NET as their primary language.

Specifically for web development, becoming proficient in C# made writing javascript (and doing complex things using jQuery) much easier because the syntax is so similar.

I agree with your points, particularly the first. I would add that it seems there are more C# developers out there than VB.NET. If you are looking to hire another developer, you may get more (quantity or quality) from the C# pool. And employers, perceiving that C# is more popular, will go in that direction, and there will be more demand for C# programmers (hence the higher salaries/rates you noticed)

I know that this is an old post but I'd like to add one other factor: all the new stuff gets done in C# first. This comes from my experiences with early WPF development. All the examples where in C# and we were working in VB.Net. It just took extra time to translate. Another example is lambdas, initially you could use expressions (single line) or statements (multi-line) in C# but only expressions in VB.Net.
When .Net was first rolled out, I think that there were a lot of VB6 folks who didn't really get .Net and that it was a whole different animal. I think that those people were partially responsible for the negative perceptions of VB.Net. But that was 10 years ago now and no longer a factor.