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
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
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
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.
for more information.