Learning C# as a VB.NET programmer - c#

I am looking to switch to C#. I come from a C / C++ background but C# is a little different for me. I am switching mainly because of Silverlight and MVVM; all examples are in C#. Any information is in C# and I am confused when I read through it all.
What is a good place to start learning C# when starting with existing C / C++ knowledge?

Start writing code in C# ASAP. Only way to learn the language is to write it. You already understand VB.NET. You've got a huge lead on anyone new to .NET.
Take a smallish application you've written in VB.NET and methodically change it over to C#.
You'll learn the syntax, etc. quickly.
Write all of your future projects in C#. Just force yourself into the change and you'll do fine.

Read the best C# books. :)

The Wikipedia article "C Sharp (programming language)" is a decent introduction to C# as a language.

Shortly after learning VB.NET I decided I'd rather be coding C#. I learned it by reading a couple of books and working on a project. Slowly, I got my coworkers converted over to the language from VB.NET as well. The languages are very similar, some code conversion is just a matter of changing syntax.
However, if you've ever worked with a true VB'er you will see VB specific functions used in their code that'll make you scratch your head. There are string handling functions and casting functions for example that you will have to convert. Also, C# has no RaiseEvent. Events take a little more effort to understand in C# because you need to wrap your mind around delegates (C++ function pointers/callbacks). As others have said, if you are coming from C++ this shouldn't be too difficult.
Many people go on about needing to work on a project to understand a language, which I agree with. However, there are features of languages which you will never know about if you don't pick up a couple of books and read about them. I've been able to show my coworkers many useful techniques just by reading a couple of books.
Lastly, C# is a great language. I was very skeptical when I first started using .NET, but now I know that MS got the right talent together for that framework and language.
Good luck.

As you know C++ (as you wrote in the question) and VB.Net (as you mentioned in the title), C# won't be hard for you if do know them both well. If this is the case, just grab any source in C#, and read it.
By the way, the article from wikipedia is a very nice intro.

One thing that may work for you is to use a converter
Write your desired code in VB.
Paste small pieces of code you don't know how to write in C# into http://converter.telerik.com/ and convert.
Manually type the result into your C# project.
Gradually, reduce your reliance on converter as you become more familiar with language.
That is enough to get you started, however C# has language features that VB does not, or VB offers in a way that is so wordy that no one really uses it.
The more features you will come across as you look at code examples from around the web (like on stack overflow), and you need to either look up syntax or function manually, or convert from C# back to vb to understand what it is doing (use same converter). Or, just paste it in and see what it does.

Related

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#.

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.

Should C# and Java incorporate each others syntax?

I've been jumping from C# to Java an awful lot and the "differences" between the two are a bit of an annoyance.
Would it be possible to write a set of extentions/plugins that would merge the two languages syntaxes.
I'm talking about adding either IDE support or using language constructs that would for example:
treat these two lines equivalently:
System.out.println("Blah");
Console.out.writeline("Blah");
Automatically notice that when you type in string you mean String
Recognise common API calls and translate them in the background.
The end goal being to be able to write a java/C# program and to pick at compile time which VM/Runtime you are targeting.
If you could do this would it be a good idea?
If not why not?
The two languages are so similar it's painful in some aspects but in other aspects they are really different.
I've seen Code that will translate a C# project into Java and I'm assuming there is probably the reverse, what I am proposing is a middle ground, so we can all just "get along".
No, absolutely not. Certainly not in the languages themselves (as implied by the title) and preferably (IMO) not in the IDEs (as requested in the body).
They are different languages. The idioms and conventions are subtly different. I don't want to be thinking in Java when I'm writing C# or vice versa. I believe developers should be actively encouraged to separate their thinking. It's not too hard to switch between the two, but that switch should be present, IMO.
While I totally agree with Jon Skeet, if you must have this why not create your own library of Java API so you can create System.out namespace which has a method call printLn which calls Console.Writeline()?
That gets you close to what you want.
Just because Java and C# share some similar syntax you need to see past this and think in terms of Java Platform and .NET Platform. The two are distinctly different, so my answer is definitely not.
There actually already is a Java language for the .NET framework, developed by microsoft: J#
This way you get the java-syntax but you are still developing with the .NET framework.
But i am not recommending anyone to use it.
I knew Java before i knew C# so i tried out J# because i thought it would be an easier transition. At first I liked it but after I tried C# I'm never going back. First of all, nobody uses J# so it's kinda hard to find examples and tutorials. Second, C# has (IMO) much more convenient syntax, specially for events, properties, lambda, anonymus methods and alot of other things, it's also being updated every now and then with even more syntax sugar which i don't think J# is.
Maybe if you often write Java and sometimes have to write a .net app it might be a good option.
I think no. I also switch from java to c#. But if the syntax is identical was is to stop someone from trying to compile c# in a Java compiler, or vice-versa.
Visual Studio actually ships with a Java to C# converter, which tries to do some of the things you mention. Unfortunately it fails miserably (1) for anything beyond the simple hello world application.
Despite being very similar on the surface, there are many significant differences between Java and C#, so you would achieve very little by doing what you suggest imo.
(1) To be fair, it actually does a fairly good job if you consider the limitations given for such a task, but in practice the resulting code is of limited use and you have to do a lot of clean up after the conversion.
Firstly what you are describing is not a difference in language syntax but a differences in class libraries. Both languages are relatively simple in terms of keywords and features but understanding or knowing the libraries and how they operate requires considerable learning.
The mistakes you are describing are things that the developer should not be making to begin with - the IDE should not be guessing. There are going to be many cases where you can't easily / trivially translate between java or dotnet. In the end a skilled developer learns and knows when and which class libraries to use.
Actually in the beginning there was no dotnet - microsoft was behind java. They however proceeded to change java in ways not compatible with the java plstform standard. To paraphrase sun sued microsoft and won I'm court. Following that ms proceeded to create dotnet and particularly c# which became microsofts VM platform. Of course along the way a whole stack of things got changed. Microsoft introduced many things which broke Javas run anywhere etc. They have done the same thing with dotnet which have cause problems for the mono team to be able to faithfully reimplemwnt everything for other non windows platforms.
• String vs string.
• lowercase method names (java) v uppercase method names(dotnet).
• Giving java keywords new names - "package".
In the end dotnet was microsoft response so they can control the platform and do their own thing instead of following a standar

