2 files required for the MS DHTML control to work properly were removed from windows vista (and win7, 8 presumably) for security reasons.
These are the DHTMLED.ocx and TRIEdit.dll.
Microsoft now supply a downloadable msi file, dhtmled.msi, which will install and register the 2 components into the following directory:
%windir%\Program Files\Common Files\Microsoft Shared\dhtmled\
I would like to build this into an inno script.
Should I run the installer on my machine first to get hold of the ocx and dll files and have separate lines for each in the inno script or should I incorporate the msi file into the script?
Also what flags should I use to prevent installation on win xp or earlier and when the files are already present?
Thanks
See Replacing the DHTML Editing Control in Windows Vista and Beyond
For new applications, you can ship the installer as part of your product (with appropriate licensing) and chain to it from your own installer. The installer can be run silently and without adding an item to the installed-programs list in Windows. (For details, see the documentation for MsiExec.exe.)
However, we recommend that the installer allow the DHTML Editing Control to be added to the installed-programs list. In addition, when your application is uninstalled, do not uninstall the control; instead, allow customers to uninstall it separately if they want.
Note that this method of installation does not provide logo-compliant installation.
The method that is compliant would be to list this as a prerequisite that the user manually installs before running your installer.
I haven't seen anything the permits redistribution of the naked libraries under any circumstances.
Related
I am (still) using Visual Studio Professional 2013. I've been using InstallShield LE to create the Setup.exe for a Windows 7 desktop app with no issues. However, when installing the app on Windows 10 machines, the app does not run correctly (can't read my ini files for examples). Changing the exe to "run as Administrator" resolves this.
However, I have to go into every Windows 10 install and change this manually. Not practical.
Is InstallShield LE on 2013 NOT Win-10 compatible (e.g. need to upgrade to VS 2016??) or is there a setting in LE that can be changed for compatibility with Windows 10?
It is possible to modify the ACL on the settings files (during installation) to make them writeable for standard users. This is commonly used, though very undesirable. See issue 14 here in a list of common design problems in MSI files: How do I avoid common design flaws in my WiX / MSI deployment solution?
I doubt Installshield LE has any features for this ACL modification. WiX does, as does the commercial edition of Installshield and Advanced Installer. There are other tools as well that may support it.
Another "solution" that I don't recommend, but that is still used by many: How do I force my .NET application to run as administrator? I suppose this is effectively what you are doing? See this answer as well for an important note (it is a different answer from the same "thread").
The real solution is to re-design your application to not store settings files in the application installation directory, but rather store your settings in HKCU in the registry, or in a settings file stored in the user profile. Regular users can obviously write to these locations.
Not 100% the same, but very related. An answer with a list of options to allow an application to write to HKLM in the registry: Per Machine App Registration. Recommended read / skim.
I'm using Advanced Installer in my product. as part of the installation, the installer installs c++ redistributables that my product needs in order to run. my question is how to prevent the user from removing the c++ redistributable installation in add/remove programs? is there an option to use reference counting on 3rd party products that the installer installs?
Have you considered using merge modules to install your redistributables? Instead of separate standalone installers. This is supported by Advanced Installer too.
This should prevent them from appearing in Control Panel, but they will also be uninstalled together with your application.
If you want to prevent the user from removing the redistributable installation from Add/Remove programs, please see the MSDN documentation: Configuring Add/Remove Programs with Windows Installer. You could use the ARPSYSTEMCOMPONENT property to prevent the redistributable from being displayed in the Add or Remove Programs list of Control Panel. This should hide the redistributable installation, but you can still use the Windows Installer to install, uninstall, repair, and reinstall the application. If the user uninstalls your application, it should be designed to also uninstall the redistributable. The recommended alternative to using concurrent installations is to instead use a setup application and external UI handler to install several Windows Installer packages sequentially.
Note however that Microsoft recommends that no one use concurrent installations to install or update a shipping product. A concurrent installation action installs another Windows Installer package during a currently running installation.
I have a vb6 application installed on a server. It works perfectly.
I am trying to relocate it to a different server, however I get an error: "Component: TABCTL32.OSX or one of its dependencies is not registered". TABCTL32.OSX does not exist on this server.
On another Windows 2003 server I get a different error saying another component is not registered. I read somewhere that VB6 is not installed by default on Windows Server 2003 and I read somewhere else that it is. Is there a way to see if it is installed? I am unsure what to look for in Add/Remove Programs. Do I need to install this: http://support.microsoft.com/kb/192461?
As suggested by the topic Windows Server 2003 includes a new version of Msvbvm60.dll this OS certainly does include the VB6 core runtimes. However it is not guaranteed to have the base subset of auxiliary VB6 libraries Microsoft began calling the "Runtime Extended files" in Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8.
In any case tabctl32.ocx must always be deployed anyway since it isn't included there.
The package described in VBRun60.exe installs Visual Basic 6.0 run-time file that you provided a raw link to is a sort of kludge and in any case is only meant for older versions of Windows (NT 4.0, Win9x) in the rare cases where you'd use it.
The VBRun60.exe file is not intended to replace the Package and
Deployment Wizard (PDW) for distributing Visual Basic applications.
For that matter it doesn't contain or have anything to do with tabctl32.ocx anyway.
Essentially what you are asking is not a development question and isn't appropriate for StackOverflow. It is an administrative issue more appropriate to somewhere like ServerFault instead.
If you aren't deploying this application using a proper installation package then that may loosely be considered a development issue, though it still really isn't.
Redistribute and register tabctl32.ocx in your setup.
If you do not have a setup, copy that file - preferably into (32 bit) windows\system32 folder or into the application's folder and issue the command regsvr32 tabctl32.ocx from within a command prompt with administrative privileges.
Is it possible to create MSI package, which will run without Windows installer installed in system, but first will install Windows installer itself, and then continue installing other components?
The goal is to create prerequisite package for our software, which must install some components, including some operation system service packs. We also prefer using MSI package. But it's obviously to us that our software will be installed on clean operation system. Though there will not be needed Windows installer present. Is it possible to create such prerequisite package using MSI?
No, there is no way to install an .MSI package without Windows Installer already being present in the OS.
However, Windows Installer has been a native part of Windows since Windows 2000. Are you really developing installers for Windows 95/98/NT4? That would be the only case where there is no Windows Installer support and you'd need to install a redistributable MSI package first.
Unless you meant to say that you require a higher version of Windows Installer than is native to one of the older OSes? (e.g. MSI 3.1 for WinXP) In that case, you'll need to bundle the .MSI redistributable for the MSI package you desire and run that first. Sometimes a reboot is required, other times not. YMMV.
One way, you can write an application in cpp or c or any language that does not require any additional frameworks or SDKs, to check for the installer and install it programatically.
It sounds like you need a bootstrapped with two or more msi files in it. Take look at the WiX documentation. WiX has build-in bootstrapped
Hope this helps
s
We are working on a winforms app in Visual Studio 2005 and the setup project we created output both an MSI and an EXE. We aren't sure what the EXE file is used for because we are able to install without the EXE.
It's a bootstrapper that checks to make sure that the .NET Framework is installed, before launching the MSI. It's pretty handy.
I suggest using something like SFX Compiler to package the two together into one self-extracting .exe and then launch the extracted setup.exe. This way you retain the benefits of the bootstrapper, but your users only download a single thing.
Edit: also see
The official line: MSDN documentation
Some bootstrapper customization: some guy's blog post about what he did
The EXE checks if Windows Installer 3.0 is present and downloads and installs it if it's not. It's needed only for Windows 2000 or older. Windows XP and newer all have Windows Installer 3.0 out of the box.
Other prerequisites, like .NET, are checked for by the MSI itself.
I think the EXE is just a wrapper/bootstrapper for the MSI in case you don't have Window Installer. If you have the requisite Windows Installer version installed then the MSI should work fine on its own.