Visual Studio 2008 ships with the expected GUI designers, code snippet support, database manipulation
tools, object and project browsing utilities, and an integrated help system. Unlike many of
the IDEs we have already examined, Visual Studio 2008 provides numerous additions. Here is a
partial list:
• Visual XML editors/designers
• Support for mobile device development (such as Smartphones and Pocket PC devices)
• Support for Microsoft Office development
• Designer support for Windows Workflow Foundation projects
• Integrated support for code refactoring
• Visual class design utilities
• The Object Test Bench window, which allows you to create objects and invoke their members
directly within the IDE
To be completely honest, Visual Studio 2008 provides so many features that it would take an
entire book (a rather large book at that) to fully describe every aspect of the IDE. This is not that
book. However, I do want to point out some of the major features in the pages that follow. As you
progress through the text, you’ll learn more about the Visual Studio 2008 IDE where appropriate.
Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts
Monday, 30 November 2009
Building C# Applications Using csc.exe
While it is true that you may never decide to build a large-scale application using the C# commandline
compiler, it is important to understand the basics of how to compile your code files by hand. I
can think of a few reasons you should get a grip on the process:
• The most obvious reason is the simple fact that you might not have a copy of Visual Studio
2008.
• You may be in a university setting where you are prohibited from using code generation
tools/IDEs in the classroom.
• You plan to make use of automated build tools such as MSBuild or NAnt, which require you
to know the command-line options of the tools you are utilizing.
36 CHAPTER 2 n BUILDING C# APPLICATIONS
• You want to deepen your understanding of C#. When you use graphical IDEs to build applications,
you are ultimately instructing csc.exe how to manipulate your C# input files. In this
light, it’s edifying to see what takes place behind the scenes.
Another nice by-product of working with csc.exe in the raw is that you become that much
more comfortable manipulating other command-line tools included with the .NET Framework 3.5
SDK. As you will see throughout this book, a number of important utilities are accessible only from
the command line.
To illustrate how to build a .NET application IDE-free, we will build a simple executable assembly
named TestApp.exe using the C# command-line compiler and Notepad. First, you need some
source code. Open Notepad (using the Start äPrograms äAccessories menu option) and enter the
following trivial C# code:
// A simple C# application.
using System;
class TestApp
{
static void Main()
{
Console.WriteLine("Testing! 1, 2, 3");
}
}
Once you have finished, save the file in a convenient location (e.g., C:\CscExample) as
TestApp.cs. Now, let’s get to know the core options of the C# compiler.
Specifying Input and Output Targets
The first point of interest is to understand how to specify the name and type of assembly to create
(e.g., a console application named MyShell.exe, a code library named MathLib.dll, aWindows
Forms application named Halo8.exe, and so forth). Each possibility is represented by a specific flag
passed into csc.exe as a command-line parameter
To compile TestApp.cs into a console application named TestApp.exe, change to the directory
containing your source code file:
cd C:\CscExample
and enter the following command set (note that command-line flags must come before the name of
the input files, not after):
csc /target:exe TestApp.cs
Here I did not explicitly specify an /out flag, therefore the executable will be named TestApp.exe,
given that TestApp is the name of the input file. Also be aware that most of the C# compiler flags
support an abbreviated version, such as /t rather than /target (you can view all abbreviations by
entering csc -? at the command prompt).
csc /t:exe TestApp.cs
Furthermore, given that the /t:exe flag is the default output used by the C# compiler, you
could also compile TestApp.cs simply by typing
csc TestApp.cs
TestApp.exe can now be run from the command line
Referencing External Assemblies
Next, let’s examine how to compile an application that makes use of types defined in a separate
.NET assembly. Speaking of which, just in case you are wondering how the C# compiler understood
your reference to the System.Console type, recall from Chapter 1 that mscorlib.dll is automatically
referenced during the compilation process (if for some strange reason you wish to disable this
behavior, you may specify the /nostdlib option of csc.exe).
Let’s update the TestApp application to display a Windows Forms message box. Open your
TestApp.cs file and modify it as follows:
using System;
// Add this!
using System.Windows.Forms;
class TestApp
{
38 CHAPTER 2 n BUILDING C# APPLICATIONS
static void Main()
{
Console.WriteLine("Testing! 1, 2, 3");
// Add this!
MessageBox.Show("Hello...");
}
}
Notice you are importing the System.Windows.Forms namespace via the C# using keyword
(introduced in Chapter 1). Recall that when you explicitly list the namespaces used within a given
*.cs file, you avoid the need to make use of fully qualified names of a type (which can lead to hand
cramps).
At the command line, you must inform csc.exe which assembly contains the namespaces you
are using. Given that you have made use of the System.Windows.Forms.MessageBox class, you must
specify the System.Windows.Forms.dll assembly using the /reference flag (which can be abbreviated
to /r):
csc /r:System.Windows.Forms.dll TestApp.cs
If you now rerun your application, you should see what appears as winform in addition to the
console output.
compiler, it is important to understand the basics of how to compile your code files by hand. I
can think of a few reasons you should get a grip on the process:
• The most obvious reason is the simple fact that you might not have a copy of Visual Studio
2008.
• You may be in a university setting where you are prohibited from using code generation
tools/IDEs in the classroom.
• You plan to make use of automated build tools such as MSBuild or NAnt, which require you
to know the command-line options of the tools you are utilizing.
36 CHAPTER 2 n BUILDING C# APPLICATIONS
• You want to deepen your understanding of C#. When you use graphical IDEs to build applications,
you are ultimately instructing csc.exe how to manipulate your C# input files. In this
light, it’s edifying to see what takes place behind the scenes.
Another nice by-product of working with csc.exe in the raw is that you become that much
more comfortable manipulating other command-line tools included with the .NET Framework 3.5
SDK. As you will see throughout this book, a number of important utilities are accessible only from
the command line.
To illustrate how to build a .NET application IDE-free, we will build a simple executable assembly
named TestApp.exe using the C# command-line compiler and Notepad. First, you need some
source code. Open Notepad (using the Start äPrograms äAccessories menu option) and enter the
following trivial C# code:
// A simple C# application.
using System;
class TestApp
{
static void Main()
{
Console.WriteLine("Testing! 1, 2, 3");
}
}
Once you have finished, save the file in a convenient location (e.g., C:\CscExample) as
TestApp.cs. Now, let’s get to know the core options of the C# compiler.
Specifying Input and Output Targets
The first point of interest is to understand how to specify the name and type of assembly to create
(e.g., a console application named MyShell.exe, a code library named MathLib.dll, aWindows
Forms application named Halo8.exe, and so forth). Each possibility is represented by a specific flag
passed into csc.exe as a command-line parameter
To compile TestApp.cs into a console application named TestApp.exe, change to the directory
containing your source code file:
cd C:\CscExample
and enter the following command set (note that command-line flags must come before the name of
the input files, not after):
csc /target:exe TestApp.cs
Here I did not explicitly specify an /out flag, therefore the executable will be named TestApp.exe,
given that TestApp is the name of the input file. Also be aware that most of the C# compiler flags
support an abbreviated version, such as /t rather than /target (you can view all abbreviations by
entering csc -? at the command prompt).
csc /t:exe TestApp.cs
Furthermore, given that the /t:exe flag is the default output used by the C# compiler, you
could also compile TestApp.cs simply by typing
csc TestApp.cs
TestApp.exe can now be run from the command line
Referencing External Assemblies
Next, let’s examine how to compile an application that makes use of types defined in a separate
.NET assembly. Speaking of which, just in case you are wondering how the C# compiler understood
your reference to the System.Console type, recall from Chapter 1 that mscorlib.dll is automatically
referenced during the compilation process (if for some strange reason you wish to disable this
behavior, you may specify the /nostdlib option of csc.exe).
Let’s update the TestApp application to display a Windows Forms message box. Open your
TestApp.cs file and modify it as follows:
using System;
// Add this!
using System.Windows.Forms;
class TestApp
{
38 CHAPTER 2 n BUILDING C# APPLICATIONS
static void Main()
{
Console.WriteLine("Testing! 1, 2, 3");
// Add this!
MessageBox.Show("Hello...");
}
}
Notice you are importing the System.Windows.Forms namespace via the C# using keyword
(introduced in Chapter 1). Recall that when you explicitly list the namespaces used within a given
*.cs file, you avoid the need to make use of fully qualified names of a type (which can lead to hand
cramps).
At the command line, you must inform csc.exe which assembly contains the namespaces you
are using. Given that you have made use of the System.Windows.Forms.MessageBox class, you must
specify the System.Windows.Forms.dll assembly using the /reference flag (which can be abbreviated
to /r):
csc /r:System.Windows.Forms.dll TestApp.cs
If you now rerun your application, you should see what appears as winform in addition to the
console output.
The Role of the Common Intermediate Language
Let’s examine CIL code, type metadata, and the assembly manifest in a bit more detail. CIL is a language
that sits above any particular platform-specific instruction set. For example, the following C#
code models a trivial calculator. Don’t concern yourself with the exact syntax for now, but do notice
the format of the Add() method in the Calc class:
// Calc.cs
using System;
namespace CalculatorExample
{
// This class contains the app's entry point.
class Program
{
static void Main()
{
Calc c = new Calc();
int ans = c.Add(10, 84);
Console.WriteLine("10 + 84 is {0}.", ans);
// Wait for user to press the Enter key before shutting down.
Console.ReadLine();
}
}
// The C# calculator.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
}
Once you compile this code file using the C# compiler (csc.exe), you end up with a single-file
*.exe assembly that contains a manifest, CIL instructions, and metadata describing each aspect of
the Calc and Program classes.
nNote Chapter 2 examines the details of compiling code using the C# compiler, as well as the use of graphical
IDEs such as Visual Studio, Visual C# Express, and SharpDevelop.
For example, if you were to open this assembly using ildasm.exe (examined a little later in this
chapter), you would find that the Add() method is represented using CIL such as the following:
.method public hidebysig instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 9 (0x9)
.maxstack 2
.locals init (int32 V_0)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: add
IL_0004: stloc.0
CHAPTER 1 n THE PHILOSOPHY OF .NET 13
IL_0005: br.s IL_0007
IL_0007: ldloc.0
IL_0008: ret
} // end of method Calc::Add
Don’t worry if you are unable to make heads or tails of the resulting CIL for this method—
Chapter 19 will describe the basics of the CIL programming language. The point to concentrate on
is that the C# compiler emits CIL, not platform-specific instructions.
Now, recall that this is true of all .NET-aware compilers. To illustrate, assume you created this
same application using Visual Basic .NET, rather than C#:
' Calc.vb
Imports System
Namespace CalculatorExample
' A VB "Module" is a class that contains only
' static members.
Module Program
Sub Main()
Dim c As New Calc
Dim ans As Integer = c.Add(10, 84)
Console.WriteLine("10 + 84 is {0}.", ans)
Console.ReadLine()
End Sub
End Module
Class Calc
Public Function Add(ByVal x As Integer, ByVal y As Integer) As Integer
Return x + y
End Function
End Class
End Namespace
If you examine the CIL for the Add() method, you find similar instructions (slightly tweaked by
the VB .NET compiler, vbc.exe):
.method public instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add.ovf
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
} // end of method Calc::Add
that sits above any particular platform-specific instruction set. For example, the following C#
code models a trivial calculator. Don’t concern yourself with the exact syntax for now, but do notice
the format of the Add() method in the Calc class:
// Calc.cs
using System;
namespace CalculatorExample
{
// This class contains the app's entry point.
class Program
{
static void Main()
{
Calc c = new Calc();
int ans = c.Add(10, 84);
Console.WriteLine("10 + 84 is {0}.", ans);
// Wait for user to press the Enter key before shutting down.
Console.ReadLine();
}
}
// The C# calculator.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
}
Once you compile this code file using the C# compiler (csc.exe), you end up with a single-file
*.exe assembly that contains a manifest, CIL instructions, and metadata describing each aspect of
the Calc and Program classes.
nNote Chapter 2 examines the details of compiling code using the C# compiler, as well as the use of graphical
IDEs such as Visual Studio, Visual C# Express, and SharpDevelop.
For example, if you were to open this assembly using ildasm.exe (examined a little later in this
chapter), you would find that the Add() method is represented using CIL such as the following:
.method public hidebysig instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 9 (0x9)
.maxstack 2
.locals init (int32 V_0)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: add
IL_0004: stloc.0
CHAPTER 1 n THE PHILOSOPHY OF .NET 13
IL_0005: br.s IL_0007
IL_0007: ldloc.0
IL_0008: ret
} // end of method Calc::Add
Don’t worry if you are unable to make heads or tails of the resulting CIL for this method—
Chapter 19 will describe the basics of the CIL programming language. The point to concentrate on
is that the C# compiler emits CIL, not platform-specific instructions.
Now, recall that this is true of all .NET-aware compilers. To illustrate, assume you created this
same application using Visual Basic .NET, rather than C#:
' Calc.vb
Imports System
Namespace CalculatorExample
' A VB "Module" is a class that contains only
' static members.
Module Program
Sub Main()
Dim c As New Calc
Dim ans As Integer = c.Add(10, 84)
Console.WriteLine("10 + 84 is {0}.", ans)
Console.ReadLine()
End Sub
End Module
Class Calc
Public Function Add(ByVal x As Integer, ByVal y As Integer) As Integer
Return x + y
End Function
End Class
End Namespace
If you examine the CIL for the Add() method, you find similar instructions (slightly tweaked by
the VB .NET compiler, vbc.exe):
.method public instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add.ovf
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
} // end of method Calc::Add
Subscribe to:
Posts (Atom)