The Default C Code

The Default C# Code

The New Project wizard also created a source file, Program.cs, whose contents have been reproduced in Listing 3-1.

Listing 3-1: Default code generated by the New Project wizard.

 using System; using Microsoft.SPOT; namespace HelloMicroFramework {    public class Program    {       public static void Main()       {          Debug.Print(             Resources.GetString(Resources.StringResources.String1));       }    } } 

The first thing to notice is the inclusion of the libraries this code relies on through the use of the C# keyword using.

 using System; using Microsoft.SPOT; 

This is similar to the C or C++ #include preprocessor directive and simply makes available the definitions contained in the referenced libraries to your code (and, more conveniently for us programmers, the productivity-enhancing Intellisense feature of Visual Studio). In this case, the code relies upon the standard System library and Microsoft.SPOT (the core .NET Micro Framework library). Technically, the code is not relying on anything from System, but most of your developments will, and it is safest to always include it. From the Microsoft.SPOT library, the code uses Debug.Print(), which, as you might expect, takes a string and sends it to the configured output destination (for example, the Visual Studio Output window when running under the emulator). You can confirm the origin of this class by hovering the mouse over the class (Debug) to display a tooltip that shows where the symbol comes from.

Every application is required to have an entry point. Entry points are always static methods (that is, they can be called without instantiating an object) called Main, just as in C or C++, and are defined like so:

 public static void Main() {...} 

The compiler will search for a method with this signature and use it by default. (It is possible to have more than one Main and to explicitly specify which one the compiler should use in the project properties, but it is generally considered bad practice to do so.)

We finally reach some code that does something:

 Debug.Print(Resources.GetString(Resources.StringResources.String1)); 

This code invokes the static method Print from the Debug class. (We know it is static because there is no object instance.) The Print method expects a reference to a string parameter. We could have simply passed in a string, but this code is demonstrating the use of resources, which provide a convenient way of separating code from data and performing localization. Resources, once defined, are included in the assembly and become available to your code as objects.

You can display the resources for your project by double-clicking the Resources.resx file (generally just referred to as the "rez x" file) in the Solution Explorer. Figure 3-5 shows the resource string editor, which defines the string that the code is using.

Figure 3-5: Editing string resources.

The resource editor simply provides a friendly user interface (UI) for working with resources, but it ultimately generates code that actually represents and builds the resources, making them available to your code. You can see this file by expanding the Resources.resx node and opening the Resources.Designer.cs file. (Looking at this file, you can see why having a UI is convenient for making changes-the code required to supply the underlying UI functionality is a bit cumbersome.)