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.
Related
I'm on a Windows 7 (64-bit) box and do not have admin rights.
It appears from the MongoDB download page (see http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/) that the latest version only an MSI install is available (no zip version).
I tried running the 3.0.4 MSI. I clicked custom so I could change the directory to install to. I used %USERPROFILE%\MyProgs\MongoDB-3.0.4, so no admin rights would be needed. It ran for a bit but then prompted me to enter admin credentials. I hit escape (like clicking on X at top right) to close the window. On other MSI installs this has worked. I tried it again and clicked "No" but in both cases received the message
MongoDB 3.0.4 2008R2Plus SSL (64 bit) setup was interrupted.
Your system has not been modified. [...]
This article does a GREAT job going through how to install MongoDB on Windows:
How to install mongoDB on windows?
My observation is that v2.4.14 is the last version that is available via the ZIP format. So for now, I'm using that version.
Is there any other way to install the MongoDB version 3.X MSI without admin rights?
NOTE: On the MongoDB Download page https://www.mongodb.org/downloads there is a link titled View Build Archive (it sends you here https://www.mongodb.org/dl/win32/x86_64-2008plus-ssl, and that site lists *.zip formatted files). I thought I had found my own solution to the question, but when I unzipped the files, and added the "bin" to my path and ran the programs (mongo, and mongod) I received an Windows Dialog that says:
mongod.exe - System Error
The program can't start because LIBEAY32.dll is missing from your
computer. Try reinstalling the program to fix the problem
I stopped here and posted this question. Thanks for any help.
For now I'm using the version that supported the zip format (v2.4.14) and that version does work.
NOTE2: The v2.4.14 zip formatted install doesn't have a file named LIBEAY32.dll), or I might have tried using that file with the newer version.
Yes, it is possible to install the latest MSI (including the one with SSL) without admin rights via command line.
msiexec /a mongodb-win32-x64-3.2.5.msi /qb TARGETDIR="C:\MongoDB"
This will copy the binaries into C:\MongoDB\MongoDB\Server\3.2\bin
I dislike long paths like that, so I create a symlink inside the folder:
cd C:\MongoDB
mklink /j bin C:\MongoDB\MongoDB\Server\3.2\bin
That will create a soft link as C:\MongoDB\bin (which you can add to your PATH environment variable).
mongo --version
mongod --version
Both should return version 3.2.5.
You can do this with most packages, we have to do similar with Python 2.7 and Node 4.4.3 MSI packages on work computers that do not have admin rights.
You can download the "legacy" version which is the unsigned non msi version as a zip. The disclaimer is listed as
The 64-bit legacy build does not include SSL encryption and lacks
newer features of Windows that enhance performance. Use this build for
Windows Server 2003, 2008, or Windows Vista
The 3.0.5 version is https://fastdl.mongodb.org/win32/mongodb-win32-x86_64-3.0.5.zip
The latest version is available as zip download.
[https://www.mongodb.com/dr/fastdl.mongodb.org/win32/mongodb-win32-x86_64-2008plus-ssl-4.0.6.zip/download][1]
Download and Unzip into folder where user has permissions e.g c:\users\xxx\mongodb.
Enter the path to bin folder (e..g c:\users\xxx\mongodb\bin) into the
environment variable 'PATH'. To access path variable press Win + R
and then enter rundll32 sysdm.cpl,EditEnvironmentVariables.
Select Path and click edit. Then enter new and there enter the path
to bin folder. Click OK and OK to save and exit.
Check Mongo version from command line using command mongo --version.
Note: Don't forget to create db folder in C drive that is required for mongo to work locally. All set.
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.
Have installed 11g in Windows 7 (64 bit machine). Since the SQL developer wont work with 64 bit jdk.
Installed the 32 bit jdk1.7.0
and changed the ORACLE_HOME\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf file SetJavaHome point to 32 bit jdk1.7.0.
Again started the SQL developer, but it throws msvcr100.dll missing. Find that the SQL Developer3.x supports at max jdk1.6.X.
Even tho the question is answered I would like to point out that downloading random DLLs from untrusted sources should be avoided.
If you are missing MSVCR100.DLL just install the correct redist for your platform.
32Bit: Microsoft Visual C++ 2010 SP1 Redistributable Package (x86)
http://www.microsoft.com/de-de/download/details.aspx?id=8328
64Bit: Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)
http://www.microsoft.com/en-us/download/details.aspx?id=13523
Cheers,
Antonio Huete
These information is specified in ORACLE_HOME\sqldeveloper\releasenotes . So install the jdk1.6 and make the sqldeveloper.conf SetJavaHome point to this.
other workaround is go to jdk1.7.0 installed path jdk1.7.0\jre\bin copy msvcr100.dll and paste it into ORACLE_HOME\sqldeveloper\sqldeveloper\bin and again try start SQL Developer. It will start.
And The file is from
This file was downloaded from: http://www.dll-files.com
If you downloaded it from somewhere else, please let us know: http://www.dll-files.com/contact.php
Installation instructions:
Extract the .dll file from .zip file. We recommend that you extract the .dll to the installation directory of the program that is requesting the .dll.
If that doesn't work, you will have to extract the .dll to your system directory. By default, this is:
C:\Windows\System (Windows 95/98/Me)
C:\WINNT\System32 (Windows NT/2000)
C:\Windows\System32 (Windows XP, Vista, 7, win 8)
If you use a 64-bit version of Windows, you should also place the .dll in C:\Windows\SysWOW64\
Make sure to overwrite any existing files (but make a backup copy of the original file for safety).
Reboot your computer.
If the problem still occurs, try the following:
Open Windows Start menu and select "Run...".
Type CMD and press Enter (or if you use Windows ME, type COMMAND)).
Type regsvr32 .dll and press Enter.
If you have any other problems, see our HELP-section at www.dll-files.com/support/
I have just downloaded latest 4.1.3 version with jdk included - Windows 64-bit with JDK 8 included to my Windows Server 2008 R2 64-bit and faced the same problem. Could not start sqldeveloper.exe, because "msvcr100.dll is missing from your computer".
I did not want to install any additional bloatware, so what I did:
take msvcr100.dll from original download SQLDeveloper folder sqldeveloper\jdk\jre\bin
and copy it to Your's oracle installation bin folder, in my case - C:\oraclexe\app\oracle\product\11.2.0\server\bin
SQL developer started!
Edit (path)\sqldeveloper.sqldeveloper\bin\sqldeveloper.conf with Notepad++ or some other advanced text editor. Don't use Windows Notepad for this.
Locate the SetJavaHome variable. Replace "../../jdk" with your regular PC Java source. On mine it was "C:\Program Files\Java\jdk1.8.0_73".
The line looks like this when you're done:
SetJavaHome C:\Program Files\Java\jdk1.8.0_73
Save and exit.
I got this error while running Oracle JDeveloper.
I have copied the msvcr100.dll file from C:\Windows\System32 to C:\Program Files\Java\jdk1.8.0_261\jre\bin.
It worked for me. Also check the enviromental varibles settings.
The JDK needs msvcr100.dll to either be located in the same directory as sqldeveloper.exe OR already be installed on a Windows machine in a location defined in environment path variable. In testing SQL Developer install on various Windows 7 machines where I have other software installed (not a clean machine), the msvcr100.dll is installed on C: \Windows\system32\msvcr100.dll.
you may get it from sqldeveloper\jdk\jre\bin\msvcr100.dll(refer your installation dir)
I was facing the same issue and it worked for me.
For me the solution was to simply upgrade SQL Developer. When work changed over my laptop I copied SQL Developer between machines and I got the above error except for msvcr120.dll. I copied that dll from my old machine but then it needed another and then another. So I downloaded the latest version of SQL developer and the errors went away. It might not solve the issues for everything but I think updating to the latest version should be done before trying any of the other solutions.
I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.
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