Build Options Dialog - Build

Help Home User interface Next > < Previous
Quick start guide How to guides Advanced topics User interface Side-by-Side License information
Web Home Free evaluation Download the latest version

Build Options Dialog

Build page

Build

Delete all manifests from target directories.
The intention of this option was to clean up target directory before the project is built. It proved to be more trouble then it is worth and it will be discontinued in a future release of Manifest Maker.
Always use generic processor architecture in assembly references
Normally Manifest Maker builds assembly references using the same 'processorArchitecture' attribute value as defined in the referenced assembly. It may be convenient to use 'processorArchitecture="*"' instead to have the operating system choose the appropriate processor architecture. This is particularly useful when building multi-platform projects using Visual Studio and other build environments.
Update identity in private assembly references
Private assemblies are located in subdirectories of the target folder. If they are a part of a larger build and their version or public key token properties change during build, subsequent build steps will fail if they contain references to these assemblies because these references still use the old version or public key token values. Checking this option tells Manifest Maker to update references at the beginning of build. Note that shared assembly references are never updated (multiple shared assembly versions may exist and be legally referenced at the same time). Library assembly references are always updated.
Use Auto-Fix to correct invalid manifests
When Manifest Maker detects manifest error during build it can guide you through the process of resolving manifest conflicts. This option is highly recommended.
Do not prompt when error can be fixed automatically
Some errors can be fixed automatically. If you wish to see all errors before they are fixed, clear this checkbox. Otherwise check it.
Embed CLR manifests in DLLs
When building manifests for CLR assemblies you have two options. Either save the manifest as a standalone file or embed it as a resource in the CLR DLL. When the manifest is embedded as a resource, the CLR DLL is copied to the target folder. When the manifest is a standalone file (external manifest) the manifest is saved in the target folder and the DLL must be located in a subdirectory due to the assembly search order (see more details here). This means that each CLR DLL will be in a separate folder. If there are dependencies between multiple CLR DLLs in the project, they are easily resolved if all DLLs are in the target directory. At the same time if the DLLs are strongly named and signed, adding the manifest resource invalidates the signature and the DLL must be re-signed.
We recommend embedding manifests as resources whenever possible.
Create new <file> elements...
By default Manifest Maker includes all type libraries found in a DLL inside the <file> tag for that DLL. This may or may not work for the client programs. When this option is checked the first type library (loaded by default by a call to LoadTypeLib or LoadTypeLibEx) is still included inside the <file> tag for the DLL but all subsequent type libraries (if any) are written to new <file> tags with the file name followed by "\2", "\3" and so on. This corresponds to normal behaviour of the LoadTypeLib/LoadTypeLibEx API. We recommend that this check box be always checked unless there is another reason for not doing so. See http://msdn.microsoft.com/en-us/library/ms221027.aspx for more information.