this.Text = "Form1";

}

#endregion

It is worth noting here that the InitializeComponent method is called from the Form1 constructor. In chapter 1, we initialized our Form object in the constructor as well. Visual Studio uses a separate method for this purpose in order to encapsulate the auto-generated code for the program.

fThis line assigns the STAThread attribute to our Main function. This ensures that the main application thread runs as a single threaded apartment so that operations such as drag and drop and the clipboard will work correctly. Strictly speaking, we should have done this in chapter 1 as well (we did not in order to keep the number of discussion points down). Apartments and threading are a bit beyond our discussion here, so for now just accept that this line is needed for the form to properly interact with the clipboard and other parts of the Windows operating system.

[STAThread]

Congratulations are once again in order for creating your first Windows Forms program, this time in Visual Studio .NET. Sit back in your chair to savor your accomplishment, and join me in section 2.2 when you are ready to add some controls to your program.

2.2Adding controls

In this section we use Visual Studio .NET to add the Button and PictureBox controls to our form. Before we do, let’s take a look at the AssemblyInfo.cs file in our project.

2.2.1The AssemblyInfo file

When you create a C# Windows application project, an AssemblyInfo.cs file is created to define various attributes for the program assembly. This includes the version number shown in the Version tab when you display the program’s properties dialog box from Windows Explorer. An attribute in C# is a declarative tag that affects the settings or behavior exhibited by an assembly, type (such as a class), or type member (such as a method or property). All attributes are based on the System.Attribute class defined in the .NET Framework as part of the System.Reflection namespace.

The AssemblyInfo.cs file makes use of some assembly-related attributes defined by this namespace. These settings are defined using the standard format for attributes targeted at the assembly file:

[assembly: <attribute>(<setting>)]

The various attribute classes defined for this purpose include the AssemblyVersionAttribute class supporting the file version number settings. In C#, the

Attribute portion of the class name can be omitted, resulting in a version number setting something like the following:

[assembly: AssemblyVersion("1.0")]

A summary of the attributes used by this file are shown in the following table:

Common attributes in AssemblyInfo.cs file

Most of these attributes accept a string that specifies the value for the attribute. One exception is the AssemblyVersion attribute. The version number is used internally for comparing expected and actual version numbers of other assemblies, namely programs or libraries, used by your application. The version number format is a string specified as follows:

Major.Minor.Build.Revision

These are all expected to be integers. The first two values are for the major and minor version number used by most products these days. Changes in these numbers normally represent incompatible changes with previous versions; that is, version 2.1 is not compatible with version 2.2 of the same library.

The build number is for different compiles of the same minor version of an assembly. Occasionally this might introduce incompatibilities, but often version 2.1.17 will operate the same as version 2.1.42, although perhaps with some slight problems in the earlier build that will have been fixed in the later build. The revision number is for bug fixes or other incidental updates, and should not normally break compatibility.

In .NET, the build and revision number can be inserted automatically by the compiler. This is done by inserting an asterisk (*) in place of one or both of these numbers.

The automated build number is the number of days since January 1, 2000 in local time, and the automated revision number is the number of seconds since the previous midnight, local time, modulo 2. These automated values ensure that a new build and revision number is generated for each compile, that the build number always increases, and that the revision number increases within a generated build. It should be noted that this scheme is good for thousands of years, and that the revision number will never be larger than a 32-bit integer. Some examples and interpretations of version number strings are shown in the following table.

Assembly version number examples

In our application, we will set the version number equal to the current section number. The following steps set the version number for our application to 2.2. While we are here, we will also assign values to other settings in the AssemblyInfo.cs file, and use the ProductVersion property of the Application class to include this version number in the title bar automatically.

SET THE VERSION NUMBER FOR THE MYPHOTOS PROJECT