#490 – Using the DEBUG Conditional Compilation Symbol

By default, Visual Studio creates a Debug build configuration in which the Define DEBUG constant option is checked.

You can check to see if this constant (or “conditional compilation symbol”) is defined in your code, using the #if directive.

        public void Bark()
        {
#if DEBUG
            Console.WriteLine("DEBUG INFO: Entering Dog.Bark() [{0}]", Name);
#endif

            Console.WriteLine("{0} says woof", Name);

#if DEBUG
            Console.WriteLine("DEBUG INFO: Exiting Dog.Bark() [{0}]", Name);
#endif
        }

Code between the #if DEBUG and matching #endif will be compiled only if the DEBUG compilation symbol has been defined.  By default, this will be true for the Debug build configuration, but not the Release build configuration.

When we select the Debug build configuration and re-build, we see the following output:

When we select the Release build configuration, where the DEBUG symbol is no longer defined, we see the following output:

#489 – Debug and Release Configurations Are Created Automatically

When you create a new project, two build configurations are created for you automatically–Debug and Release.  The Debug configuration is meant to be used for debugging your application and the Release configuration is meant to be the one that you build with when releasing your application.

The Debug configuration

  • Defines the DEBUG constant (which you can use in your code to conditionally compile code only when debugging)
  • Does not optimize the code (to make stepping through the code in the debugger easier)
  • Builds output in \bin\Debug directory, rather than \bin\Release
  • Outputs full debug info, so that the appropriate source code lines can be located when debugging

#488 – Build Platforms Allow Project Properties to Target a Platform

Build Configurations allow you to build the project in different ways, depending on the configuration selected (e.g. Debug and Release).  In a similar way, Build Platforms allow you to target different hardware platforms, saving a different set of project properties for each platform.

The predefined Build Platform choices represent different hardware platforms that you might want to build your project for.  Each choice indicates the platform that the application is intended to run on.

  • x86 – Intended to run as a 32-bit process
  • x64 – Intended to run as a 64-bit process
  • Itanium – Intended to run on an Itanium processor
  • Any CPU – Intended to run as 32-bit or 64-bit

You can actually specify various project properties for any combination of Build Configuration and Build Platform.  But the Build Platform typically dictates the value of the Platform target choice on the Build tab of the Project Properties window.

#487 – Build Configurations Allow Saving Sets of Project Properties

In Visual Studio, a build configuration represents a set of saved properties that affect the build process.

A build configuration can be associated with a solution or with individual projects.

A build configuration at the solution level dictates which projects to build for that configuration, which build configurations to use for individual projects, and which platform to build each project for.

At the project level, a build configuration allows setting different project properties for each configuration.  For example, a “Debug” configuration might be configured to define the DEBUG constant and generate full symbols for debugging purposes.

You select the current build configuration to use by selecting an item from the Solution Configurations dropdown in the main toolbar.

You can also select Configuration Manager from the Build menu and then change the configuration in the Active solution configuration dropdown.

#484 – Add a Project Reference to Use a Type from Another Project

Let’s say that you’re authoring two different projects in Visual Studio–one that will contain a type (like Dog) and one that will use that type.  You need to set up a project reference so that the project that wants to use the Dog class knows about the project that defines Dog.

Assume that the project containing the Dog class will be a class library (.dll) that we’ll call DogLibrary.  We’ll also generate a console application project (.exe) that uses the Dog  class, which we’ll call DogApplication.

To use the Dog class from the console application, we need to set up a project reference so that DogApplication knows about DogLibrary.  Right-click on DogApplication and select Add Reference…

On the Projects tab, which lists other projects in this solution, select DogLibrary and click OK.

In the References folder for DogApplication,  you’ll now see that this project references the DogLibrary project.

#483 – Adding a new Project to an Existing Solution

A solution in Visual Studio can contain one or more projects.  When you create a new solution using the New Project wizard, you typically get a solution with a single project.

You can add additional projects to a solution at any time, representing additional components that will be built when you build all source code in the solution.

As an example, suppose that you use the New Project wizard to create a WPF Application called MyWPFApp.  You’ll get a solution with a single project.

Now let’s say that you want to add a class library (DLL) to your project.  You right-click on the solution in the Solution Explorer and select Add | New Project.

You’ll get the Add New Project dialog, where you can select Class Library as the project type, give the project a name, and press OK.

You’ll now see the new project in the Solution Explorer.

#482 – Basic Project Types in Visual Studio

The first step in creating a new application is typically to use the New Project wizard in Visual Studio.  The wizard creates a new solution with one or more projects containing a minimum set of source code files that represent a project of the desired type.

The more common project types that you might create include:

  • A WPF (Windows Presentation Foundation) client application

  • A WPF Ribbon application – a WPF client with a Ribbon control

  • A Console application – an application that sends all output to a console window

  • A class library – a DLL that contains .NET types that an application might make use of

  • A WPF Browser application – a WPF app that can be deployable from a browser

  • A Windows service – an application that runs in the background as a Windows service

  • A WPF custom control library – A DLL containing one or more custom controls deriving from Control

#481 – Projects and Solutions in Visual Studio

When you work with Visual Studio to develop an application, you organize your source code into projects and solutions.

Projects contain items such as your source code files and typically are configured to produce a single deployable object at build time, like a Console Application (.exe), WPF Application (.exe) or a Class Library (.dll).  A project is something that you can build individually, generating the desired output (like an .exe or .dll file).

Solutions act as containers for projects.  You can perform certain operations, like building the software, for the entire solution.

When you open Visual Studio, you typically open a solution.  You then use the Solution Explorer to view and manage items contained in projects within that solution.

The example below shows a solution (ConsoleApplication1) that contains two projects–a Console Application packaged as an .exe file (ConsoleApplication1) and a class library packaged as a .dll file (DogLibrary).

#474 – You Can Include Unicode Characters in Your Source Code

You can enter Unicode characters directly into your source code using the editor in Visual Studio.  These characters will be stored and intepreted correctly, if contained in a comment or a string literal.  (Unicode characters are not used in any C# keywords).

You can also enter a hex code for the Unicode character, rather than entering the character directly.  (E.g. By copying/pasting it or entering from a keyboard that includes the character)

        static void Main()
        {
            string money = "€";
            string sameThing = "\u20AC";
        }

#452 – Object Browser Shows You the Interfaces that a Class Implements

In Visual Studio, you can see which interfaces a particular class implements by using the Object Browser.

Open the Object Browser window by selecting Object Browser under the View menu.

Once the Object Browser appears, you can navigate to the class that you want information on.  In the example below, we can see that the Cow class derives from Object and implements both IMoo and IStrangeCowBehavior.

We can’t tell from this view, however, which interfaces are implemented explicitly, i.e. requiring an interface-typed variable to access the methods.

You can click on the class itself to see all of the members of the class, including public and private members.

You can see all members.  Members in implicitly implemented interfaces (e.g. IMoo) show up as public members.  Members of explicitly implemented interfaces (e.g. IStrangeCowBehavior) show up as private.

You can also click on the interfaces to see members of each interface.

Follow

Get every new post delivered to your Inbox.

Join 43 other followers