vscode-remote-release
vscode-remote-release copied to clipboard
microsoft
Can't open vscode offline in WSL when there is update
- VSCode Version: 1.49.3
- OS Version: wsl
Steps to Reproduce:
- Make sure you are offline and don't have the lastest version of vscode
- Open WSL (Windows Subsystem for linux)
- run "code " to open vscode
- Vsode will delete and try to update even if you are offline.
Does this issue occur when all extensions are disabled?: Yes
I been frustrated by this, because I don't have access to internet all the time. I end up using another editer.
This is what I am taking about:
❯ code .
Updating VS Code Server to version d2e414d9e4239a252d1ab117bd7067f125afd80a
Removing previous installation...
Installing VS Code Server for x64 (d2e414d9e4239a252d1ab117bd7067f125afd80a)
Downloading: 100%
Failed
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/home/hamza/.wget-hsts'. HSTS will be disabled.
--2020-10-12 18:31:20-- https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘update.code.visualstudio.com’
ERROR: Failed to download https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable to /home/hamza/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a-1602520270.tar.gz
But sometimes it is different error too. Because sometimes it doesn't fully xdownload.
This makes VSCode unusable on spotty WiFi or if you have to restart VSCode for any reason after losing connection for an extended period of time (flight, outage, whatever). At this point I'm now considering leaving VSCode Remote for VSCode running in WSL itself just to avoid this problem.
I don't understand why it's not possible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning.
tl:dr It seams like on what @aeschli mentioned at #5104 an update get triggered if vscode mismatch vscode server. Base on that fact a workaround could be disabling Auto Update in VSCode settings.
I definitely agree with @pluma and the fact that every new version is not compatible with previous version of WSL server make very little sense.
This quite unreasonable and painful behavior. To add a bit more details to this issue the problem is coming from bootstrap script wslDownload.sh
Here is the piece of code that remove the previous version.
# This version does not exist
if [ -d "$VSCODE_REMOTE_BIN" ]; then
echo "Updating VS Code Server to version $COMMIT"
# Remove the previous installations
echo "Removing previous installation...";
rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????
rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????
rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????.tar.gz
fi
I guess one solution could be is to check for internet connection before removing. However it seam unsound to do it in this download script. I'm trying to understand what trigger VSCode to update in the first place in case user is offline. I think, it would make most sense to do offline check before triggering the update procedure and just fall back to the installed version of VSCode server.
Would it be possible to prevent VSCode from auto-updating when exited while offline, if the remote extension is installed?
I could also imagine VSCode's auto-update having a notification like "A new version of VSCode has been downloaded in the background. VSCode will be updated the next time you exit the application" with a button for preventing that. Or at least a flag to prevent the auto-update while offline.
sible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning
I use wsl with visual studio it still does the very same thing
just ran into this issue on the train.
Windows seemed almost workable when using WSL ...
+1 I hit this on a flight this month thanks monthly update cycle. Even more discouraging was learning that there is seemingly no straightforward way to disable this behaviour, e.g. no quick flag to start it up anyway.
I think the following sequence is shortsighted where the previous installation is deleted first, and then fetching the new version is attempted:
$ code .
Updating VS Code Server to version 8dfae7a5cd50421d10cd99cb873990460525a898
Removing previous installation...
Installing VS Code Server for x64 (8dfae7a5cd50421d10cd99cb873990460525a898)
...
Seemingly another manifestation of MSFT-branded product overlooking real-world on-the-road use-cases re the lack of thoughtful/elegant handling :-P. No doubt y'all work hard, please take a real vacation one day and venture off the grid for a bit to experience this first hand!
In case it is not clear, the desired behaviour is:
- Developers should not be blocked from using VSCode in cases where an Internet connection is unavailable or intermittent (important: including any extensions that they may depend on).
- VSCode provides developers an elegant path to start-up in a scenario where docs/web/etc. are assumed to be inaccessible (i.e. no assumptions that the dev is in a position to look anything up / no data can be fetched; for example, if a seamless startup can't/won't be implemented, the command output to
codein WSL2 on failure should suggest flag/alternate command to unblock the developer and get them coding).
A not-great quick workaround to suggest for now is if you plan on coding while on the go is to start VSCode before you embark and leave it open...
However beware there are still cases where VSCode can still get a bit hairy and require a full re-start -- e.g. a case would be if some extension updates were installed automatically in the background while a connection was still available.
Maybe you are talking gold, but maybe also you should not be using WSL, in flight?
No offense intended
Unfortunately, our implementation mandates that the client and the server version match. A client cannot work with a server that has a different version. Keeping the old server doesn't help, we simply can't use the old server anymore, unless you revert the version of the client.
But yes, I understand that this is a real issue. Ideally the VS Code installer we could bundle the client and server download.
There is a reason why we all use Vscode. It is not perfect, but good enough.
I want for Vscode to be fixed, and maybe "a client and server download" is the way to go. Otherwise, there are may be other solution, such as delete the broken code from now.
@hamza512b why close the issue?... at this time there is no resolution?
Just, open new issue. Thank you
I am also experiencing this issue. I just tried to open VS Code in WSL on a train and couldn't get any work done because I couldn't download the new version.
It feels ridiculous that the way VS Code is designed prevents me from performing entirely local tasks when offline.
Please look into this issue. I'm living in a country with hours of daily blackouts, and there is virtually no internet during blackouts. This issue is incredibly frustrating and it happens quite often.
In my opinion a good solution would be giving the user a checkbox in settings to check that says "force download of new remote server on WSL (or "the following wsl distributions") with VSCode update" or sth. like that. I would find that beneficial anyway since it would possibly also reduce the time i wait for VSCode on WSL to start when i actually need it.
+1 on this issue. My WSL is isolated from the rest of our network by IT policy so I simply cannot use VSCode in WSL because of this :(
I'm not sure if this is a fix, but this stackexchange post which set update.mode to none makes you skip the update when you run code.
And so, vscode obviously falls into disrepair if the Internet is missing somewhere, great!
