I downloaded the 64-bit Windows SQLite setup executable to install on my Windows 7 x64 machine:
sqlite-netFx40-setup-bundle-x64-2010-1.0.78.0.exe
(11.60 MiB)
and ran the setup. It failed with this error:
Could not open
HKEY_LOCAL_MACHINE\Software\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
There was no "AssemblyFoldersEx" key beneath "v4.0.30319". So I created the key there and re-ran the setup, which completed this time without error.
However, when I try to add the reference, System.Data.SQLite does not appear in the list of components on the .NET tab.
What would be the next troubleshooting step? Thanks
Since VS2010 is Win32 and not x64, you need to install the Win32 setup to get design-time support. You can still use the x64 binaries with your application, the Win32 is only needed for VS integration.
Yes, you need to install Win32 SQLite for design time support; after download and executed 32bit setup (sqlite-netFx40-setup-bundle-x86-x-x.x.x.x.exe), if you still facing the same error you can run the VS designer components 32bit installer without the option checked by following steps:
Open a Visual Studio command prompt.
Change to the "System.Data.SQLite\2010\bin" install directory.
eg: CD D:\Programs\System.Data.SQLite\2010\x86\bin\
Run the following commands:
corflags /32BIT+ /Force Installer.exe
sn -k System.Data.SQLite.snk
sn -Ra Installer.exe System.Data.SQLite.snk
Installer.exe -install true -installFlags AllExceptGAC -tracePriority Lowest -verbose true -noCompact true -noNetFx20 true -noVs2008 true -whatIf false -confirm true
Command explaination:
corflags /32BIT+ /Force Installer.exe
Using the "corflags" tool (part of the .NET SDK), flag the "Installer.exe" tool as 32-bit only
sn -k System.Data.SQLite.snk
Generate any strong name key pair (Any key pair SNK file will work here)
sn -Ra Installer.exe System.Data.SQLite.snk
Re-sign the "Installer.exe" assembly using the above generated strong name key pair
Installer.exe -install true -installFlags All... -confirm true
Run installer with neccessary flags, but the most important is to put in '-confirm true'; as this is the needed flag for SQLite installer which prevent user execute setup by clicking the installer.exe directly in windows explorer.
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'm trying to setup a large number of build agents and so far i can install all the dependencies silently (using powershell, nuget and chocolatey).
However i cannot install the tool IlMerge without the damn GUI popping up.
Ive tried all the usual msiexec switches and they are just ignored. does anyone know of a way of getting this tool on a box in an unattended way?
Or should i just repack the thing in zip/msi?
This is on windows server 2008 R2
If i run
Invoke-Expression "msiexec $installerPath\ilmerge.msi /passive"
I still get a security dialog.
Currently i'm just thinking ill do this:
Copy-Item x:\installs\ilmerge.exe "C:\Program Files (x86)\ILMerge"
seeing as its only one file.
Below worked for me, no security dialogs.
cp ILMerge.msi \\Server\admin$
winrs -r:Server ILMerge.msi /passive
dir "\\Server\C$\Program Files (x86)\Microsoft\ILMerge"
With chocolatey you would have just needed to specify -ia '/quiet' as the package was not silent by default. This was specified by the tag notSilent and it was also in the description (http://chocolatey.org/packages/ilmerge/2.11.1103.1).
The latest package is just the executable, so you can just install it. http://chocolatey.org/packages/ilmerge
I have a .NET 3.5 application that is compiled with a configuration with Any CPU. The application is referencing an OCX file with an interop assembly.
When the application is installed on a Windows 7 32-bit everything works fine. When the same appplication is installed on a Windows 7 64-bit, we get an error:
Retrieving the COM class factory for component with CLSID {CCB90182-B81E-11D2-AB74-0040054C3719} failed due to the following error: 80040154
Using Process Monitor from SysInternals I could see that on the 32-bit OS the system is trying to load the following registry key.
HKCR\Wow6432node\CLSID\{above CLSID}\InprocServer or
HKCR\Wow6432node\CLSID\{above CLSID}\InprocServer32
which are available and that's why the application works.
On the 64-bit version Windows is looking for
HKCR\Wow6432node\CLSID\{above CLSID}\InprocHandler or
HKCR\Wow6432node\CLSID\{above CLSID}\InprocHandler32
None of them exist.
How can it be made to work on Windows 7 64-bit?
Since it's an InprocServer it runs in calling process context. If the calling process is AnyCPU running on x64 platform it can run only x64 COM components.
So you either need to get x64 version of component or compile your application for x86 platform.
If this COM component would be an Local or Remote server that would work as well...
Sometimes can help the next actions:
create an filexx.bat with
#echo un-register
regsvr32.exe completePathOfOcxOrDllFile -u
#echo register
regsvr32.exe completePathOfOcxOrDllFile -u
#pause
#exit
And, of course, run the bat file as admin (right click file and click in run as admin).
my application needs SQL Compact SP1 and SP2 installed (Entity Framework), but there is nothing on MSDN where I can determine silent install parameters for those two files (SSCERuntime-ENU-x86.msi for SP1 and SSCERuntime-ENU.exe for SP2). And on top of that, 64bit SP1 needs to be installed like this: install x86 file and then install x64 file on 64bit machine. Any thoughts appreciated.
OK, I've figured that out myself - all you need is to take these install files, run CMD and run them with wrong parameter, for example: C:\SSCERuntime-ENU-x86.msi -myAwesomeFlag. Because of course given parameter will not be found, install process displays MessageBox with a list of all possible parameters and their options. This works for both servicepacks and .NET 4 installation package.
Generally speaking .msi install parameters are normalised compared to .exe (which can be anything the developper choose). I recommend using this command with those parameters for silent install: msiexec /i SSCERuntime_x86-ENU.msi /qn /norestart
q is for quiet
n is for No UI
norestart ensure that the computer doesn't reboot right now, this is useful if you deploy software with tools like SCCM, Chocolatey, etc. Otherwise if the software needs a reboot it will reboot the computer and if a user is working on it he will not be really happy ;)
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.