Setting up Application Project Properties in Visual Studio .NET 2003


Visual Studio Project General Properties

Setting the properties for a project can be a tedious task. There are automated ways of doing this, but they still require an understanding of all the compiler and linker options. I highly recommend just sticking to this for now.

I promise to only examine the options that are most needed. If you need more information about a particular option not explained here, search for it in the Visual Studio Help Index.


We will first look at the General Tab. Make sure that the Configuration is set to Debug. We will look at Release later.



Output Directory
This is where your executable or library will be placed after it is successfully built. It takes either an absolute path or a relative path from the project (.vcproj) file.

It is nice to keep your Debug and Release output files separate. The default in Visual Studio is to keep them in separate directories named for their build configurations. In this case $(SolutionDir)$(ConfigurationName) would place the .exe in a Debug directory.


Intermediate Directory
This is where all object files (*.obj) and other intermediate build processing files will be placed after each is successfully built. It also takes either an absolute path or a relative path from the project (.vcproj) file.

Again, it is nice to keep your Debug and Release output files separate. The default in Visual Studio is to keep them in separate directories named for their build configurations. In this case $(ConfigurationName) would place the intermediate files in a Debug directory.


Configuration Type
Determines the type of output file generated. Choices include:

  • Application (.exe)
  • Dynamic Library (.dll)
  • Static Library (.lib)

Stick to applications and static libs. DLL's are not worth the trouble in this course (speaking from experience!).


Use of MFC
Determines whether the compiler should include the Microsoft Foundation Classes. Choices include:

  • Use Standard Windows Libraries
  • Use MFC in Static Library
  • Use MFC in Dynamic Library

Unless you are writing something with dialog boxes, toolbars, and/or widgets, stick to the standard Windows libraries. Otherwise you will be including more things than you need which will unnecessarily increase your build time and also make your executable bigger.


Use of ATL
Determines whether the compiler should include the Active Template Library. Choices include:

  • Not Using ATL
  • Use ATL in Static Library
  • Use ATL in Dynamic Library

Unless you are writing something that specifically requires the ATL, stick to the "Not Using ATL" option. Otherwise you will be including more things than you need which will unnecessarily increase your build time and also make your executable bigger.


Character Set
Determines which character set the compiler should use. Choices include:

  • Not Set
  • Use Unicode Character Set
  • Use Multi-Byte Character Set

This has been a problem in the past. Some (but not all) DirectX samples require the Unicode character set so they can be compilant with internationalization. Stick with the Multi-Byte if you can. Sometimes you will be forced to go to change to Unicode due to the nature of the libraries you use or other code you may have written. Just be aware of the change in the size of data types as a result of switching this option.

For more details on Unicode versus Multi-Byte chracter sets see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_support_for_unicode.asp


Use Managed Extensions
NO!!! Unless you are using the .NET Framework or C#, I highly suggest you stay away from this -- much pain came from this option when I took the class.


Whole Program Optimization
No -- this is a Debug build. You may want to try to compile with this on your Release builds. However, note that this will dramatically increase build times.





<< Previous

:: Index ::

Next >>