MSVC workspace and solution files come with several configurations. The main two are Debug and Release. Debug produces libraries and executables with debugging symbols and doesn't enable inlining. The Release configuration enables optimizations and leaves out debugging symbols. All projects contain both configurations. If you want to build static or mfc versions of th elibrary you need to use different project and solution files. Project files with _Static extension denote workspaces for building static libraries.
Different configurations produce different libraries and executables. For example, Debug versions of dynamic libraries are always named *d.dll (like aced.dll) and the executables are placed in the current directory. Release versions of dynamic libraries are named *.dll (such as ace.dll) and their executables are usually placed in the Release subdirectory. Other common suffixes include *sd.lib for Static Debug and *s.lib for Static Release.
Projects only use the same configuration versions of the libraries. The Debug version of an ACE example only uses debug version of ACE library.
Other compile time options are set or unset via the config.h file. For example, to turn on a compile time definition, define it at the beginning of config.h. Unsetting a definition just requires define ACE_FOO 0 or a undef at the end of the file (after including config-win32.h). Different macros require different techniques.
I don't think we have any documents really giving any info on what libraries are produced by the MSVC project files.
So unlike the Unix platforms, Win32 libraries do not have a prefix of "lib", instead it is used as an extension. For example, the debug version of the dynamic ace library is aced.lib (which is a stub for aced.dll). The three ACE libraries are:
And for TAO we have the main TAO library and several sub libraries which contain extra features of TAO that aren't always needed (such as the POA in TAO_PortableServer).
And finally we have the orbsvcs libraries. Each ORB service is contained in its own library. More libraries may be needed to be linked in, since some services require the use of others (such as TAO_AV requiring TAO_CosTrading and TAO_CosProperty).
The *.lib and *.dll files are located in ACE_wrappers/lib. You need to point your PATH to $ACE_ROOT/lib for running the applications.
I hesitate to put down explicit instructions on what libraries need to be linked in, considering that the libraries are being split apart more and more for footprint purposes. For most ACE stuff, you will only need to link in ace.lib. For plain TAO clients TAO.lib is enough. TAO servers also require TAO_PortableServer.lib for the POA. If the TAO application uses Dynamic Anys, TAO_DynamicAny.lib is also needed. Then if any of the ORB Services are used, more libraries are needed. For example, a client that uses the Name Service would need to link TAO_CosNaming.lib.
And note that the release versions of the libraries are listed above. For debug configurations the libraries would be aced.lib, TAOd.lib, etc.
It is a little difficult for us to list how exactly one should create projects that use ACE/TAO but are external to the ACE_wrappers tree. Since most projects we create are in that tree, we can make assumptions about directory structure that doesn't always apply for external projects. In other words, we have ideas how they should work, but they usually remain a bit, um, untested. :-)
There are three main dependencies a project would have on ACE/TAO.
So I guess in summary we would recommend adding most of the settings to Visual C++'s global settings (include paths, library paths, and executable paths) and just refer to the libraries without any paths.
ACE_ROOT is an interesting environment variable. Even though it is heavily used on Unix (in fact, ACE/TAO will not compile without it) it really isn't needed for MSVC. The reason for this is that we were interested in making configuration and setup really easy for Visual C++ on Windows. In retrospect it might have made quite a few things easier to specify if ACE_ROOT was required. One thing you might notice is that TAO_IDL will display a message if ACE_ROOT isn't set, but it is only a problem if the IDL file includes <orb.idl> and you don't use -I to specify where orb.idl is.