I have a vb6 application that will be accessing a network Postgresl 9.3 database via ADO.
This is a portion of the connection string
Provider=MSDASQL;Driver={PostgreSQL ANSI}
What (if anything) do I need to distribute with my application to guarantee that the provider/driver combination will be present on windows machines (xp and up)?
Thank you.
Bundle the psqlODBC MSI:
http://www.postgresql.org/ftp/odbc/versions/msi/
Just run it with msiexec /i THEDRIVERMSI.msi /passive /n from your installer.
It comes with the required libpq, OpenSSL, etc. You might need to make sure the correct Visual Studio runtime is installed, I don't remember if it auto-installs that.
If you want to make it invisible to users, bundle it as an msm that becomes just another component of your application's MSI installer. You have to recompile psqlODBC to generate the msm, see the winbuild and installer folders in the source code.
Related
I have installed DB2 10.1 in AIX 7.1 at /opt/IBM/db2/V10.1. But there is a script which is expecting DB2 at /opt/db2_10_1.
I am not sure if it is possible to change the directory of an installed software and if I do it, what are the points I have to keep in my mind before performing this step.
FYI- I am not an AIX or DB2 expert. I am just performing this task as instructed.
Did your instructions specify a non-default path for the Db2-installation?
(The path /opt/IBM/db2/V10.1 is a typical default for AIX )
Do not manually hack to change the installation directory of Db2, just because a script is badly written! Responsible admins would never allow such mistakes on production environments.
It is an error for a script to hard-code a Db2-installation path. That script should be coded correctly to determine the Db2-installation path, or to have that information provided via configuration or arguments.
A possible option is to create a symbolic link so that /opt/db2_10_1 points to the real path at /opt/IBM/db2/V10.1 , but this is not guaranteed to work for all situations, it depends on how badly written is the script - so other different errors may appear later from that script (although Db2 itself will function normally).
A separate matter is that it is unwise to install a Db2 version that is already out of support (end of life). Does the business understand the consequences of installing an out-of-support version? (unless the business has purchased an extended support contract from IBM).
You have to make new install
stop instance
rename sqllib directory
recreate instance using db2icrt in new binaries in install directory
import catalogued database with db2cfimp previously exported using db2cfexp
What would be the best way to deploy upgrades to a piece of software with the following requirements:
The upgrade:
Must be run from a client machine, not a server.
Must Show a dialog to select a network location and copy files to a share.
Must show a dialog to enter SQL Server connection information and the upgrade must connect to SQL Server to run an upgrade script.
Must not change anything on the client machine from which the upgrade is run. (Nothing in Add/Remove programs, registry, etc. I.e. no Windows Installer.)
Must not rely on any additional dlls or frameworks. The user must be able to download a single file and run it from Windows XP SP2 without having to install anything else.
Some things I have looked into:
Batch files (can’t show a dialog to allow the user to enter connection information)
OSQL (can’t show a dialog and can’t copy files)
WiX (runs on top of Windows Installer so it puts things on the client machine from which it is run)
Custom C#/VB app (requires .NET framework)
Winzip/WinRAR (can't show a dialog, can’t run SQL Scripts)
If you don't want to rely on any dlls and frameworks, you should make a native app, this can be, for example, custom winrar sfx (you can run additional scripts after extraction, this can be a batch that executes sqlcmd).
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.
We have a windows app and we were using Wise for deployment. Recently we switched to InstallAware and though it has some good points we are facing some issues. Can someone recommend another deployment and packaging app? We are a small company and we do not have a dedicated staff for packaging etc. Also our package includes SQL server express installation and we would love to have the simplicity of such includes as is in IA.
How about NSIS or InnoSetup? They're both widely used, and not that hard to use. (If you choose InnoSetup, also download ISTool, it's a lot easier than writing the script file manually.)
We've used NSIS several times, both for full regular desktop installers, and for small, silently installing patches. It's easy to write a basic installer, especially if you use HM NIS Edit which acts as a wizard and IDE for NSIS. Because it's scriptable, you'll be able to check if SQL Server Express is already installed - if not, it can be installed as part of your installer process.
I have never used anything but Windows Setup and the setup projects that come with Visual Studio. Do you have any unusual requirements that prevent you from doing that?
I assume your requirement as follows,
You are using wise package studio to create\customize the application to create MSI and these msi package will be deployed or installed to your environment.
My question is : How many desktops \laptops are their in your company (Infrastructure)
Solution to your question based on my assumption:
At present Admistudio is the best product to replace the Wise and you can use Installshield repackager to create or customize the applications.
Install anyware is used to customize the Dll files (Build and release method) and create custom actions in that build file and build it to MSI
Installshield Repackager is used to create MSI from Exe files and also customize existing MSI using transform file (no need to modify existing MSI instead we can create MST file to MSI and perform the customization to MST file and same file will be applied while deployment.)
Please let me know if you need further assistance.
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi