Microsoft Visual Studio

Creating C# Class from an XML file

Brad — Mon, 25 Feb 2008 09:16:40 GMT

If you've existing XML files that you need to manipulate in C# there is no need to write your own class by hand. Visual Studio ships with a little known tool XSD.exe which will do all the leg work for you.

Step 1 (from a command prompt):

This will create an XSD based on the XML file, which in step 2 will allow the tool to create the C# class(s)

XSD.exe [XML_FILE]

Step 2 (from a command prompt):

Call the tool again, this time providing the newly created .xsd file, along with /c (for classes, you could use /d for a dataset) and /n for your project's namespace

XSD.exe [XSD_FILE] /c /n:[PROJECT NAMESPACE]

Other parameters that might be useful are /o: (out) which specifies the output directory

Step 3:

Add the newly created .cs file to your project, and bingo, job done!

Visual Studio: Commenting Code

Brad — Thu, 17 Jan 2008 14:31:10 GMT

Who hates trying to work out what a complex C# method does that you didn't write? I know I do! Now who also hates writing the aforementioned comments... yep me too again! Along comes GhostDoc... a nice little plug-in for Visual Studio that automatically generates XML comments for your C# code! All you need to do is hit the hot key (which you can define) or right click and choose "Comment this..." and bingo a method or property you had selected now has a comment. GhostDoc uses some clever behind the scenes code based on the name of the method/property and the data types involved to make a "best guess" effort on giving it a comment - now I admit some of its suggestions do provide a few comedy results - but either way its often a good starting point!

I suggest you give it a go...

http://www.roland-weigelt.de/ghostdoc/

Debugging Web Applications... Quicker!

Brad — Mon, 14 Jan 2008 09:44:37 GMT

It's always frustrated me that Visual Studio takes so long to start debugging web applications compared to a standard windows form application. Also when you stop debugging it would kill the spawned IE window too - annoying if you were in the middle of testing something... Anyway I often found it was better to launch my own version of IE (so it remains open) then in Visual Studio select Debug > attach to process > then select the WebDeb.WebServer.EXE process(s). This was much quicker than clicking the standard "start debugging" button (or F5). But even that wasn't enough - it still annoyed me that you had to manually select the process to attach to - then while looking for something else I stumbled across the solution...

Right click the web site in the solution and select properties, followed by the "Start Options" node. In there change the "Start action" from the default "Use current page" to "Don't open a page. Wait for a response from an external application" then click OK. With the site still selected I recommend setting "Use dynamic ports" to false in the properties window - this means you'll always know what port to connect to. Now open IE as before and browse to the correct URL (and port). Now simply hit F5 in Visual Studio whenever you want to debug and it'll load quicker, without spawning a new instance of IE and it will remain open when you stop debugging.