We are an team that are dedicated C#, and will start with an new project, there the customer really wants it in VB.NET.
Are there a bad choice to do the development in C# and then convert it and deliver in VB.NET.
Are there any tools that will make this easier to us than any simple converter?
I wouldn't recommend using a converter for a whole project. They're OK for code snippets and perhaps a class at a stretch, but even with two languages like C# and VB.NET based on a common runtime there'll be things that can't be converted.
As I see it you have the following choices:
Convince the customer that writing the application in C# is for the best - it's the language you know and you'll be able to deliver a higher quality product in a shorter time.
Write it in VB.NET, but point out that it will take longer to deliver.
Don't take the project. I'm assuming that this is not an option, but I'm including it for completeness.
Each language has its unique features and specialties. It is an illusion to believe that code written in C# can seamlessly be converted to VB.net. If you do automatic conversion, you'll have to fix it manually afterwards (because it is unlikely that your project will compile) and it will have poor quality, look bad and not be optimized.
I think it is a bad idea to rely on automatic conversion if your customer wants a solution in VB.NET. The code written by an automatic converter will often use a bad coding style for that language - even if the end result is the same.
It might be OK to use an automatic conversion tool occasionally to aid the development process if you are unsure of the exact VB syntax for a C# construct. You should check the result of the conversion is a best practice in VB.NET and not just copy and paste converted code without reading it. Conversion tools can make errors or produce ugly code that a human programmer would not write. Code committed to the project should be reviewed, preferably by one of the team members with the most experience in VB.NET.
You should strive to use the best practices for VB.NET so that your customer can easily understand and maintain your code.
If you feel that your team is unable to complete the project to a high quality in VB.NET then as ChrisF mentions you might want to consider:
Declining the project.
Convincing the customer to accept a high quality C# solution instead of a low quality VB.NET solution.
Alternatively you could try to gain the competences in VB.NET you are currently missing. Some examples of ways to approach this:
Attending courses on VB.NET so you at least know the basics.
Buying and reading books about programming in VB.NET.
Employing a new team member with VB.NET experience.
Using a consultant in the initial phases to help start your project and review code until your team is able to produce high quality VB.NET code on its own.
Attempting a smaller project in VB.NET first to gain some experience.
Are there any tools?
Kind of. I don't like any of them, as they don't look "trustworthy", but you can try your luck:
http://www.developerfusion.com/tools/convert/csharp-to-vb/
http://www.carlosag.net/Tools/CodeTranslator/
http://converter.telerik.com/
Would I recommend simply translating VB to C# ?
No. Because you're forced to trust in a converter. VB really, really isn't that much of a stretch from C#. If you are doing simple things, it should be pretty easy.
Regardless of your reasoning, it is possible to do this. Use RedGate's reflector http://www.red-gate.com/products/reflector/ and Denis Bauer's disassembler http://www.denisbauer.com/NETTools/FileDisassembler.aspx. You can pick your language, and the code that comes out, while not exactly what you coded, should compile back to the same IL.
You can decompile your C# binaries with JustDecompile export it as VB.net project, load the project file in VS and build.
This, however, does not usually work out of the box as you may have to fix some minor issues like:
Anonymous Types
Indexers
reimplement "unsafe" code
As you can adjust your (existing) C# test project to test the converted project along with your original implementation.
After fixing that you have the advantage to know your VB builds and runs well, which cannot be guaranteed by any automatic converter.
Related
I'm going to migrate my Android application into WP7 platform. Android one contains heavy enough calculation stuff (encryption/decryption), plus extensive usage of DB (SQLite) and some graphics (simple) and I'm trying to figure which language to select: either C# or VB
I have some experience both in C# and VB.net, but can't decide which one to select, any clues?
I would recommend C#, based on a couple of factors:
I assume the Android application is written in Java. Between C# and VB, C# is the most similar.
If you are doing lots of calculations, C#'s more terse syntax will probably make the code easier to read. VB is more verbose and thus tends to produce more clutter.
Since you are new to the platform, you will definitely find a lot more resources with C# code examples than with VB.
I went from VB.net to C# and wouldn't ever go back through my own choice!
Aside from the technical differences (see here for just one comparison), it's my personal opinion that C# is more readable, fluent and just plain better.
Do a search on google for heaps of comparisons on why one is better than the other. At the end of the day it's your personal preference... try both and see which you prefer.
There are no technical benefits or drawbacks to choosing either language; the complete set of APIs and platform features are available to you whether you choose C# or VB.NET, so it comes down to whichever you are most comfortable with or want to spend more time with.
The only thing that might sway it one way or another is that (in my opinion) there are more samples, blog posts, and general help written in C# than VB.NET, but that's about the only differentiator I can think of.
If you aren't particularly familiar with either then definitely use C#. By far and way the vast majority of code you will come across in the Web and in books on Silverlight will be written C#.
I'd go with C#, it's a far more popular language. Furthermore, Java to C# is an easier transition.
Edit:
Popularity of a language make's it easier to find information and perhaps more importantly, quality developers.
Choose the language you are more comfortable with.
I would suggest c# because it's more similar to java. So maybe you will manage to save code structure.
C# for sure. C# is a lot more alike Java, and syntax alike much more compatible.
Next to that C# is more popular so more resources for it, and because of the extra time they spend on C# the compiler slightly generates higher performance MSIL.
If you know Java you'll find C# very comfortable to transition to and work with, especially if you're having to maintain older Java code as well as working on the new project. I've worked in situations where I had to work with VB6, VB.NET and C# code within the course of a day and it can be tricky to remember not to use or to use semi-colons or that the variable type goes first or last.
Any one know the corresponding C# code of this
Yes, I do. Are you asking for someone on here to translate that entire VB.NET project into C# for you? That isn't likely to happen for free.
Instead, might I suggest that you try an automated conversion tool, like this one, or this other one?
But really, any competent C# programmer should be able to translate VB.NET code into C# with a little bit of effort. The only thing that's changed is the syntax; the underlying methods are all exactly the same. Anyone who assumes experience with the .NET Framework should be fluent in either language.
I am looking for a tool that can convert a PHP application into ASP.Net application either c# or VB.Net.
I tried using the 'PHP to ASP.NET Migration Assistant' from microsoft but it leaves a lot of code un coverted and doesn't even create proper codebehind files.
Any ideas or tools that you know?
It's not going to work, sorry. Not only are the languages very different (the biggest difference arguably being that one is dynamically typed and the other is statically typed), but the entire architecture of the environment is vastly different. No automated tool is going to overcome this.
Even if you can find a tool that claims to accomplish this, it's going to emit terrible .NET code. It probably won't use any of the server controls, or at least not use any of them correctly. It's going to force the .NET code to try to do things "the PHP way" and end up costing you a ton in performance and maintainability.
Basically, there's just no way, reasonable or otherwise, to do what you're trying to do. Think of it this way... Have you ever seen automated translations between vastly different spoken languages? The results are humorous to say the least, and they are not accurate representations of the target language.
You're going to need a developer (or team of developers) to do this.
I don't think you can convert automatically a full php application into dotnet, as SLaks said, these languages are very different.
I started dotnet a half year ago, after years in php, and it's really different. You cannot use common techs from php, but you can use anothers. It's a different approach with different advantages, so an automatic tool can't do this.
Maybe you can convert some general php structures with a tool, but it won't be as good as if you write it by hand. And a complete app is nearly impossible.
For example, how would you convert a native php template based view system automatically? Maybe you can achieve this (never say impossible), but you shouldn't waste your time.
You can finish it much faster by hand than searching for a probably non-existent (or not good enough) tool.
As others have stated, an automatic converter from php to c#/asp.net is going to leave a lot to be desired.
Your question got me thinking (well, googling) about php on .net. My search found this: Welcome to Phalanger 2.x.
I don't know how mature it is (though being at 2.x implies some level of maturity); but I'm thinking that with something like this you can port your code over time, while still having the app up and running and still making incremental improvements to the application.
You can now run PHP on .NET with interop using http://phalanger.codeplex.com Some genius dun it!
First of all, until now, all my programming education, has been targeted to console applications, just like everyone who starts learning C and C++. (the 2 languages i know)
Now, i want to jump to the nice graphical World.
So, I am exploring Windows Forms, i have already got many headaches trying to understand the language that it uses (quite diferent from native C++), but i managed to do a couple of things like using textbox and buttons.
Well, the thing is, i have read in many places that, in order to avoid headaches trying to code winforms in C++, i'd better "Build the GUI in C#, because it's way easier, and the logic, and code in C++". And that is my question, i don't understand that statement, at all.
What is that supposed to mean?
Also, it's C# THAT similar to C++, as to affirm that statement? Cause, if C# was too diferent to C++, i would have to learn the whole C# language
hope you understand my doubt.
PD : Sry about my bad english.
Joan, while it is certainly possible to develop an applications Front End in C# and the logic in C++ I believe it to be a huge waste of effort to do it this way since you only complicate yourself for no real benefit since you can code both things in the same language.
C# has many advantages over C++ and I personally use mostly C#, but I can clearly see many programmers who love C++.
Now going into your question regarding the similarities between C++ and C# the answer is yes and no. Yes in the sense that C#'s syntax is clearly derived from C++. Many things like ifs and for loops are written exactly the same, so if you know how to write an if in C++ you can write it in C#.
The difference (and a critical one that is) lies in the way the languages work. C++ is an strictly compiled language (it goes from C++ code to machine code). C# is an interpreted language (it goes from c# to MSIL and during runtime to machine code). In C# you can't use pointer arithmetic without explicitly allowing, in C++ you can (and will) use pointer arithmetic. C# has garbage collection, C++ does not.
In the end, as I said in the first paragraph you can use both languages to build an application, but it would be highly complicated. My advise to you is to learn a bit of C# and then decide which language you would prefer to build your GUI application. But don't believe even for a second that C++ can't be used to build a front-end since there are a myriad of frameworks for that. One I remember from the top of my head is Qt.
Another option for you is to use "C++/CLI" which is a flavor of C++ which can use the .NET Framework (the same framework C# uses)
EDIT: Thanks Jerry for pointing out that Managed C++ is obsolete and that C++/CLI is the one!
C# has braces, semicolons, and uses the concept of classes. It has "C derived" syntax, but otherwise is very dissimilar to C++. Java is really the precursor to C#, not C++.
You can build application GUIs using C#, and then use various methods of calling into C++ (such as P/Invoke). Unless you are using lots of existing libraries, or looking for absolute performance, its going to be a headache.
If you are looking for examples of modern Windows GUIs using C++, take a look at the Hilo example program.
It is not very difficult to switch to a new language. The few keywords you would have to learn are not the issue. What costs most energy if to get used to the new environment and class libraries. That is probably what you mean and it is true, you'll need some time.
Now coming to the split GUI in C# and code in C++, then you'll have to make all bindings and marshalling of parameters if there are buffers and strings for example. I don't think this would make your life any easier. Interfacing with native Dlls can become some pain. However if you use third party dlls and have already a large working codebase you could try to compile the logic code with /clr enabled. This generates a DLL that can be used from within .NET directly.
NOTE: WinForms is now out-of-date for new applications, consider using WPF instead. It scales nicely, but the learning curve might be steep for newcomers.
Please note that you have native C++ and C++/CLI, the first one is the one you have learned, but the second one is the one you will need to use if you want to combine it with a C# GUI. However, I would suggest you to stay away from C++/CLI because this will cause a lot of confusion if you don't have a solid ground in C++, C# and .NET.
The reason that you can't use the native C++ is because C# is a managed language, so you will either have to find another GUI that fits with C++ or you will have to go C# for everything. For more information about managed see the environment part of Difference between C++ and C#, the article will also provide you with a good comparison between both.
Well, this aint a direct answer but hope it will help you. Since you stated that, you are just started and you want C++ combined with GUI, I suggest you to take a look at Qt. IMO I found C++ and GUI made easy in Qt. Also it's good too.
Although it's not a direct response to the question you're asking, I'd first caution that WinForms are already basically a dead-end, so for new code you'd be much better off avoiding them. If you're going to do a GUI in .NET, the currently preferred choice is WPF.
Some people find C# an easier way to do a GUI. It's definitely true that Microsoft provides considerably more in the way of Wizards and such to do it with little or no coding if you use .NET for the job. Other people (especially those with more experience doing so) can produce a GUI in C++ just quickly (or even a little more so) using C++ instead.
Mixing languages like this can work well in relatively large projects where you have completely separate teams of people working on the different parts. For smaller projects where the same people typically work on both parts, the difference in syntax is at just about the worst possible level -- not enough different to really shift gears and think differently, but still enough different that you can't plan on just typing things and having any hope of them compiling. All in all, you're usually a lot better off picking one language and sticking to it.
At a colleague's workplace, a decision is trying to be made about whether to use both languages in the workplace or to standardize on one? There are some VB.Net developers and some C# developers.
What advantages or disadvantages would there be to using both or to using one?
Edit: To clarify this question, the question is not asking the advantages of one over the other, rather what are the advantages/disadvantage of standardizing on both languages versus standardizing on one.
For instance, one point could be that C#/VB.Net may have more third party tools available and hence it may make sense to standardize all developers on that language.
We should probably put on our Reality Glasses for this discussion. It's not just Syntactic Sugar going on here.
You will find that you can write code very quickly in Visual Basic.NET. That is largely due to some features that it has that C# does not yet provide: namely, the My namespace, which provides a plethora of functionality that C# developers have to frequently code by hand. (And that's a damned shame, if you ask me.)
I code in both languages every day. Coding event handlers for forms in Visual Basic is a snap, and it's VERY obvious what methods handle which events. It's not always as clear in C#. On the other hand, you can't always be as explicit in Visual Basic as you want to be, because Visual Basic does so much of the work for you. C# has the advantage of just getting the heck out of your way, and letting you get down to the nuts and bolts. Quite often, that's extremely liberating.
VB will let you invoke static/shared methods on an object instance. C# won't. You'll learn that the hard way when you try to port your code. C# will complain about unreachable code; VB doesn't care one way or the other.
But under the hood, when you get right down to it, it's all .NET. It all compiles down to MSIL. There will be minor differences. Visual Basic, for example, doesn't care about the case-sensitivity of names, where C# does. And the big gotcha there is that the CLR does as well. You'll realize that when you try to use reflection. Does that mean you shouldn't use VB? Nope. Just make sure you case things consistently -- especially your namespaces. (Namespace "My" and namespace "my" are two completely different namespaces to C# and the CLR, but they're the same to VB.)
Choose the language that makes you most productive, that reduces ramp-up time and maintenance costs. You may find that that means working with both languages. (We do!)
EDIT TO ADDRESS OP'S EDIT:
Refactoring tools are available for both languages.
Automated unit testing tools are equally applicable.
3rd party controls are going to be available for both languages because they're compiled down to MSIL.
Now, for IDE productivity tools, the one thing that C# has at this time that VB doesn't is StyleCop. That may change soon (and I hope it does), but I don't view it as a roadblock by any stretch of the imagination.
This is personal experience mixed with workplace lore:
VB.NET is capable of being little more nimble, compared to C#, because there isn't a standards committee (except for any that may exist at Microsoft).
Most of the Google-able code hackery out there is done in C#, and most of the best resource books provide code samples in C# only.
VB.NET is tainted with a history of VB being accessible to even the most incapable of developers. This is unfair, imho, because VB.NET is much more a "real" language. But the taint isn't going to be washed away any time soon, and "real" programmers still generally despise it.
As for real life - I code in my own time in C# and VB.NET at work. I believe that because so much of the code one writes for .NET is calls against the framework objects, the differences are actually quite small. If you can declare variables in both languages you're 80% to being portable. If you understand the framework, the syntax of the languages is a small obstacle.
EDIT to directly answer your question: We happily use both (though mainly VB.NET) and haven't ever had any problems. We use Visual Studio which allows us to pretty freely mix code files/assemblies. I would encourage you not to limit to a single language - I think some diversity is good for the brain.
My workplace had traditionally been a VB.Net shop, but a decision was made a couple years ago to switch to C#. This happened mostly because the VB developers had either left or moved into other positions and most of the new hires preferred C#. We still have a large legacy VB.Net code base, but all new development is being done in C#.
I don't think there's a strong technical reason to choose one language over the other, as they are pretty equivalent in functionality, but I do feel there are some valid reasons to choose one type of developer over the other. While I believe VB and C# are equal, there's is the unfortunate perception that C# developers are better than VB developers. While there is some justification for this, it's overblown. (It was more applicable in the C++/VB days.) That said, the perception exists. This does cause some talented developers to avoid and bash VB (though they usually do so from ignorance). I do think it's harder to hire developers into a VB shop than visa versa, because a C# developer will often balk at the idea of having to use VB, but VB developers usually aren't as opposed to using C#. There is one significant disadvantage to choosing C# over VB and that's that C# developers generally get paid more.
In my experience, the best developers welcome using both languages. The more languages you know, the better.
After tracking your question for a little bit and noting your edit, I have to wonder if you're fishing a little bit...
Either way, I think it's fairly obvious that at least the latest third-party tools favor C#. I, like the other responders, code VB for work and prefer C# for other development. I have definitely noticed that the documentation for many third-party addins/plugins and in some cases the products themselves favor C#. ReSharper, even though 4.5 has better VB support, is still vastly more comprehensive when using C#. And other frameworks, like Fluent NHibernate, don't support VB at all. So for tooling, especially when considering late-breaking stuff, I believe that C# wins. Not to mention the fact that C# got a few new features in 3.0 that won't be available until VB 10 makes a wide release.
I still agree whole-heartedly with the others; if you can do it in C#, you can do it in VB. It's all the same CLR, in the end.
I'd say given that there are "some VB.NET developers and some C# developers," there really is very little benefit to forcing everyone to use one language. Frankly even a VB.NET developer who's never looked at C# should be able to read C# code with no more than a brief introduction to the syntax, assuming he/she has a reasonable understanding of the .NET framework; and a C# developer should be able to do the same with VB.NET.
(I should also add: this is assuming everyone has access to a development environment in which the .NET languages can co-exist harmoniously -- e.g., VS2005, VS2008, etc., as opposed to one of the Express Editions, which as far as I know don't allow multi-language solutions.)
Don't fall for the "most examples / books are written for C#". Working out how to apply a C# example to VB.NET is trivial -- you'll have more trouble trying to understand what the moron who wrote the example / book is trying to do and what their hideous coding (un)convention is all about than you will mentally flipping C# syntax to VB syntax.
Also I'd say don't worry about whether you hire C# or VB.NET programmers: if they are any good at all then they won't have a problem with reading / writing both languages.
We use both here, and after a little resistance from some (we were using C++ before) have settled down fine. As I had predicted, the hardest thing for our team was (and probably still is) the conversion from MFC to .NET, not the language used to access the libraries.
FWIW our main split is VB.NET for UI code, and C# for backend / database / computation code.
C# and VB.net are the same with a different syntax. You can convert from C# to VB.net and back very easily.
VB.net does have a few extra advantages that C# does not, such as inline XML.
Most places have C# because its the more popular language.
I started out as a VB developer so naturally I migrated to VB.Net when I first worked with .Net. In fact my first .Net application was made in VB.Net too. But I tried out C# and found myself liking it better in a matter of weeks.
So I made some of that app in C# (some libraries) and it didn't hurt me. Now though I hate going back to the older VB.Net code and working on it. I really wish I could change it all to C# somehow.
That's not going to happen.
So what I am telling you here is, irrelevant of what language you choose (VB/C#) stick to it. Don't do mixed language development unless you have a compelling reason I can't think of yet :)
The advantage of standardizing on a single language is that basically everyone will have 1/2 as much to learn. I think it's better to spend the time learning more features of .NET, within a single language, rather than learning 1/2 the features in both.
As far as hiring goes, it does not really restrict you as a good VB or C# programmer should be able to switch to the other language without difficulty (or else they aren't really a good programmer :)