An easy to use and free code conversion tool implemented as a Silverlight application. You can load a file or paste VB or C# code and convert to C# or VB with the click of a button. You can also save the result back to a file on your machine.

Visual Basic and C# aren't that far apart in terms of languages and converting between them is usually fairly easy, if something of a chore. In this project we make use of a really good code conversion web service implemented by the guys at SharpDevelop. As well as their well known IDE for .NET they also run a few other projects that deserve to be better known - and the code conversion utility is one of them. You can use it to convert C# to VB .NET or VB .NET to C#. You can also convert to and from the minority language BOO - a .NET language that gets far less attention than it deserves.

Of course as this is a Silverlight application you can try it out for yourself at our Resources and Tool section .

The basic operating principle behind the converter is that it uses a syntax analyser to generate a syntax tree which is then used to generate the same code in the alternative language. What this means is that the translation should be more accurate but it can only deal with syntactically complete programs - i.e. whole classes - and it can only work on programs that have no errors.

The conversion utility has been made available as a web service and it is the basis for SharpDevelop's own instant interactive code conversion web pages. What we are going to do is implement the same idea but using Silverlight.

The basic design will use two textboxes for the input and the output. A combobox allows the user to select the code direction e.g. C# to Visual Basic. No attempt is made to verify that they have selected the correct language direction. The user can either copy and paste the code into the Textbox or they can load a file directly. The options for the converted code is to copy and paste it back into an IDE into the text box or to save the result back to a file.

As a result of this outline you can see that this project provides an example of working with Silverlight:

• web services
• combobox
• file open for read and load
• file open for write and save

Cross platform web services

The first problem in using a web service supplied by a third party via Silverlight is its draconian cross domain policy. If you want to use a web service that isn't sourced from the same domain as the page that is hosting Silverlight the service has to have a cross domain policy file. Unfortunately not many web services have installed a cross domain policy file and so it was with the SharpDevelop web service.

If this is the case there is little you can do apart from asking the web service owners to add a policy file. This is precisely what we did and the SharpDevelop group responded quickly and effectively - don't expect this sort of response from very web service organisation.

So it is assumed that there is a working cross domain policy file installed in the root of the server - which is true for SharpDevelop at the time of writing.

The first thing we have to do is add the web service as a reference to the project. Start a new Silverlight 4.0 project in either Visual Studio or in Web Developer Express 2010.

Right click on the Service Reference branch in the Solution Explorer and select Add Service. Enter the address of the web service, in this case:

http://codeconverter.sharpdevelop.net/
             ConvertService.asmx?WSDL

and leave everything else set to the default.

When you click OK a set of classes will be created and added to the project to act as proxies to the service. If you have never used a web service before - yes it really is this easy. The classes and their methods can be used as if they were normal C# classes and can be called in the usual way. However when you call one of the generated methods HTTP is used to contact the server, transfer data and receive the results back and all of this is presented to you as a standard method call.

Of course there some differences and in particular the time it takes to complete a call could be much longer than for a standard method. As a result you can't really use a blocking call that would cause the UI thread to wait while data was transferred. Instead most web services are called asynchronously and this makes them ideal for the event pattern. In most cases however you can think of it as simply defining an even handler in the most convenient way possible.

<ASIN:1847199763 >

<ASIN:0470534044 >

<ASIN:0470524650 >

<ASIN:1430230185 >

<ASIN:0672333368 >

<ASIN:1430272074 >