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 Line	sxs32cmd /q:1 /l:9 /c:1 /t:$(IntDir)\sxs32cmd.log /d:$(OutDir) win_DLL.sxs32mm
Description	Building 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 Line	sxs32cmd /q:1 /l:9 /c:1 /t:$(IntDir)\sxs32cmd.log /d:$(OutDir) com_DLL.sxs32mm
Description	Building 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:

To generate an assembly from the DLL being built by your project you need a post-build event like the two DLL projects above.
To generate an embedded manifest for a program being built you need to use the custom build rule as shown in the targetProgram above.
To generate an embedded manifest for a DLL you need the same approach as the targetProgram above.
To generate an external application manifest for your program you need a post-build event similar to those used for the DLLs above.

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.