Learning C# XML
by Niel Bornstein | Pages: 1, 2, 3

An Intense and Bracing Introduction to C#

The most important thing to remember about C# is that although it's definitely not Java, it is a lot like Java. So much so that you can probably port a lot of your application logic with a simple search-and-replace operation. (I'll highlight those areas when we go over the relevant code examples.) There are a few syntactic differences between the languages; I'll mention a couple of the most interesting ones, but rather than go over them in detail, you should read about the language on your own. I recommend any or all of the following articles: Conversational C# for Java Programmers by Raffi Krikorian; C#: A language alternative or just J--? by Mark Johnson; and A Comparison of Microsoft's C# Programming Language to Sun Microsystems' Java Programming Language by Dare Obasanjo. There are also several books on C#, including Programming C# by Jesse Liberty and the forthcoming C# In A Nutshell by Peter Drayton & Ben Albahari. And of course, there is Microsoft's own invaluable .NET Framework Class Library.

Let's begin our introduction to C# by diving right into the code.

The first change really is a simple global search-and-replace. The C# equivalent of the System.out class is Console, and the println() method's equivalent is WriteLine().

What we call packages in Java are called assemblies in C# -- an oversimplification, but it will do for purposes -- and they are brought into scope not with the import statement but with the using statement. Also, rather than declaring what package your class belongs to with a package statement, the assembly is declared through nested braces.

You don't have to be a rocket scientist to know that there is no javax.xml.parsers assembly in C#. Microsoft has provided an assembly called System.Xml which contains all the XML classes you're likely to need.

The last of our simple changes is one that may take some getting used to. Every Java developer knows that method names begin with lowercase letters, right? Well, Microsoft has taken a different route: building on its MFC naming tradition, all method names in C# begin with capital letters, including Main().

Now let's see what those changes have done to our sample code so far.

using System;

public class com {
  public class xml {
  public class RSSReader {

    static private Writer out;
    static String lineEnd =  System.getProperty("line.separator");

    Stack stack = new Stack();
    StringBuffer value = null;
    String title = null;
    String link = null;
    String desc = null;

    public static void Main(String args[]) {

    // don't worry about the rest of this code yet
    // ...
    }
  }
  }
}

Compiling Your Code

Since we've made our trivial changes, we might as well let the compiler tell us what else we have to do. Yes, I know there's going to be a lot of error messages, but we have to start somewhere.

Of course you know the command line to compile and run the Java version of RSSReader (I'm running this on Windows, since that's where my C# project lives):

javac -g -classpath %CLASSPATH% com\xml\RSSReader.java

Here is the equivalent C# compilation command line:

csc /debug /r:System.Xml.dll /t:exe RSSReader.cs

Share your comments on this article with the author and other readers.

Post your comments

Just as javac is the Java Compiler, csc is the Cee-Sharp Compiler (get it?). I've listed the parameters in the same respective order in each compile line, so that you can see that the C# equivalent of -g is /debug and the Java -classpath parameter (which was not strictly necessary in this example, of course) is something like the /r switch. There's a final parameter on the C# compile line, /t:exe. In C#, you can run your code in the .NET runtime or you can compile an executable directly. In this case I'm compiling an executable, saving the wonderful world of .NET for future articles.

If you run the compile line, you'll get a list of errors like the following.

Microsoft (R) Visual C# .NET Compiler version 7.00.9372.1
for Microsoft (R) .NET Framework version 1.0.3328
Copyright (C) Microsoft Corporation 2001. All rights reserved.

RSSReader1.cs(7,29): error CS1519:
	Invalid token 'out' in class, struct, or interface member
declaration
RSSReader1.cs(16,42): error CS1552:
	Array type specifier, [], must appear before parameter
name
...

Which should give you the impression that, although the languages are very similar, they're not identical. Maybe it's best not to try to compile it just yet. We're going to need to cover some minor syntax points first.

C# Minutiae

We need to make three very simple changes. First, out is a reserved word in C#, and, in fact, we should just delete that line and change all instances of out.write() to Console.Write().

Second, in Java the brackets of an array declaration may come either after the type or after the instance name. In our case, the Java code is written as String args[]. In C#, the brackets must come after the type, thusly: String [] args. Another simple fix in two places.

Finally, several of our Java methods have throws clauses. In C#, every exception is a runtime exception; there is no throws concept. We'll just delete all the throws clauses.

Compile again, and you'll see these errors:

Microsoft (R) Visual C# .NET Compiler version 7.00.9372.1
for Microsoft (R) .NET Framework version 1.0.3328
Copyright (C) Microsoft Corporation 2001. All rights reserved.

RSSReader1.cs(9,7): error CS0246:
	The type or namespace name 'Stack' could not be found
  (are you missing a using directive or an assembly reference?)
RSSReader1.cs(10,7): error CS0246:
	The type or namespace name 'StringBuffer' could not 
  be found (are you missing a using directive or an
  assembly reference?)
RSSReader1.cs(48,22): error CS0246:
	The type or namespace name 'Attributes' could not be
  found (are you missing a using directive or an assembly
  reference?)

Which raises two more issues. Some of the Java classes that you've come to know and love don't exist in the C# world, though similar assemblies are available. And some do exist, but you've got to bring those assemblies into scope with the using statement. So our solution to these errors is twofold.

First, add the following lines at the top of your C# file.

using System;
using System.Collections;
using System.IO;
using System.Text;

Second, in addition to C# method names starting with a capital letter, there's another perversity: string starts with a lower case letter because it's actually a C# primitive. There are also some minor differences in the names of utility classes. For example, instead of StringBuffer, C# has a StringBuilder class. Try to suppress your gag reflex, and do some global search-and-replaces.

These changes will fix more compilation errors. And now we can learn about XmlReader.

Pages: 1, 2, 3

Next Page