An expected output of a certain extension stopped occurring, so I want to figure out if there is some interference. I used the Reload With Extensions Disabled command to try running the extension in isolation, but apparently I am unable to enable any extensions whatsoever in this mode, which kinda makes sense, but is unintuitive.
How can I achieve the desired effect - running extension(s) with all other extensions disabled?
Note: To use Profiles you must currently have the setting Workbench > Experimental > Settings Profiles: Enabled checked (I believe in vscode v1.75 they will be enabled by default, or st least the experimental designation will be removed).
Create a temporary profile: Gear icon/Profiles/Create.../Create a Temporary Profile.
That will reload with all extensions disabled, but you can then quickly install the one particular extension you want to test into that temporary profile.
Then when you are done you can go back to your Default profile the same way (with all your previous extensions enabled) and the temporary profile will be deleted.
Related
I'm writing an app for macOS (12.1 locally) in Xcode 13.2.1. I need screenshot access, and it seems like the easiest way to get permission for that (in macOS 11 and later) is to use CGRequestScreenCaptureAccess, and to check eligibility using CGPreflightScreenCaptureAccess:
https://stackoverflow.com/a/65423834/444912
My code essentially looks like this:
let hasScreenAccess = CGPreflightScreenCaptureAccess();
if (!hasScreenAccess) {
CGRequestScreenCaptureAccess()
}
When I run a fresh build, a modal appears as expected:
and I'm able to see my app appear in System Preferences, also as expected:
Enabling my app's permissions prompts me to quit my app and restart it. This restarts my production copy of my app, from the app store. However, if I quit that and re-run the same build in XCode, my build is still not granted permission to record the screen (even though it appears as enabled in System Preferences). How do I allow my app to have permissions to record my screen locally?
We had a similar issue after renaming one of our apps which made use of the /usr/sbin/screencapture command line tool. The security prompt appeared every time a screen capture was triggered, no matter the activation status in System Preferences.
During development, the tccutil reset ScreenCapture {bundle identifier} command helped keep the permissions clean for subsequent testing.
I solved this in the process of writing this question, so I figured I'd share my answer. If I delete the copy of my app from my Applications folder, things seem to work. I assume that there is some sort of "claiming" process that goes.
It seems to work if I rename the copy of the app in my Applications folder, delete the screen recording in System Preferences, and then run my fresh build from Xcode.
In System Preferences, it can be the production copy of your app. You may need to replace it with your debug build app.
Delete it from System Preferences.
Locate your debug build app in Finder and drag & drop it to System Preferences.
Your debug build app must be given the permission.
I just upgraded to VS Code 1.57 and now many of my extensions aren't working! It seems like they are not even enabled. I tried restarting but it didn't fix the issue
What is going on and how can I fix this? They were working fine with VS Code 1.56
While there are many, many reasons why an extension may not be working, with VS Code 1.57 one big new reason you be running into is workspace trust.
Workspace trust tries to keep you safe when simply browsing through code, even if that code came from an untrustworthy source. As extensions may load and execute content from the current workspace, in VS Code 1.57 extensions the run code are disabled by default in 'Restricted mode' (untrusted workspace)
Checking if an extension is disabled due to workspace trust
If you are in restricted mode, you should see Restricted mode in the status bar:
To check if one of your installed extension is disabled because you are in 'restricted mode':
Open the extensions view
Search #installed and find the extension you are interested in
Extensions that are disabled due to workspace trust will be faded out and have a little shield next to them:
Enabling all extensions
To enable all of your extensions again, trust the current workspace by running the Workspace: Manage Workspace Trust command and then trusting the current workspace
Selectively enabling extensions
You can also selectively enable individual extensions in 'restricted mode' with the Extensions: Support Untrusted Workspaces setting
You need to edit this setting in the JSON editor. The setting value is an object that uses extension ids as keys:
"extensions.supportUntrustedWorkspaces": {
"ms-azuretools.vscode-docker": {
"supported": true,
// Omit the version if you want the extension to
// be enabled for every version
"version": "1.13.0"
},
}
Over time, many extensions should be updated to support the concept of workspace trust. This means that the extension can choose if they are enabled or disabled in 'restricted mode'. Some extensions may also enable themselves in 'restricted mode' but limit potentially dangerous functionality
Note that simple extensions, such as themes and grammars, are always enabled, even in 'restricted mode'.
We have an installer with a separately selectable auto-update feature.
Normally, if a customer wants to switch that feature on or off after the installation has completed, we tell them to re-run the installer and correct the setting. (Tested, works.)
Now a customer has a problem: Their corporate IT prepared an installation package that (mistakenly) has auto-update installed, and said IT refuses to put out a corrected installation package.
So the question is:
Can I give the customer a reasonably future-safe way to disable auto-update - say, by modifying a registry entry - without having to re-run the installer?
On Windows, the registry key
HKEY_CURRENT_USER\SOFTWARE\ej-technologies\install4j\installations
contains values with the names updateSchedule<application id>. If you locate the one for your installer, you can change the value data to "never".
In my current environment VsCode is being deployed to users through SCCM so they have the ability to install the app without admin rights. The current installation supports switches such as /Silent etc, but doesn't seem to have any other switches that would define auto updates to be off by default when the app is installed. The reason for this as I'm sure you're all aware VSCode will prompt the user letting them know there's an update avaliable. Done some digging already and as detailed, you can change the settings.Json file to disable the updates, which would be great if this was a 'system wide' i.e (C:\Program Files\Microsoft VS Code) settings file, but as detailed Here it points to %appdata% (User settings).
So, in theory you could query the user on the install and then just do some powershelly magic to chuck the required json data into that settings file and the user would be away and wouldn't have to manually turn off auto updates However SCCM installations install as an elevated account (system) not as the individual user running them so it doesn't appear feasible to manage it that way.
So fundamentally if there was a way/switch that would allow the auto update feature to be disabled on install or as a post install step I'd be very grateful for any clues on how to achieve this.
Thanks!
To achieve this with SCCM you can do the following (I will describe this for a package\program it is however also possible to achieve with an application, the options are pretty similar there):
Create a installer program the same way you would if you did not want to deploy settings (something like VSCodeSetup.exe /VERYSILENT /MERGETASKS=!runcode as your commandline and in the programs "Environment" tab select "Run with administrative rights")
Create a second program that copies (or creates) a settings file in the way you want it to %appdata%
In this second programs options in "Environment" set "Program can run:" to "Only when a user is logged on" and "Run mode" to "Run with user's rights"
On the "Advanced" tab set "When this program is assigned to a computer:" to "Run once for every user who logs on"
Deploy both programs to your collection
With this setup SCCM basically does what you want split into two different setups for the respective rights needed. There will be short times where the program is installed and the settings are not yet applied (can be shortened by setting "Run another program first:" in your config setup to the base setup but this makes things a little more complex and still if a new user logs in some time during a windows update job there will be delay until the settings are deployed) but the only way to guarantee that there is never a time where the settings are not applied is by replacing the default program start with a script that sets your options.
The settings JSON (likely the one which is being deployed with SCCM) just needs this entry:
"update.mode": "none"
While by default it has the auto-update channel enabled:
"update.mode": "default"
A post-install script could do that - but while it's located in %appdata%, the user still can change it.
I apologize if this is not the right place to ask such question, but I'm at my wit's end since Embarcadero's forum won't allow me to post any question there.
I have enabled the "Deploy" feature in the C++ Builder IDE, to test out about the depending dll & bpl files of my application, when I'm done, I found myself trapped in an annoying state - I can't perform any debugging without connected to a remote pc (with their PAServer)! This is causing a HUGE problem for me as I will not be able to debug my application if I'm away from the office, i.e. I'm on a field service at my client's place or at home.
I tried deleting the deployment profile, but it just get recreated every-time I compile my project and there is a DEPLOY command upon running compiling and running the source code. I have to wait until the connection attempt to the remote pc time-out to continue testing the application by manually clicking the .exe of my application.
Is there any way to turn off the "Deploy" feature so that I can do debugging on my local machine just as before activating the "Deploy" feature?
I've found out where the profile was hiding and deleted it, now I can debug as usual.
In the Rad Studio help:
ms-help://embarcadero.rs_xe5/rad/Connection_Profile_Manager.html
On occasion, I have this same problem with DelphiXE5 (where the problem is that I forget how to get back to the default environment without losing my remote settings.)
Remote Deploy active:
The Revert option for the normal build/debug environment:
And finally, the previous Remote Deploy settings available via the same Target Platform context menu (i.e., Properties):
The Default Connection isn't something to be setup. To the contrary, it's really not a connection at all. The Revert... menu item essentially means Revert to local build & debug.