I have a VSTO addin which will not install on 32bit machines. (the error popup on install is: "This installation package is not supported by this processor type. Contact your product vendor.")
The addin uses Installshield to do the install.
The application builds with "AnyCPU".
It seems to force to 64bit if anything within installshield references a 64bit. (eg I have registry entries for my addin which are its Description, friendlyName, LoadBehavior and Manifest. These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
I don't really know if this needed?
So my fix is to have two releases... where one doesn't have any 64bit registry references.
How would I fix this? I've been toying around with the notion of ditching Installshield LE and moving to vs2017 with some other installer...
I have a VSTO addin which will not install on 32bit machines.
Do you mean the addin is not loaded by Office? or the install package itself fails to install?
I'll assume the addin is not loaded. I don't know how installshield controls the the package components bitness, but I will try to provide an answer that you can apply to any tool, as long as the following options are configurable in the tool.
With MSI packages installing VSTO addins you need to make sure your registry entries end up in the right registry hive, based on the bitness of your installed Office version, not the one of the OS.
So, for machines with Office x86 you have these registry:
on x86 OS: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
on x64 OS & 32-bit Office: HKLM/Software/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin
The two paths above represent a single configuration in your MSI. i.e. if you create a standard MSI that installs the standard x86 registry entries on a 32 bit machine that same MSI will automatically be redirected to Wow6432Node for a x64 machine and everything should work if that machine has a 32-bit office installed.
If you have a x64 machine with a 64-bit office than you need to force the installation of that registry outside of the Wow6432Node, i.e. directly under: HKLM/Software/Microsoft/Office/Outlook/Addins/myAddin
This can be done from a 32-bit MSI too, if you mark the registry MSI component as a 64-bit (don't know where this option is in IS but I am sure you can find it). This will force the OS to stop the redirection to Wow6432Node for those registry entries. And the MSI should also work on 32 bit machines, where this flag will be ignored.
However, you should know that marking the component as 64-bit in a 32 bit MSI package will trigger some ICE errors/warning.
These are located in HKLM/Software (64bit)/Wow6432Node/Microsoft/Office/Outlook/Addins/myAddin)
FYI, this is the 32 bit area of registry on a 64-bit machine, not the 64-bit one. Only 32 bit applications can read registry from this location.
Related
I need to install Microsoft XML Parser 4.0 from Inno Setup.
How can that be done?
I was given a task to embed MSXML in the installer of ours. It's a proprietary piece of software our company makes (for accounting, it uses XML to store and exchange data). Apart from modern systems It's also going to be installed on many old systems using Windows XP.
I'm using Inno Setup 6.1.2.
Also, is there a quiet mode of installation as an option? So the users won't have to click anything and just be notified that MSXML was installed?
Did you Google this?
https://silent-install.net/software/microsoft/msxml_parser/4.30.2107.0
Eg:
msxml.msi /qn /L* "%temp%\XML Parser 4.30.2107.0.log" /norestart ALLUSERS=2
If you look at the Msiexec (command-line options) it does say the qn switch will display no user interface.
Somewhat of an aside, the requirement of installing both on XP and on 'modern' systems may create a conflict that you or your installer will have to resolve.
From Installing and Redistributing MSXML 4.0:
System Requirements
MSXML 4.0 is supported in Windows Server 2008 R2, Windows 7, Windows
Server 2008, Windows Vista Windows Server 2003, Windows XP, and
Windows 2000
From Installing and Redistributing MSXML 6.0:
System Requirements
MSXML 6.0 is supported in Windows Vista; Windows 2000 Service Pack 4;
Windows Server 2003; Windows Server 2003 Service Pack 1; Windows XP
Service Pack 1; Windows XP Service Pack 2.
MSXML 6.0 is preinstalled with Windows Vista. For earlier versions of
Windows, you can install MSXML 6.0 as a separate download.
So you can only use MSXML4 below Vista. And with Vista and above you should be able to reply on MSXML6 already existing.
Your installer could perform an OS version check (alt ref) and then only install MSXML4 if needed. Or you might be able to detect specifically if MSXML6 is installed and then install MSXML4 only if not (assuming therefore its an older system).
But I would test your application (if you haven't already) and see if it will run against MSXML6; it may, without changes. If so then I would forget MSXML4 and include MSXML6 in the installer instead (*). That way your installer could just run it 100% of the time, and expect that on Vista and up it would just do nothing. Your installer would therefore be simpler plus you would be taking advantage of "MSXML 6.0 provides security and performance improvements over earlier MSXML versions." noted here.
(*) Unless you have to run on WinXP pre-SP1?
I am wrestling with an issue I cannot understand. We have a ClickOnce deployment of a WPF application in Azure blob storage. The processor architecture is everywhere "msil" in this deployment. When it gets run from IE, it runs as a 32bit application on AMD64 computers. The desired behavior would be to run as 64 bit. Could someone please enlighten on where should I look to fix this problem?
I already managed to go through the hoops to build the assemblies as x64 and create the ClickOnce deployment as amd64. This combo will run as 64 bit. The desired behavior is to still have it "msil" so it can run as either 32-bit or 64-bit, depending on the operating system it will be running on.
One of our users has an Excel VBA project that references Microsoft Windows Common Controls 6.0. The corresponding MSCOMCTL.OCX file is no longer in our image, and so of course the project won't run due to a missing reference.
Rather than installing Microsoft Visual Basic 6.0 Common Controls on our Windows 7 64-bit systems with Office 2016 64-bit, is there something different that the user can reference in their project that is more modern and supported?
Side question: If we do install it, will it even be able to work, with 64-bit Excel calling a 32-bit OCX?
Answer: I tried on a 64-bit Office installation, and the answer is No. You can install it, register it, and reference it, but you can't actually use any of the UI controls from it. They simply don't appear in the list.
Platform Builder 5.0 is only supported on Windows 2000 and XP.
This question is to aid those looking for a way to run Platform Builder 5.0 on more recent operating systems.
A few reasons one might want to do that:
Corporate IT policy may not permit the use of Windows 2000/XP
With time, genuine copies of Windows 2000/XP may become increasingly hard to obtain
Depending on your overall setup and requirements, might eliminate the need for using a virtual machine for Platform Builder 5.0
You may simply wish to run a more modern and secure operating system
This answer explains how to install and run Platform Builder 5.0 on operating systems it is not officially supported on.
Windows Server 2008 and 2012
This procedure has been found to work on:
Windows Server 2008 (32-bit)
Windows Server 2012
Windows Server 2012 R2
It is recommended that you install Platform Builder before joining a Windows domain. I've had some issues getting the Platform Manager components registered while logged in as a domain user. See also the description further below.
Virus protection software might prevent the installation of .NET Framework 1.1, at least this has been a problem with Symantec Endpoint Protection. You may have to remove any security products before starting the installation (these may be re-installed later, but see the note below on the Full vs. Basic version of Symantec EP).
To install PB5, start by copying the contents of the installation CD (or mounted .iso) to a local folder, from here onwards referred to as the installation folder.
Use an .msi editor (like Orca) to remove the following entries from Microsoft Windows CE 5.0.msi in the installation folder:
OS version check (Table LaunchCondition, Action (MsiNTProductType=1 OR ...)
Emulator device driver (Table InstallExecuteSequence, Action CA_InstallVMMDriver.3D2F911E_A60A_4C07_8F7D_5306DC073E9A)
From the installation folder, run, in this order
ISScript8.msi (installs the InstallShield 8.0 script engine)
dotnetfx.exe (installs .NET Framework 1.1)
Microsoft Windows CE 5.0.msi (installs Platform Builder 5.0)
The installation may appear to hang at the Registering Platform Manager components step. It should proceed after a few minutes. If it is still stuck after, say, ten minutes, and your machine is joined to a Windows domain, then kill the installer in Task Manager, leave the domain and try installing again (you can rejoin after the installation is complete).
During the installation, you will receive a warning about compatibility issues. Select Don't show this warning again and click Run the program without getting help.
After the installation has finished, add a registry entry as follows.
If installing on a 32-bit system:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools]
"SharedFilesDir"="C:\Program Files\Common Files\Microsoft Shared\"
Otherwise (installing on a 64-bit system):
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Shared Tools]
"SharedFilesDir"="C:\Program Files (x86)\Common Files\Microsoft Shared\"
Next, install Windows CE / Platform Builder updates as required (i.e. the "monthly updates" provided by Microsoft).
Optional: If any of your Windows CE targets require CJK support, you will need to update the cenlscmp tool to avoid an error during the makeimg phase. While this bug has long been fixed in Platform Builder 6.0 (PB6), the PB5 version has been left in the dust. So for CJK support you will need to copy cenlscmp from a PB6 installation, i.e. copy C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386\cenlscmp.exe to the corresponding folder in your new WINCE500 tree. Note that I've only tested the PB6 version; it is likely that newer versions would work too.
Optional: If you need support for building SDKs, you must make a copy of the Platform Builder help files, or a hard-coded assumption in the SDK builder will cause the build to fail. Copy the directory C:\Program Files (x86)\Windows CE Platform Builder\5.00\cepb\help to C:\Program Files\Windows CE Platform Builder\5.00\cepb\help.
Launch Platform Builder.
You will see a warning about compatibility issues. Select Don't show this warning again and click Run the program without getting help.
Optional: In the main window, click Tools | Customize. Click the Build OS menu once to open it. Drag the Build and Sysgen menu item out of the menu and drop it when the cursor displays a small 'X'. This will remove a dangerous command that, if clicked by accident, will require reinstalling Platform Builder. Hit Close to dismiss the Customize dialog box.
Platform Builder 5.0 is now ready to use, including the IDE itself, the build system, the help system, the debugger, and the run-time licensing tool.
Features that I haven't tested and which may or may not work include CETK and the emulator (the latter highly unlikely to work, as the emulator device driver had to be removed from the .msi).
If you use Symantec Endpoint Protection, be aware that the Full version may prevent pbxmlutils - an important Platform Builder tool - from running. This does not appear to be an issue with the Basic version.
One last hurdle is to configure the firewall to permit debugger traffic. To do this, open Windows Firewall with Advanced Security and
Under Inbound Rules, hit New Rule...
Select Program, Next
Enter the Path %ProgramFiles% (x86)\Windows CE Platform Builder\5.00\CORECON\BIN\cesvchost.exe, click Next
Ensure Allow the connection is selected, Next
Ensure Private and Domain are selected (but not Public, unless you really need this), Next
Enter a Name, e.g. "Platform Builder 5.0 debugger - cesvchost", Finish
Repeat the above with the path %ProgramFiles% (x86)\Common Files\Microsoft Shared\Windows CE Tools\Platman\bin\cemgr.exe.
Platform Builder will now be able to receive BOOTME frames, upload images, and connect to target with the kernel debugger.
Windows 7 and 8
The procedure documented above will not work for 64-bit Windows 7 or 8 (32-bit not tested).
Modifying the .msi as described makes the installation hang at the Registering Platform Manager components step. Removing the Platform Manager components from the installer causes a number of other issues, including failed registrations of the Help system and some common controls. More importantly, with Platform Manager missing it will not be possible to install any Windows CE/Platform Builder updates, making it virtually impossible to build any non-trivial CE project.
Windows 10
Not tested.
Installation package msi with check conditional "if the workstation is 32 or 64 bit
I need to make an installation package: which checks if the workstation is 32 or 64 bits and by finding. Next, if it is 32 go to Share\Path\ and run the run.exe, and if it is 64 bits, go to Share\path and run the run.exe
I could do this in a *.bat, separate do 32.bat and 64.bat, but will be better to have one .msi with two conditional check, also I need to do this in Visual Studio or another language that would give me a .msi, so I can send the .msi by sccm to my windows envirionment.
Could anyone help me with the code, please?
Thank you!!!
You could build 2 installers one for 32bit, one for 64bit and create a SCCM application adding both those installers as deployment types.
Then for each deployment set the requirements to the operating system types that match.
Then you can deploy them both to the same collection and they will only run on the correct versions. (I am assuming you have one large collection you don't want to break down to x86 and x64 yourself) The others will report back as requirements not met.
Also if you are wanting this for an application catalogue deployment or user deployment same principles will apply. If they are on a 32bit PC the 64bit will not allow the install to start. (Quite possibly wont show on the list of available software)