HIDDEN FILES

Figure 13-1 shows the Solution Explorer window for a solution that contains two projects. The solution named MySolution contains two projects named WindowsApplication1 and WindowsApplication2. Each project contains a My Project item that represents the project’s properties, various files containing project configuration settings, and a form named Form1.

FIGURE 13-1: A solution contains one or more projects that contain files.

image

In WindowsApplication2, the Show All Files button has been clicked (the highlighted button third from the right at the top of the picture) so that you can see all the project’s files. WindowsApplication1 has similar files, but they are hidden by default.

These files are generated by Visual Basic for various purposes. For example, Resources.resx contains resources used by the project and Settings.settings contains project settings.

RESOURCES AND SETTINGS
Resources are chunks of data that are distributed with the application but that are not intended to be modified by the program. (Technically, you can change resource values, but then they are acting more as settings than resources, so I won’t cover that here. In fact, changing resources in a strongly named resource file raises an alarm indicating that someone may have tampered with the file.) These might include prompt strings, error message strings, icons, and sound files.
For example, resources are commonly used for customizing applications for different languages. You build different resource files for different languages, and the program loads its prompts and error messages from the appropriate resource file. Chapter 28, “Configuration and Resources,” has more to say about resources.
Settings are values that control the execution of the application. These might include flags telling the program what options to display or how to perform certain tasks. For example, you could build different profiles to provide settings that make the program run in a restricted demo mode or in a fully licensed mode. Normally, settings for .NET applications are stored in .config files, although an application can also store settings in the registry, XML, or .ini files. For example, this article discusses saving settings in XML files: http://www.devsource.com/c/a/Techniques/XML-Serialization-Better-than-the-Registry.

The following list describes the files contained in WindowsApplication2 and shown in Figure 13-1. The exact files you see for an application may be different from those shown here, but this list should give you an idea of what’s involved in building a project. Note that most of these files are generated automatically by Visual Studio and you shouldn’t edit them manually. If you change them directly, you are likely to lose your changes when Visual Studio rebuilds them and you may even confuse Visual Studio.

  • WindowsApplication2 — This folder represents the entire project. You can expand or collapse it to show and hide the project’s details.
  • My Project — This folder represents the project’s assembly information, application-level events, resources, and configuration settings. Double-click the My Project entry to view and edit these values.
  • Application.myapp — This XML file defines application properties (such as whether it’s a single instance program and whether its shutdown mode is AfterMainFormCloses or AfterAllFormsClose).
  • Application.Designer.vb — This file contains code that works with the values defined in Application.myapp.
  • AssemblyInfo.vb — This file contains information about the application’s assembly such as copyright information, company name, trademark information, and assembly version.
  • Resources.resx — This resource file contains the project’s resources.
  • Resources.Designer.vb — This file contains Visual Basic code for manipulating resources defined in Resources.resx. For example, if you define a string resource named Greeting in Resources.resx, Visual Basic adds a read-only property to this module so you can use the value of Greeting as shown in the following code: 
    MessageBox.Show(My.Resources.Greeting)
  • Settings.settings — This file contains settings that you can define to control the application.
  • Settings.Designer.vb — This file contains Visual Basic code for manipulating settings defined in Settings.settings, much as Resources.Designer.vb contains code for working with Resources.resx. For example, the following code uses the UserMode setting: 
    If My.Settings.UserMode = "Clerk" Then ...
  • References — This folder lists references to external components such as DLLs and COM components.
  • bin — This folder is used to build the application before it is executed. The Debug or Release subfolder contains the compiled .exe file (depending on whether this is a debug or release build).
  • obj — This folder and its Debug and Release subfolders are used to build the application before it is executed.
  • ApplicationEvents.vb — This code file contains application-level event handlers for the MyApplication object. For example, it contains the application’s Startup, Shutdown, and NetworkAvailabilityChanged event handlers.
  • Form1.vb — This is a form file. It contains the code you write for the form, its controls, their event handlers, and so forth. If you double-click this file in Solution Explorer, Visual Studio opens it in the Form Designer.
  • Form1.Designer.vb — This file contains designer-generated Visual Basic code that builds the form. It initializes the form when it is created, adds the controls you placed on the form, and defines variables with the WithEvents keyword for the controls so that you can easily catch their events.
  • Form1 — This entry represents the code-behind that you add to the form. If you double-click this file in Solution Explorer, Visual Studio opens the form’s code in the code editor. Alternatively, you can open the code by right-clicking the Form.vb entry and selecting View Code.

Some projects may have other hidden files. For example, when you add controls to a form, the designer adds a resource file to the form to hold any resources needed by the controls.

Normally, you do not need to work directly with the hidden files, and doing so can mess up your application. At best, the changes you make will be lost. At worst, you may confuse Visual Studio so it can no longer load your project.

Instead you should use other tools to modify the hidden files indirectly. For example, the files Resources.Designer.vb, Settings.Designer.vb, and Form1.Designer.vb are automatically generated when you modify their corresponding source files Resources.resx, Settings.settings, and Form1.vb.

You don’t even need to work with all of those source files directly. For example, if you double-click the My Project item in Solution Explorer, the property pages shown in Figure 13-2 appear. The Application tab shown in this figure lets you set high-level application settings. The View Application Events button at the bottom right of the figure lets you edit the application-level events stored in ApplicationEvents.vb.

FIGURE 13-2: These property pages let you define the project’s resources, settings, and general configuration.

image

The References tab shown in Figure 13-2 lets you view, add, and remove project references. As you can probably guess, the Resources and Settings tabs let you edit the project’s resources and settings.

A particularly important section hidden away in these tabs is the assembly information. When you click the Assembly Information button shown in Figure 13-2, the dialog box shown in Figure 13-3 appears.

FIGURE 13-3: The Assembly Information dialog box lets you define basic project information such as title, copyright, and version number.

image

Many of the items in this dialog box, such as the application’s title and description, are self-explanatory. They are simply strings that the assembly carries around for identification. The assembly and file versions are used by the Visual Studio run time to verify compatibility between an application’s components. The GUID (which stands for “globally unique identifier” and is pronounced to rhyme with “squid”) uniquely identifies the assembly and is generated by Visual Studio. The Make Assembly COM-Visible check box lets you determine whether the assembly should make types defined in the assembly visible to COM applications. For more information on this dialog box, see http://msdn2.microsoft.com/1h52t681.aspx.

The My.Application.Info namespace provides easy access to these values at run time. Example program ShowAssemblyInfo uses the following code to display this information in a series of labels when it starts:

Private Sub Form1_Load() Handles MyBase.Load
    lblCompanyName.Text = My.Application.Info.CompanyName
    lblDescription.Text = My.Application.Info.Description
    lblCopyright.Text = My.Application.Info.Copyright
    lblTrademark.Text = My.Application.Info.Trademark
    lblDirectoryPath.Text = My.Application.Info.DirectoryPath
    lblProductName.Text = My.Application.Info.ProductName
    lblTitle.Text = My.Application.Info.Title
    lblVersion.Text = My.Application.Info.Version.ToString
End Sub
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.116.63.64