GitHub code editor (github.dev) on Microsoft Edge browser says the error request initialize failed with message: Webassembly is not defined and also missing syntax highlighting while opening a file (e.g. a simple .cs file)
All you need to do to fix that is to go to the edge settings > privacy, search, and services > scroll down to reach option Enhance your security on the web, and just turn it off (note that you must completely turn it off, not setting it on Balanced or strict.)
or you can create exception:
after that refresh the github and see it working...
hope this saves you time.
As of now (2022.5), the above exceptions list no longer works. Disabling Enhanced Security feature is never an option for me.
Users should add the following sites to exceptions. Mind the [*.] wildcard, it's mandatory.
github.dev
[*.]vscode-webview.net
If you are using vscode.dev, you should add it either
vscode.dev
If you are using VSCode Web insider builds (click Switch to Insider Versions... on bottom-left ), add the following domain.
[*.]vscode-cdn.net
adding github.com is not necessary, the actual workers are not running from this domain.
Update:
Currently (07/2022) the following works for me:
github.dev
[*.]vscode-cdn.net
Related
In VS Code 1.57, I see this on the left of my status bar:
What is Restricted mode and how I can I remove this from my status bar?
How to disable the "Trust" feature
This will disable all prompts and trust mode features, making vscode behave exactly like it did before this feature was added.
GUI (ctrl ,)
Search for "Trust" in the settings menu and uncheck: security.workspace.trust.enabled
settings.json
add the following line: "security.workspace.trust.enabled": false
What is Restricted Mode?
At first glance, this new "Restricted Mode" seems unnecessary and obtrusive.
I believe its purpose is to prevent execution of untrusted code - e.g. as a result of an extension or using the "debug" option on an untrusted file. It seems to work in a similar manner to the restricted mode on MS Office apps, like MS Word, which restricts editing, saving and printing files until manually enabled.
From the Visual Studio Code documentation on Workspace Trust:
Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features: tasks, debugging, workspace settings, and extensions.
Personally, I have never come up against a situation where this would have been a problem and it seems like a constant nuisance for the sake of the one occasion it could be useful. That said, I imagine some people work with potentially dodgy files more often.
What can I do about it?
There are four new settings that allow us to customise this feature:
If you wanted to remove the feature, you can just switch off Trust, which "Controls whether or not workspace trust is enabled within VS Code". I have tried this and it does seem to completely disable this new feature - even removing related options from the command palette.
You can also control how VS Code works when opening an empty environment and how VS Code behaves with regards to untrusted files.
If you keep "Trust" enabled, you can also configure folders that you consider "safe" - for example your usual workspace, vs. your downloads folder.
Follow these steps to configure your trusted folders:
Hit CTRL+SHIFT+P (or your local equivalent) to open the Command Palette.
Start typing Workspaces: Manage Workspace Trust and select the entry when it comes up.
Alternatively, click the cog and select "Manage Workplace Trust", as it seems there is a new entry for it there.
You will be presented with the following form, showing the option to trust/untrust the current window and an option at the bottom-left to configure trusted folders:
Select the "Add Folder" button at the bottom and add folders that you trust.
Where can I find more information?
The release notes for VS Code v1.57 can be found on GitHub. There is also a specific page dedicated to workspace trust on code.visualstudio.com.
Another new option, from VSCode 1.58 (June 2021)
Workspace Trust Banner Setting
Speaking of settings to configure the Workspace Trust feature, you'll notice a new setting to configure when the banner appears to notify indicate the current window is in restricted mode.
Like the security.workspace.trust.startupPrompt setting, the new security.workspace.trust.banner allows you to completely disable the banner after you've become familiar with the Workspace Trust feature and don't need any indication of which of your windows are in restricted mode.
By default, this banner shows once per workspace and remains until it is dismmissed.
Note: the new (July 2021) article "Workspace Trust" by Chris Dias details that "Trust" concept.
We specifically ask if you trust the authors of this workspace because VS Code can't tell if the code is malicious or not (hey, we just know 1's and 0's), where it came from, if you intend to contribute to the project, etc.
You, on the other hand, are smart and you know where the code came from: you (ok), your company (probably ok), your buddy Kai (depends), or some random person on the internet (definitely not).
That knowledge helps make the tool smarter. If you trust the author, great! The tools and extensions have the green light to do their thing and provide a magical experience, and we're not going to bug you again.
If you don't, you are telling us be careful VS Code, don't execute any code. This is what we call Restricted Mode, where potentially harmful functionality is disabled so you can more safely browse the code and eventually make an informed decision.
Note:
From our own dogfooding as well as through interviews with other developers, we found that people generally have a primary folder where they put all their sources and consider it trustworthy.
We therefore added the ability to trust the parent folder directly from the dialog.
You can trust it and all the sub folders with one click and then you won't see the trust prompt again.
Restricted Mode
When prompted by the Workspace Trust dialog, if you choose No, I don't trust the authors, VS Code will go into Restricted Mode to prevent code execution. The workbench will display a banner at the top with links to Manage your folder via the Workspace Trust editor and Learn More about Workspace Trust.
You will also see a Restricted Mode badge in the Status bar.
Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features tasks, debugging, workspace settings, and extensions.
To see the full list of features disabled in Restricted Mode, you can open the Workspace Trust editor via the Manage link in the banner, or by clicking the Restricted Mode badge in the Status bar.
More Information
Restricted mode means that you are currently working in an untrusted workspace ('restricted mode'). In 'restricted mode', some editor features (debugging, tasks, some extensions) are disabled to keep you safe when dealing with a project from an unknown source.
To disable the Restricted mode status bar entry:
Right click in the status bar
Uncheck the workspace trust entry
Note that this only hides the status bar entry, it does not change the trusted state of the workspace. This answer covers more details on workspace trust, how to trust a workspace (which also removes the status bar entry), and how to disable workspace trust entirely if needed
Even after disabling the Restricted Mode status bar entry, you can always trust the workspace with the Workspace: Manage Workspace Trust command
I am using Visual Studio 2019 v16.8.5 and have a single Blazor WASM PWA project in my solution that I recently upgraded to .NET5. In between I got it to run, but lately I cannot get to start it anymore.
The screen says Loading... and that's it.
The console output (Firefox) shows the following error: Microsoft.JSInterop.JSException: Could not find any element matching selector 'app'.
At some point this was running without this issue, but even reverting the solution to an earlier state does not bring any change and I still get a blank screen.
I found a github source saying "just remove builder.RootComponents.Add<App>("app"); from Program Main". If I do this, the error disappears and I just get a blank page saying Loading... with no errors in Console output.
Additional information: I now do a full cache cleanup (cookies and website files) after running the project in Visual Studio to prevent any caching issues.
What am I doing wrong that I can't see any of my pages?
Even after explicitely calling them like https://192.168.188.31:5555/login?
Depending on the template version used to create the initial app, a slightly different HTML is used inside the index.html.
Older version could look like
<app>Loading...</app>
while newer should like
<div id="app">Loading...</div>
In case, the first is still true, the corresponding declaration should be
builder.RootComponents.Add<App>("app");
For the second the line should be
builder.RootComponents.Add<App>("#app");
The second uses the id selector #.
Usually, the index.html is seen as a "static" file and is cached by the browser. So changes, you have done in that file are not reflected immediately. The easiest way to disable the cache is to open the developer tools, go to the Network tab and disable the cache.
I have a test case reporting scheme delivered in HTML that is complex in its own right and not easily ported to a VSCode extension. I would like to launch a Debug Configuration for each failing test case from the browser displaying the report. I have already been able to modify the report and have added a copy/paste widget for each test case's associated command. However I would like to do something to the effect of:
Launch a service as a VSCode extension that can handle requests
Formulate those requests in a way that can dynamically create launch configurations
It may be that I am stuck writing a Debug Adapter without the bells and whistles of interacting with the report.
That being said, if this is a solved problem or has a framework for solving with VSCode (and I realize remote execution could be a Very Bad Thing for VSCode to allow), I have not been able to find it through an existing extension.
I welcome your ideas.
This is perhaps not as open ended as it sounds...my question ultimately is: can VSCode operate as a service to be requested by web interfaces? Even if it could be done via Localhost this would be a boon. If it can be done over ssh with authentication, that would also be a bonus.
One way of getting VSCode to handle requests would be by invoking a vscode:// URI. This requires your extension to implement a URI handler. After the mandatory parts of the URI, you could have arbitrary data with whatever information you need.
Something that might or might not be an issue for your use case is that invoking such a URI triggers a popup in VSCode / doesn't work silently:
For dynamically creating launch configurations, you can use the vscode.debug.startDebugging() API.
I'm completely new to source/version control and I recently decided to try out the Visual Studio online service (the renamed TFS online service). I ran into a problem and now I'm not sure if I'm doing something wrong or is the VSOnline service faulty.
Problem is as follows:
Completely working Windows phone 8 project. Compiler and debugger working as expected in VS13 ultimate (also in VS12 pro).
However, when I add the project to source control and check it in. Then check it back out it breaks.
Symptoms:
1) XAML markup not recognized. IntelliSense reports error for every single XAML tag, even fundamental tags like Phone:PhoneApplicationPage. These errors can be cleared if I change from debug to release mode, but they re-appear when I launch project next time.
2) Debug target not changeable. In the dialog where you can typically choose between device and different emulator modes there is only one option "start". Impossible to deploy app on actual device. "Start" always launches default emulator (which works fine, no bugs there), but you can't choose which emulator.
3) VS13 crashes when I try to open debug tab in project properties/settings.
4) Attempt to build the solution in VSonline fails.
I realize there is a possibility I'm doing something wrong. Never used source control before, but in my understanding I still should be able to handle the project completely normal after check-out. Restrictions to debugging or deploying to device would seem counter-productive to me.
And also the false errors and VS13 crashing in settings implies there is something broken.
Any opinion, advice or help will be hugely appreciated.
After few days of relentless effort I was able to solve the problem.
As I work from home and my own computer, I'm always logged in with my personal account.
And I was logged in visual studio with my work account which has the MSDN subscription.
This caused account clash and all the odd behavior. Logging out from all browser didn't help, it mysteriously kept my personal account always logged in. And I believe this is caused by Skydrive.
So I set up new user account for my work id, log in using that and all started working perfectly.
Bottom line: If you wish to use visual studio online or log in in VS, make sure you are logged in with same account on the computer.
I'm using Google Chrome Developers tool and console while developing and debugging my web applications.
I've some Chrome plugins/extensions installed. These plugins/extensions add extra markups and scripts in the pages while rendering them in the browser, and when I view my codes in the developers tool, makes it a lot messy.
I want a clean way to view my codes without those extra markups.
So is there a way to toggle (disable/enable) the plugins quickly, or in the best way, to disable them in a particular tab? I've several plugins/extensions installed and I don't think it's a good idea to disable and then re-enable them manually.
Besides, I may want to use a plugin/extension while I'm browsing other websites on other tabs simultaneously.
There's no mechanism to disable an extension for a specific tab, or specific host. You could hack something together via the management API that would disable extensions when you hit a specific URL, but that disabled state would be global, not local.
Extensions don't, however, run in Incognito mode (unless you explicitly whitelist them via a checkbox at chrome://extensions): that might be a decent workaround for you. Load your in-development site in Incognito, work with it there in a clean environment, and pop back into your regular window for normal browsing.
You could, of course, accomplish the same thing by setting up a specific profile for development in which you simply didn't install extensions.
These are workarounds, of course. You should feel free to file a feature request for more granular user-side control over when extensions are loaded: http://new.crbug.com/
Would running 2 separate instances of Chrome be of help for you?
(You can start 2 unrelated Chrome browser instances from a command line specifying different user directories: chrome --user-data-dir=userdata1 & chrome --user-data-dir=userdata2 )
I haven't tried it for your usecase, but it sounds reasonable.