I updated to the version here where it installs it per user instead of all.
How do I install for all users instead? Do I need to install for each user now?
Look for the system installer instead of the user setup installer. The system installer will give you the option to:
1. Install for all users
2. Choose a directory.
Download here (oficial page): https://code.visualstudio.com/download
Can't find it? The system installer is below the big blue button to download. You'll see 3 options. The middle option will say system installer.
Applications that are global are stored in /Applications directory as opposed user specific installation that are installed under Applications under the user home directory. So moving the installed folder to /Applications directory might work.
Related
I might have installed the wrong version of Oracle SQL Developer (Version 4.1.4) on my Win 10 laptop. So I want to uninstall it and install a newer version.
Any idea what´s the easiest way to do it?
Find the directory it was unzipped to, e.g. C:\Program Files\sqldeveloper, though it could be anywhere - quite likely in your downloads directory; and just delete that entire sqldeveloper directory.
There is no installation as such, it's just a Java application sitting in a directory.
Settings are held under your personal home directory, and when you unzip and run the later version (18.2 is current) you'll be asked if you want to migrate those settings, which will include any connections you've already defined.
Read more in the 4.1 documentation.
It is not installed so you can't uninstall it. To remove it from system do following:
Delete base directory, where you unziped it (where you run it).
Delete your user connection data - folder C:\Users\<username>\AppData\Roaming\SQL developer
If you don't have any other oracle software, delete your user configuration data - folder C:\Users\<username>\Oracle
Visual Studio code offers User and System Installer but I have not found any description about the differences between these two options.
Could someone please shed a light on this for me?
User setup for Windows
Announced last release, the user setup package for Windows is now available on stable. Installing the user setup does not require Administrator privileges as the location will be under your user Local AppData (LOCALAPPDATA) folder. User setup also provides a smoother background update experience.
Download User Setup
If you are a current user of the system-wide Windows setup, you will be prompted to install user setup, which we recommend using from now on. Don't worry, all your settings and extensions will be kept during the transition. During installation, you will also be prompted to uninstall the system-wide setup.
Reference: https://code.visualstudio.com/updates/v1_26#_user-setup-for-windows
I installed the user version side-by-side with the system version with no problems. The basic differences between the two is that the system version installs on the file system like every other app. The user install is basically a click-once (or web installer) version that installs in the User folder of the machine.
The settings made to VS Code in the system version save for Everybody on the computer and the user version the settings are only for the user. I find that the behavior of the user version is a bit annoying for me because I have reasons to want to open multiple copies of VS Code at the same time and the user version only allows one instance. Otherwise, there's not really anything different between the two as far as I can tell.
Many companies (like mine) dont allow Admin privileges, I think that's the main point so you can still install VSC with the user installer
After user version of Visual Studio Code is downloaded, make cmd in the download folder and run a command below, replacing the correct version in the VS ode installation file name:
runas /trustlevel:0x20000 ./VSCodeUserSetup-x64-1.74.3.exe
start the command below in order to check which trust levels are supported:
runas /showtrustlevels
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.
The Code documentation suggests that it is added to the PATH during installation, but that did not seem to work for me (at least not in PowerShell). Where is it installed such that I can add it myself?
The install path is C:\Users\username\AppData\Local\Code
C:\Users\username\AppData\Local\Code\bin is added to the PATH by the installer, but it might be that tools such as PowerShell will pick this change up only until after a log off/log on or a restart
On macOS, VS Code these days seems to have a Command Palette (shift + Cmd + P) command to install it to the path called "Shell Command: Install 'code' command in PATH".
It seems that a good old restart of the box fixed the issue. Interestingly, merely restarting PowerShell or logging out and back in didn't fix it.
Modern Software Installation.
Many of the larger software packages have finally caught-up with the times. Make sure the correct choice(s) are made during the software download and during the software installation.
Most individual PC users are the sole users of their PCs. Yet many software packages have always defaulted the installation processes to assume otherwise. This is why so many software packages install to a path that includes C:\ .... user\ ...
But most of us individual PC users don't want the software installation including a path that involves using the ... user\ ... path. And instead we want the software installed into the default C:\ path without the "user name".
Some of the most common software installation packages are becoming available for the individual PC user and these packages install on the PC in our preferred path - (not involving a path through the ... user\ ... ).
And if there is not a separate download package for the individual PC user, then during installation make sure to closely read each step which will often now include a checkbox of whether the installation is for a "user" or for "all users". Select all users.
When you install your product locally, all the needed files are stored in the machine.
When you set the features to Advertise, files will be installed locally when the user launches the application.
What happens then when yo set the features to "run-from-source"? I Googled it and was only able to find this: http://msdn.microsoft.com/en-us/library/aa367538%28v=vs.85%29.aspx
Thanks!
This is a rarely used feature of Windows Installer and I don't normally reccomend using it. It was invented back in a day when hard drives were small and the thought was you 'advertised' ( pretend install aka install source ) a feature and that when the user clicks the shortcut it would go to the source and finish the installation of the feature ( aka install local )
It just adds a lot of complexity to your servicing model. It's not worth it IMO.
When placing all installation files next to the MSI (similar to advertised installation), you can install features from source. This means that all files in these features will be used from the MSI location (they are not copied in the target folders during install).
Running from source can be used when the installer remains permanently on the target machine. So the application can use the installer directly instead of using installed files.