Develop in C# but deliver in VB.NET_问答_开发者

We are an team that are dedicated C#, a开发者_JAVA技巧nd 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.