You can use file properties to indicate what actions the project system should perform on the files. For example, you can set file properties to indicate whether a file should be compiled or embedded into the build output as a resource.
You can select any file in Solution Explorer and then examine its properties in the Properties window. Visual Basic and Visual C# files have four properties: FileName, BuildAction, CustomTool, and CustomToolNamespace.
The BuildAction, CustomTool, and CustomToolNamespace properties are provided for advanced scenarios. The default values are typically sufficient and do not need to be changed.
You can rename a file by clicking the FileName property in the Properties window and typing in the new name. Notice that if you change the file's name, Visual Studio will automatically rename any .vb or .resx files that are associated with it.
The BuildAction property indicates what Visual Studio does with a file when a build is executed. BuildAction can have one of several values:
None - The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.
Compile - The file is compiled into the build output. This setting is used for code files.
Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file.
Embedded Resource - This file is embedded in the main project build output as a DLL or executable. It is typically used for resource files.
The default value for BuildAction depends on the extension of the file you add to the solution. For example, if you add a Visual Basic project to Solution Explorer, the default value for BuildAction is Compile, because the extension .vb indicates a code file that can be compiled. File names and extensions appear in Solution Explorer.
Note that the name of the file in your project will not be the identifier for the managed resource in the assembly manifest (see Assembly Manifest for more information). The identifier will be namespace.filename.extension, where namespace is the value of the DefaultNamespace property in a Visual C# project or RootNamespace property in a Visual Basic project. Filename and extension remain the same as their original designation. If the file is a .resx file, the project system will run resgen.exe on the file, creating a .resource file. The .resource file will be embedded in the assembly, so the assembly manifest will refer to the .resources file and not the .resx file.
For example, if you add the file MyFile.bmp to a project whose default namespace is MyProj, and set the build action to Embedded Resource, MyProj.MyFile.bmp will be the identifier in the assembly manifest. If you then add the file MyFile.resx to the project, the default build action will be Embedded Resource and, MyProj.MyFile.resources will be the identifier in the assembly manifest.
Note that when the resource editor adds an image, it sets Build Action to None, because the .resx file references the image file. At build time, the image is pulled into the .resources file created out of the .resx file. The image can then easily be accessed via the strongly-typed class auto-generated for the .resx file. Therefore, you should not change this setting to Embedded Resource, because doing so would include the image twice in the assembly.
For more information on how to access resource files (compiled from .resx files) at run time, see ResourceManager Class. For more information on how to access all other embedded files and resources at run time, see Assembly.GetManifestResourceStream Method.
This property specifies the conditions under which the selected source file will be copied to the output directory. Select Do not copy if the file is never to be copied to the output directory; Copy always if the file is always to be copied to the output directory; or Copy if newer if the file is to be copied only when it is newer than an existing file of the same name in the output directory.
In smart device projects, the newness of a .dll or .exe file is determined by comparing the Win32 versions as follows:
If the device-side version is less than that of the desktop, the file is copied.
If the device-side version is greater than that of the desktop, the file is not copied.
If the versions are the same, a checksum comparison is made. If the checksums are the same, the file is not copied. If the checksums are different, the file is copied.
The newness of files other than .dll and .exe is based solely on checksum.
Data files will be copied to a subfolder named Data Files in the output directory.
Custom tools are components that can be used to transform files from one type to another at design time. For example, a custom tool might be a dataset code generator that reads in an XML Schema (.xsd) file, and generates classes in a code file that programmatically exposes its tables and columns. There is a predefined list of custom tools available in the product; this property allows you to see which custom tool is applied to a file. In rare circumstances, you might need to change the value of this property. The value of this property must either be blank or one of the built-in custom tools.
To set or change the custom tool, click the CustomTool property in the Properties window and type in the name of a custom tool.
If you have a custom tool assigned to your project, the CustomToolNamespace property allows you to specify the namespace you want to assign to code generated by the custom tool. When you specify a value for the CustomToolNamespace property, code generated by the tool is placed in the specified namespace. If the property is empty, generated code is placed in the default namespace for the folder in which the converted file lives; for Visual Basic, this is the project's root namespace, and for Visual C# this corresponds to the setting of the DefaultNamespace property for the folder.