Visual Studio 2005/2008 Integration - Example Project

how-to | home

You may wish to read the introduction before reading this section. This illustration uses Visual Studio 2005 but the corresponding example for Visual Studio 2008 is also included and the procedure is the same.

vs2005.sln

The Manifest Maker installation includes an example Visual Studio 2005 solution illustrating the use of manifest projects in the Visual Studio environment. This is a quite elaborate solution intended to illustrate as much as possible. Chances are that real-life needs are less complex then this. The solution contains three projects:

windowsDLL.vcproj

This is a plain Windows DLL that exports one function. This function, GetDetails, returns the full path from which this DLL was loaded. The test program displays the path returned by this function.

Additionally this project has a post-build event which builds an assembly containing this DLL. The side-by-side project file is located in the project folder along with other source files. The side-by-side project output directory is redirected to the Visual Studio output directory so that the Debug or Release versions of the manifest are built depending on the solution configuration currently being built by Visual Studio. Note that this project has the sxs32mm build rule turned off - the side-by-side project must not be compiled and embedded into the DLL, it must be built by a post-build event to create the assembly. The post-build event is defined as:

Command Linesxs32cmd /q:1 /l:9 /c:1 /t:$(IntDir)\sxs32cmd.log /d:$(OutDir) win_DLL.sxs32mm
DescriptionBuilding Windows DLL assembly...

Note the use of the /d:$(OutDir) option to redirect the build to the Visual Studio output folder. Also notice that if you open this project in Manifest Maker you will see an error indicating that the DLL cannot be found. This is expected since the DLL has not been built yet. The /c:1 option tells sxs32cmd.exe to copy, not move, the DLL to the assembly folder so the DLL will not disappear from the target folder after it is built.

serverDLL.vcproj

This is a simple COM object with one interface and one method. This method, also called GetDetails, returns a BSTR containing the full path this DLL was loaded from.

Like the above project, this project also has the sxs32mm build rule turned off and a post-build event defined to build the side-by-side assembly for the output DLL:

Command Linesxs32cmd /q:1 /l:9 /c:1 /t:$(IntDir)\sxs32cmd.log /d:$(OutDir) com_DLL.sxs32mm
DescriptionBuilding COM DLL assembly...

The event is essentially the same as the above with only names and comments changed.

targetProgram.vcproj

This project illustrates the use of the sxs32mm custom build rule to create application manifest embedded in the executable. The rule is turned on and as you build this project, the temporary manifest fragment is built in the intermediate folder then merged with other manifest fragments generated by Visual Studio and embedded as a resource in the final executable.

Since the targetProgram project uses the other two assemblies as dependencies, it is defined in Visual Studio as dependent on the other two projects. When you build the solution the two DLLs and the corresponding assemblies are built first and the program is built only after the two other builds are complete.

The important aspect of this example is that the type of build you may need to define depends on the desired end result:

When you are building a DLL it may be possible that you need both an embedded manifest (with resource ID #2) and an external assembly manifest. The embedded manifest is then activated by the system when your DLL is loaded (see Using Side-by-Side Assemblies as a Resource) so you can find your static links during DLL initialization, and the external assembly manifest is used by programs that need to find your DLL.

Read more on sxs32cmd.exe options.