Visual Studio 2019
You may wish to first read Visual Studio Integration and Command Line Manifest Maker to get an overview of the topic.
Build process in Visual Studio, starting with version 2010, is using msbuild.exe instead of the older built-in controller. Manifest Maker Visual Studio integration includes a number of XAML files and new functionality of sxs32cmd.exe.
The command line Manifest Maker sxs32cmd.exe is specifically designed to perform a build of a side-by-side project in an automated environment. It has been extensively tested in Visual Studio but can be adopted to practically any build environment. The build process implemented by sxs32cmd.exe is exactly the same as in the interactive sxs32mm.exe with the added ability to override certain settings prior to starting the build.
As of version 4.0 Manifest Maker adds build mode command line options. The /COM option is meant for building COM manifests and can be used to build CLR manifests instead of the /CLR option. These two types of manifests are referred to as DEF-manifests, the define resources made available by this DLL. The /DLL option is used to build a REF-manifest, a manifest that defines resources required by this DLL. This option can also be uses in place of the /EXE option to build application manifests.
Note that a DEF manifest exposes resources (which Manifest Maker discovers in the target DLL) while a REF manifest uses outside resources. As a result, a DEF-manifest build does not require a project file and ignores the project, if specified on the command line, but requires the DLL to be otherwise complete. A REF-manifest build will execute with no project file on the command line but the resulting REF manifest will be empty. Normally a REF-manifest build should have a project file to make the build meaningful. It does not need to retrieve anything from the DLL itself.
A COM DLL or a CLR DLL may legally have both a REF-manifest and a DEF-manifest. In order for the DEF-manifest build to succeed, the DLL must be ready to execute at the time of /COM processing. If a REF-manifest is needed it must be created before the DEF-manifest. It is recommended that both DEF and REF manifests be embedded as resources in the DLL. This is the default processing for /COM and /DLL options. If the DLL will be signed with Authenticode, both manifests manifest must be embedded before signing.
Normally the manifest is written to the target folder specified in the side-by-side project. With integrated build the target folder is automatically set to the folder of the module specified in the /COM or /DLL command line switch. This is the correct choice in most cases. When it is not, use the /d: option to set the target to the required location.
When Manifest Maker builds a manifest, it also performs validity checking and attempts to fix the manifest, if it is not valid. If the project contains references to DLLs or private assemblies, those assemblies need to be available while the manifest is tested.
The following options control the integrated build (see Command Line):
/com:<dll-path>
Build a COM manifest for the COM DLL <dll-path>, test it, embed it as a #1 resource and delete the manifest file after embedding.
/clr:<dll-path>
Build a CLR manifest for the .Net DLL <dll-path>, test it, embed it as a #1 resource and delete the manifest file after embedding.
It is legal to use /COM with a .Net DLL, it will be silently changed to /CLR.
/exe:<exe-path> <sxs32mm-project-path>
Build a REF-manifest for the program <exe-path> using the <sxs32mm-project-path> project. The project is expected to contain references to resources needed by this program. The manifest is then tested, embedded it as a #1 resource and deleted after embedding.
/dll:<dll-path> <sxs32mm-project-path>
Build a REF-manifest for the DLL <dll-path> using the <sxs32mm-project-path> project. The project is expected to contain references to resources needed by this DLL. The manifest is then tested, embedded it as a #2 resource and deleted after embedding.
It is legal to use /DLL with a program, it will be silently changed to /EXE.
Other options can be used to change the default behaviour of the above build type choices. For example /n: option will change the manifest resource number or /k: will change whenther the manifest is deleted after embedding.