Learning C# after C++

In a progression of languages, I have been learning C and C++. Now I would like to learn C#. I know there are some drastic differences between them - such as the removal of pointers and garbage collection. However, I don't know many of the differences between the two.
What are the major differences that a C++ programmer would need to know when moving to C#? (For example, what can I use instead of STL, syntactic differences between them, or anything else that might be considered important.)
C# for C++ Developers is a great place to start. It is a table that lists the most important comparisons between the two languages.
Once you have explored some of these differences, you might choose a self-contained project you have written in the past in C++, and re-write it in C#. In your first pass, you will probably just end up translating directly across, using the same design and algorithms. As you become more comfortable with C#, you will recognize ways to take advantage of language features only available in C#, as well as the incredibly versatile .NET Framework.
I think it's important to note that pointers weren't really removed from C#, but that they still exist, they are everywhere, and they are called references.
Charles Petzold has a .NET Book Zero that is designed specifically for the C/C++ Windows programmer who wants to learn C# and .NET. It is a free PDF download from his site. All of the source code used in the book is available as a separate Zip-file download.
There was a similar question that has lots of pointers (pun inteded :-)) and resources about the differences between C++ and C# and what to pay attention when learning transitioning - Linux/C++ programmer to Windows/C# programmer.
Look at the Generic collections and LINQ (all the related technology to LINQ) for STL like functionality.
The number one thing to note is that ~/Destructor is c++ is nothing like the ~/finalizer in c# -- See IDisposable/using.

from C++ to C#

What are good c++ to C# articles/tutorial or books?
I am reading http://msdn.microsoft.com/en-us/magazine/cc301520.aspx and will read http://andymcm.com/csharpfaq.htm and http://www.ondotnet.com/pub/a/dotnet/2002/02/11/csharp_traps.html afterwards. Have any of you read any good books for ppl who have a strong understanding of programming && || C++ on the C# language (and libraries)?
It would be helpful to have the C# Language from Microsoft (not ECMA) specification with you to guide you with the syntax changes between C++ & C#.
download C# Version 3.0 Specification (.doc) here
Absolutely the best place to find information about C# is MSDN.
I recommend you follow the C# tutorials listed here: C# Tutorials on MSDN
I was also a C++ dev before I started doing C#. Those tutorials will get you up to speed.
Read about .NET as well.
Also, I forgot to mention the specification:
C# Language Specification on MSDN
It's worth reading through so you know some of the not-so-obvious differences between C# and C++ (for example, structs are pass by value whereas classes are pass by ref), and usage of 'out', 'ref', and other keywords. Just an example :).
I am currently reading Jon Skeet's C# in Depth. It is the best treatment I have seen for C# 2 and 3. If you are an advanced C++ programmer and you have some familiarity with C#, this is the book to take your C# competence to mastery.
Jon provides insights into the evolution of C# and insights into the various new language features. Not just the "hows" but also the "whys". Again, approach it after reading a beginning C# book. It doesn't cover the basic stuff which is covered many times by numerous other C# books.
I'll second the suggestion for CLR via C#, it is without doubt one of the de facto books one would expect any competent C# programmer to have read. Also, coming from a C++ background it will answer your questions about how things work in a managed environment.
I often find that personal experience provides the most insight into language differences. One can read all the theory written about a new programming language, but without experience this doesn't help much.
I'd recommend downloading Microsoft Visual C# Express Edition (http://www.microsoft.com/express/vcsharp/) and trying it out with a few simple programs. Start with "Hello World!" and work your way from there. (I know this can be tedious, but it helps to build a solid grounding in a language you are unfamiliar with). Once you have a solid feeling for the language, you should be able to focus your efforts (and questions) toward more specific language differences.
I recommend Accelerated C# book for programmers who's came from C++ and Java Languages.
Personally when I had to learn C# I would type the name of what I was looking for in the C++ term and tack on C#. For example:
std::vector C#
which gave me several pages dedicated to explaining lists and other types in C# that did what that exact code did in C++. Worked fairly well, even for some of the lesser used parts of the STL/Templating library.
If you're coming from C++, I think the best book to start with is CLR via C#. It will give you both a solid introduction to C# while also acclimating you to life in the CLR. The latter may be more of a stumbling block for someone with a solid C++ background.

Categories