Home > Articles > Programming > Visual Studio

  • Print
  • + Share This
This chapter is from the book

My Project

My Project is a special tool that enables developers to set project properties. My Project is a window that can be invoked by double-clicking the My Project item in Solution Explorer or by clicking the Project, Properties command (the menu item text also includes the current project name). Figure 2.21 shows how My Project looks regarding the sample application we previously created.

Figure 2.21

Figure 2.21. The My Project window.

My Project is organized in tabs; each tab represents a specific area of the project, such as application-level properties, external references, deployment options, compile options, debugging options, and many more. At the moment you don’t need to learn each tab of My Project because during the rest of the book we use it a lot, learning the meaning and purpose of each tab when appropriate. What you instead need now is to

  • Understand what My Project is.
  • Remember how you can open it.
  • Learn the usage of the Application tab, which we will discuss first.

Application Tab

Each application has some settings. Application settings can be the executable’s name, icon, or metadata that will be grabbed by the operating system, such as the program version, copyright information, and so on. The purpose of the Application tab in My Project is to provide the ability to edit these kinds of settings. The Application tab is shown by default when you first open My Project. Figure 2.21 shows the Application tab. Some settings are common to every kind of Visual Basic project, whereas other ones are related to specific project types. In this chapter you get an overview of the common settings, whereas specific ones will be discussed when required in the next chapters.

Assembly Name

The Assembly name field sets the name of the compiled assembly—that is, your executable. By default, Visual Studio assigns this setting based on the project name, but you can replace it as needed.

Root Namespace

This particular field sets the root-level namespace identifier. Namespaces will be discussed later in this book. You can think of the root namespace as the object that stores all that is implemented by your project. According to Microsoft specifications, the root namespace should be formed as follows: CompanyName.ProductName.Version. This convention is optimal when developing class libraries or components but might not be necessary when developing standalone executables. By default, Visual Studio sets the root namespace based on the project name.

Application Type

This represents the application type (for example, Console application, Class Library, Windows Forms application) and is automatically set by Visual Studio on the appropriate choice. To ensure you will avoid any problems, you should not change the default setting.

Icon

This field allows setting an icon for the executable file. You can browse the disk and select an existing .ico file as the executable icon.

Startup Object

By setting the Startup Object field, you can specify which object will be executed first when running your application. For example, imagine you have a Windows Presentation Foundation application with more than one window. You might want to decide which window must be the application’s main window. With the Startup Object field, you can make this decision. Notice that the startup object changes based on the project type. For example, in a WPF application the startup object is a Window object, whereas in a Console Application the default startup object is a Module in which the Sub Main method is located. The name of the field also changes based on the project type. In a WPF application it is called Startup URI, whereas in a Console Application it is called Startup Object.

Assembly Information

By clicking the Assembly Information button, you get access to a new window called Assembly Information, as shown in Figure 2.22.

Figure 2.22

Figure 2.22. The Assembly Information window.

From this window you can specify several properties for your executable that will be visible both to the .NET Framework and to the Windows operating system. Table 2.1 explains each property.

Table 2.1. Assembly Information Explained

Property

Description

Title

The title for your application, for example, “My First 2012 Program.”

Description

The description for your application, for example, “My first application with VB 2012.”

Company

Your company name.

Product

The product name, for example, “Suite of My New 2012 Applications.”

Copyright

Copyright information on the author.

Trademark

Trademarks information.

Assembly version

Specifies the version number for the assembly in the style Major.Minor.Build.Revision. This information identifies the assembly for the .NET Framework.

File version

Specifies the version number for the executable in the style Major.Minor.Build.Revision. This information is visible to the Windows operating system.

GUID

A globally unique identifier assigned to the assembly. You can replace it with a new one or leave it as the GUID provided by the IDE.

Neutral language

Specifies what local culture is used as the neutral language.

Make assembly COM-Visible

.NET assemblies can be exposed to COM. By marking this flag, you can accomplish this task later.

