I have InstallScript Project created with InstallShield X (Version 10.5)
When I run mt.exe from Windows SDK v7.1A with the following manifest:
MySetup.exe.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level='requireAdministrator'
uiAccess='false'
/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
using the following command:
# wrong file! MySetup.exe will be truncated!
mt.exe -manifest MySetup.exe.manifest -updateresource:MySetup.exe;#1
the installer (MySetup.exe) is truncated from ~80 MB to ~110 KB. How do I properly embed Admin Privilege Elevation manifest to the installer generated by InstallShield X?
There is a downloadable tool from InstallShield which modifies the manifest of a built setup.exe or update.exe. At this point I don't recall which versions of InstallShield's output it works with. It will remove digital signatures as it modifies the contents of the .exe file.
http://support.installshield.com/kb/view.asp?articleid=Q113245
(As a disclaimer I am paid to work on the product. I still recommend instead using a version of InstallShield which offers the option to select a manifest. I believe that's InstallShield 12 for MSI setup.exe, and something later such as InstallShield 2010 or InstallShield 2011 for InstallScript setup.exe and MSI update.exe files.)
Use the mt.exe tool to update the manifest of the following files (make a backup first!)
C:\Program Files\InstallShield 10.5\Redist\Package Stub\Setup.exe
C:\Program Files\InstallShield 10.5\Redist\Uncompressed Files\Language Independent\Intel 32\setup.exe
C:\Program Files\InstallShield 10.5\Support\Dialog Sampler\Media\Default\Disk Images\Disk1\setup.exe
C:\Program Files\InstallShield 10.5\Support\Dialog Sampler\Media\Skin\Disk Images\Disk1\setup.exe
with the same command as in the question
mt.exe -manifest Setup.exe.manifest -updateresource:Setup.exe;#1
and then rebuild the installer
If this doesn't work, then as pointed out by Michael Urman in his comment, you need to update the manifest for other stubs. The way I look for the stubs is by recursively search the string 6595b64144ccf1df using Notepad++ in InstallShield installation folder. This value is the publicKeyToken that I find in the manifest of my final installer.
You can use any resource editor like XNResourceEditor or mt.exe to extract the manifest and search for files that contain similar manifest under InstallShield installation folder.
Related
I have a manifest file and use the mt command in makefile to add it into one of my exe files. After it's installed. If I use DPI Awareness Enabler or check the registry in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, it does NOT show anything interesting. Normally if I manually set Compatibility to Windows 7 and disable DPI scaling in file property, it would show up in DPI Awareness Enabler and the registry.
So am I right to assume register is linked only to GUI not the actual file? As if I use mt command to extract manifest file from exe, I can see my original manifest file.
Above all, I don't think my manifest file works as expected. The way I test it is to reproduce a bug in the app. The workaround is set Compatibility to Windows 7 and disable DPI scaling in file property. If I just use the installed file even with manifest file embeded, it doesn't solve the problem. But if I manually change it in property, it solves the bug.
Some extra information, the app is built with VS2010 with hotfix to fix the manifest warning. Not sure if that is the cause.
Any help would be appreciated.
Here is the manifest file
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
</application>
</compatibility>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Here is the part in Makefile
ADD_CUSTOM_COMMAND(
TARGET myExe
POST_BUILD
COMMAND "mt.exe" -manifest \"${CMAKE_SOURCE_DIR}\\res\\dpiaware.manifest\" -inputresource:\"$<TARGET_FILE:myExe>\"\;\#1 -outputresource:\"$<TARGET_FILE:myExe>\"\;\#1
COMMENT "Adding display aware manifest..."
)
Ok, I finally give up on the manifest solution. Just so happen we use wix. So I add some registry values to HKLM->SOFTWARE->Microsoft->Windows NT->CurrentVersion->AppCompatFlags->Layers during installation.
I have a Windows Phone 8 app which I am porting to Windows-10. The app used .vsix extensions for Windows Phone 8, hence I am trying to create a similar .vsix extension for Universal Windows app as well.
My SDKManifest.xml file is as follows:
<?xml version="1.0"
> encoding="utf-8" ?> <FileList Identity = "XXX.UWP" Version =
> "1.0" DisplayName = "XXX Universal Windows SDK"
> TargetPlatform="UAP" MinVSVersion = "14.0" SDKType="External"
> SupportedArchitectures = "x64;ARM" SupportsMultipleVersions = "Error"
> TargetPlatformMinVersion="10.0.10069.0"
> TargetPlatformVersion="10.0.10069.0"> <File
> Reference="XXX.winmd"
> Implementation="XXX.dll"/> </FileList>
My VSIX Manifest file is
<PackageManifest Version="2.0.0"
xmlns="http://schemas.microsoft.com/developer/vsx-schema/2011">
<Metadata>
<Identity
Id="XXX.UWP"
Version="1.0"
Language="en-US"
Publisher="XXX Inc" />
<DisplayName>XXX SDK for Universal Windows</DisplayName>
<Description>XXX SDK</Description>
<License>license.txt</License>
</Metadata>
<Installation AllUsers="true" Scope="Global">
<InstallationTarget Id="Microsoft.ExtensionSDK"
TargetPlatformIdentifier="Windows Kits"
TargetPlatformVersion="10"
SdkName="XXXSDK.UWP"
SdkVersion="1.0" />
</Installation>
<Assets>
<Asset Type="Microsoft.ExtensionSDK" Path="SDKManifest.xml" />
</Assets>
</PackageManifest>
I have all these xml files along with required dll's in a folder say "myVsix". I then zip this folder to creater "myVsix.zip"
Then I rename this to "myVsix.vsix" to create a .vsix file.
When I try to install this by double clicking on the file, I get the following error:
This VSIX package is invalid because it does not contain the file extension.vsixmanifest at the root. The VSIX file may be corrupted.
This is the error log:
3/3/2016 5:46:30 PM - Microsoft VSIX Installer
3/3/2016 5:46:30 PM - -------------------------------------------
3/3/2016 5:46:30 PM - Initializing Install...
3/3/2016 5:46:30 PM - Microsoft.VisualStudio.ExtensionManager.MissingPackagePartException: This VSIX package is invalid because it does not contain the file extension.vsixmanifest at the root. The VSIX file may be corrupted.
at Microsoft.VisualStudio.ExtensionManager.InstallableExtensionImpl.ReadVSIXManifestFromPackage(Stream vsixStream, CultureInfo preferredCulture)
at Microsoft.VisualStudio.ExtensionManager.InstallableExtensionImpl..ctor(String path, CultureInfo preferredCulture)
at VSIXInstaller.App.InitializeInstall(Boolean isRepairSupported)
at VSIXInstaller.App.InitializeInstall()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
It seems that Visual Studio can't find or read the .vsixmanifest file. It must be misnamed or something else is wrong with it.
Instead of creating the VSIX file by hand, you should create it using the VSIX Project Visual Studio template:
If you can't find it in your Visual Studio copy, you should modify your installation and include the Visual Studio Extensibility Tools:
This will automatically create a correct basic structure of the VSIX and even an editor in Visual Studio for editing the manifest which should make it much easier and more convenient to create a valid VSIX.
I am using WIX for my application's setup project, I have to install device drivers along with my application setup. so I have two driver installer files for each x86 and x64 platforms (since I have to use difxapp_x64/difxapp_86 reference file I need to have two separate installation projects), and one application setup project. now based on the platform I want to call either one of the driver installer msi file and the application installer file from one Msi file ( Bootstrapper !?). How can I accomplish this ?
after a bit of search i come to know in wix 3.6 there is a new tool know as 'Burn', this will help me to call collection of installation packages that are chained together.. so I have created a new setup project as Bootstrapper. but when I build its creating the msi file successfully but could not able to run it.. here is the code:
<?xml version="1.0" encoding="UTF-8"?>
<?define version="1.3.0.3"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="Bootstrap" Version="1.0.0.0" Manufacturer="Bootstrap" UpgradeCode="58A81C66-C066-4CA1-9712-D884C11C88BD">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<ExePackage Id="ExeProject"
SourceFile="../../../CCSetupProject/bin/Release/CCSetupProject.exe"
InstallCommand="/q /ACTION=Install"
Name="iCConnectInstaller"
Vital="yes"
PerMachine="yes"/>
</Chain>
</Bundle>
</Wix>
when I click the Bootstrapper.msi file it says "Preparing to install" and then "This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package."
dont know what I am missing here!, anybody got this error before ?
You can't by having two separate packages.
To solve the problem you have to build a merge module for the drivers, and then merge it with the main installation.
By having a separate merge module, you can create an additional package which install only the drivers, or you can use product features to select what is gettin installed.
We have a c++ application which I recently ported from Linux/gcc to build on Windows with Visual Studio 2005. The app uses a 3rd party library which only provides DLLs which use the optimised CRT DLL (i.e. they don't provide equivalents which link to the debug CRT DLL). With VS2005 this didn't seem to be a problem = the debug build found the optimised CRT DLL in the System32 dir.
I'm now trying to build and run our app with VS2008 and the debug build fails to run because it can't locate the optimised CRT DLL (msvc690.dll). The VC9 CRT DLLs are squirreled away in directories with a GUID style name - i believe this is an side-by-side assembly and the app is supposed to locate it using the app's manifest. However the manifest that gets built and embedded in the app exe only specifies the debug CRT assembly:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level='asInvoker' uiAccess='false' />
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
I'm not a Windows expert (not any more at least) so this is all new to me. What is the correct solution here? Do i need to tell the manifest compiler to add the optimised CRT DLL to the assembly? If so how do i do this?
Ok. If you open the 3rd party library dll in VS 2008 (make sure it chooses OpenWith>Resource Editor) does it contain a manifest of its own?
If it does, or even if it does not, its also useful to get DependencyWalker to see which exact runtime dlls this third party library is attempting to link to.
The fact that it worked with VS2005, and not VS2008, implies the dll wants to use the releasemode versions of the VS2005 runtime: msvcr80.dll
You mention msvc690.dll, which doesn't ring a bell with me: Visual Studio 6 used the simply named msvcrt.dll - the first version of Visual Studio to use a versioned dll runtime was VS 2003 .NET or something: msvcrt7.dll
Anyhow, IF the 3rd party library does not contain its own manifest resource, then the easiest thing to do would be to add the dependent assembly references to your applications manifest.
There are a number of ways of doing this - you can create a manifest fragement as a XML file and add it to your applications "Configuration Properties > Manifest Tool > Input and Output > Additional Manifest Files"
I find the most convenient way of merging additional dependent assembly directives in VS2008 is to use the linkers /manifestdependency command line option.
If you add the following code snippet to a file in your project, it will give the linker the necessary hint:
#define X_CRT_ASSEMBLY_VERSION "9.0.21022.8"
#pragma comment(linker,"/manifestdependency:\"type='win32' "\
"name='"Microsoft.VC80.CRT' "
"version='8.0.??.??' " \
"processorArchitecture='x86' " \
"publicKeyToken='????????'\"")
The ??'s are there because I don't know the version numbers or public key token of the VS2005 libraries off hand. if you can look them up and fill them in, it should go swimmingly.
I am creating an .msi package for the application which has a prerequisite for installation.
I am using the Visual Studio 2005 Bootstrapper for this task.
To this end, I did the following:
Located the folder C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ and created a folder for my prerequisite (made it same structure as 'dotnetfx'); created the 'product.xml' and 'package.xml' and placed them appropriately. I kept the xml files very simple so far to test the installation:
product.xml
<?xml version="1.0" encoding="utf-8"?>
<Product ProductCode="MyPrereq" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
<PackageFiles CopyAllPackageFiles="false">
<PackageFile Name="MyPrereq.exe" />
</PackageFiles>
<InstallChecks>
</InstallChecks>
<Commands Reboot="None">
<Command PackageFile="MyPrereq.exe" EstimatedInstallSeconds="90">
<InstallConditions>
</InstallConditions>
<ExitCodes>
<ExitCode Value="0" Result="Success"/>
<DefaultExitCode Result="Fail" String="GeneralFailure" FormatMessageFromSystem="true" />
</ExitCodes>
</Command>
</Commands>
</Product>
package.xml
<?xml version="1.0" encoding="utf-8"?>
<Package Name="MyPrereq" Culture="Culture" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
<Strings>
<String Name="Culture">en</String>
<String Name="DisplayName">MyPrereq</String>
<String Name="GeneralFailure">A fatal error occurred. The installation failed.</String>
</Strings>
</Package>
Now I can add the prerequisite from the list and build my setup project.
The problem:
The build output is the 'setup.exe', the 'MyApp.msi' package, plus the subfolder called 'MyPrereq' which contains 'MyPrereq.exe'.
I would like the build to create a 'setup.exe' and a single 'MyApp.msi', which would contain the 'MyPrereq' inside, with no additional files/directories.
I know that the .NET framework is another prereq for my app, and it is included in the same .msi, so that should be possible somehow.
How can I achieve this?
You can create a self-extracting installer with tools such as IExpress (coming with Windows) containing all files in a single executable (see this SO posting).
You cannot have an MSI file installing its own pre-requisites. First, because Windows Installer itself is a pre-requisite (and must be installed by a non MSI exe) and second because Windows Installer installations are transactional and don't support the chained execution of MSI files. This basically means that one MSI installation cannot start another MSI installation. As a consequence, any pre-requisites must be installed by a separate bootstrapper (by the way, the installation is no longer transactional - the pre-requisites won't get uninstalled if your MSI installation fails).
There seems to be a basic mis-understanding about the bootstrapper mechanism though. The bootstrapper can currently only be generated by Visual Studio or MSBuild. Afaik it is not possible with WiX. Look for the GenerateBootstrapper task in MSBuild (see this SO posting).
I managed to do that with IExpress.
Had to use a small trick, however, which is described here
Creating a bootstrapper for a VS Shell application
Unfortunately, the MSBuild task
doesn't provide the option to have the
configuration resource use
prerequisite installers found in the
target directory, so you must manually
update the appropriate resource file
to remove the hard-coded path that
looks for prerequisites in a
sub-directory of the same name.
Open the Setup.exe program in Visual
Studio's resource editor
Double-click
the resource named, SETUPCFG in the 41
folder
Search for the "Vs Shell\"
string and delete the two occurrences
that appear
Save the resource file
and the Setup.exe executable will be
updated automatically
Run iexpress
Create a new package by following the
IExpress wizard's steps and make sure
to include the following files: The
MyVSShellApplication.msi file The
Setup.exe bootstrapper file The
vs_shell_isolated.enu.exe file
The problem was that bootstrapper puts the prerequisites into a subfolder, and IExpress does not recognise subfolders. Have to be careful while editing 'setup.exe' too, didn't get it correct on the first try.