On a Windows workstation after a recent update of VSCode I'm prompted (recommended) to install a "User Setup Distribution of VSCode for Windows"
The link for more info leads to:
Download User Setup
If you are a current user of the system-wide Windows setup, you will be prompted to switch to the user setup, which we recommend using from now on. Don't worry, all your settings and extensions will be kept during the transition.
I don't see anything that explains what changes this distribution makes or how it's different from a distribution for other platforms, like X11/linux.
Code is a great editor, so I use it on various platforms depending where I am. Where is the explanation of what is included in this updated "Distribution"?
https://code.visualstudio.com/updates/v1_26#_user-setup-for-windows
Famous Question Badge Celebration! : love to VSCodium https://vscodium.com/ ... and highly recommend to anyone interested in this Q.
VSCode User Setup is a new installer, with a new install strategy, which installs the whole executable for VSCode and its dependencies in directories which don't require system-level / administrator permissions to modify. This allows a few things:
Users who don't have admin privileges to their workstation can still install and use VS Code
VS Code can perform its updates with fewer prompts (basically without the system-level privilege escalation prompts)
One tip: If you already had VSCode installed as a system-wide installation and you switch to the new installer as prompted/recommended, the User Setup installer will suggest that you uninstall the system-wide install first. I was a little nervous that I might lose my extensions doing this, but I went ahead and tried it and am happy to report that my extensions, recent projects, and other data regarding my VSCode use remained intact between uninstalling the "old" version and then proceeding with install of the new User Setup version.
(I'm a first time responder after many years.)
Note there is another useful discussion on this subject at: (What is the migration procedure for moving from Windows system-wide Visual Studio Code to user setup?). I too got worried when I got unexpected messages from the install informing me that the version was already installed and asking me if I wanted to continue? I clicked NO, why continue if it is already installed. However, in the process I became aware of the distinction between 'distribution' and 'version'. It turns out that the install works pretty much flawlessly no matter how you go about it. You can delete the system-wide distribution or not. If you do delete, you can delete before the new install, (which I did). You can also delete after the new install. (I didn't read too closely but there might be an extra step if you want to use both distributions.) In hindsight, since all approaches work nearly flawlessly, a minimal amount of instruction is all that was required. But in foresight, a little extra information on what to expect would have expedited the process for several people, including me. P.S. I found the answers in this thread useful. Thanks.
From the page you link to:
This setup does not require Administrator privileges to install. It also provides a smoother background update experience.
Related
So I've read that when installing Visual Studio Code, the User Installer is recommended because it installs to the Users folder and does not require administrator privileges, but apparently it also allows for better background updating of the program.
However, when I try to install the User Installer, I get the following message:
This User Installer is not meant to be run as an Administrator. If you would like to install VS Code for all users in this system, download the System Installer instead.
I tried installing it once before by accepting this, but the title bar of VS Code will show "Administrator," so I'm wondering what was the point of the User Installer if it still warns me of administrator privileges and still installs with them? If it installs to the Users folder, why would it even show this warning message? Is there a way to avoid this?
If not, will this cause any issues, like slowdowns or such? Do I still get the benefit of the smoother updating that the User Installer supposedly gives?
Stealing from this answer, I see that visualstudio.com says:
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.
That suggests to me that the error message we've both seen will soon be obsolete.
That is, when the installer sees you logged in as admin (which conventionally means you wouldn't be coding), it assumes you wanted this now-intended-to-be-deprecated use case where you're installing once on the system for ALL users, which the user setup won't do.
You've probably seen installers ask this: "Do you want to install for all users or just your user?" If all users, it asks you to give the installer admin permissions and installs in Program Files. If just you, it installs in a user path (like VS Code for users does: C:\Users\thySmyUserName\AppData\Local\Programs\Microsoft VS Code).
Instead of a unified system/user install, VS Code seems to have broken it into two.
Make sense? If you're installing to code when logged in as admin, like on a remote box or something, that might still be a bit of an admin smell, but the user setup sh/w/ould otherwise be fine.
If you wanted to install for every user on the box, which you could do with your fancy admin permissions, you'd need to get a different installer. That's all.
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 have built an application that installs and runs fine on my Windows computer on the first install. I wish a computer novice to be able to re-install it from scratch. At this time, I have to manually delete the directory where the installer puts it. C:\ProgramFiles..... This is trivial code that I would know how to write, if I could get to a pre-install area within the deployment installer. How can I get this code into the deployment installer?
Alternately, is there an option the user could push to delete the previous version. The deployment
installer obviously knows that the previous files are already there? Other installers say something like "Do you want to re-install" and then take care of the problem.
I would also like to include my version of the java virtual machine with my deployment. I have found several descriptions of how to do this, but they do not always agree.
I am new to java, ant and Netbeans but have over 50 years programming experience. This is an elegant solution to many standard programming problems. It seems a shame that two conceptually simple
holes should exist.
Ann Maybury
Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.
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.