The Assembly Information tool is important because it enables you to specify settings that you want to be visible to your customers and other settings needed by the .NET Framework. Behind the scenes, all this information is translated into Visual Basic code, which is discussed more in Chapter 3.

View Windows Settings

Starting from Windows Vista, Microsoft introduced to the Windows operating system an important component, known as User Account Control (UAC). When enabled, this mechanism requires the user to explicitly grant elevated permissions to applications being run. Because of this and starting from Visual Studio 2008, you have the ability of specifying the permissions level your application will require for the UAC. For example, if your application needs to write to the Program Files folder (this is just an example and rarely a good idea), you need to ask for elevated permissions to the UAC. You can specify UAC settings for your application by clicking the View Windows Settings button. At this point Visual Studio generates a new XML manifest that will be packaged into your executable and that you can edit within the IDE. This file contains information for UAC settings and for specifying the operating systems that the application is designed to work for (see the supportedOS node). Listing 2.2 shows an excerpt of the default content of the manifest, related to the UAC settings.

Listing 2.2. The UAC Manifest Content

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-
com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
            If you want to change the Windows User Account Control level replace the
            requestedExecutionLevel node with one of the following.

        <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

            Specifying requestedExecutionLevel node will
            disable file and registry virtualization.
            If you want to utilize File and Registry Virtualization for backward
            compatibility then delete the requestedExecutionLevel node.
        -->
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- A list of all Windows versions that this application is designed
           to work with.
      Windows will automatically select the most compatible environment.-->

      <!-- If your application is designed to work with Windows Vista, uncomment the
following supportedOS node-->
      <!--<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"></supportedOS>-->

      <!-- If your application is designed to work with Windows 7, uncomment the
following supportedOS node-->
      <!--<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>-->

      <!-- If your application is designed to work with Windows 8, uncomment the
following supportedOS node-->
      <!--<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></supportedOS>-->

    </application>
  </compatibility>

  <!-- Enable themes for Windows common controls and dialogs (Windows XP and later)
-->
  <!-- <dependency>
    <dependentAssembly>
      <assemblyIdentity
          type="win32"
          name="Microsoft.Windows.Common-Controls"
          version="6.0.0.0"
          processorArchitecture="*"
          publicKeyToken="6595b64144ccf1df"
          language="*"
        />
    </dependentAssembly>
  </dependency>-->

</asmv1:assembly>

Notice how a huge number of comments help you understand the file content and how you should manage the behavior of your application according to the Windows version that your application is going to target. The requestedExecutionLevel element enables you to specify which permission level must be requested to the UAC. You have three possibilities, explained in Table 2.2.

Table 2.2. UAC Settings

Setting

Description

asInvoker

Runs the application with the privileges related to the current user. If the current user is a standard user, the application will be launched with standard privileges. If the current user is an administrator, the application will be launched with administrative privileges. This is the default selection in the manifest.

requireAdministrator

The application needs administrative privileges to be executed.

highestAvailable

Requires the highest privilege level possible for the current user.

To specify a privilege level, just uncomment the line of XML code corresponding to the desired level. You can also delete the requestedExecutionLevel node in case you want to use file and registry virtualization for backward compatibility with older versions of the Windows operating system.

The Application Framework

In the lower part of the screen is the Enable Application Framework group, a feature that allows executing special tasks at the beginning and at the end of the application lifetime. For Console applications it is not available, but it is relevant to other kinds of applications; for instance, in the Windows Forms application it enables the setting of a splash screen or establishing which form is the main application form. The application framework is discussed in Chapter 19.

Target Framework

From the Target Framework combo box, you can select the version of the .NET Framework that your application will target. The main difference with the same selection that you can do when creating a new project is that here you can target the .NET Framework Client Profile for versions 4.0, 3.5 Service Pack 1, and 3.5 Server Core. The .NET Framework Client Profile is a subset of the .NET Framework that provides the infrastructure for client applications and that can be included in your deployments instead of the full version. Microsoft removed the .NET Framework Client Profile in version 4.5.

  • + Share This
  • 🔖 Save To Your Account