I've got a handful of custom tasks in VS Code that I want to share across multiple projects. The tasks are currently installed in $PROJECT_DIR/.vscode/tasks.json.
Where should I put my tasks file so that it is loaded by VS Code for all projects (I'm thinking something similar to User vs Workspace settings)?
I've tried ~/.vscode/tasks.json (I'm not sure if this is a location that VS Code uses or if it's something I created ages ago) and also $HOME/Library/Application \Support/Code/User/tasks.json (this is where custom settings.json and keybindings.json etc. are stored). Neither of these locations works.
At the moment, it seems like I can only have custom tasks defined in each workspace rather than globally. I couldn't see anything in the official documentation. Any pointers welcome?
To answer the specific question about the location of the "user tasks" tasks.json file:
In Ubuntu, it's in ~/.config/Code/User/tasks.json
In Windows WSL, it's in /mnt/c/Users/<username>/AppData/Roaming/Code/User/tasks.json
[feel free to edit if you know the location in Mac or other systems]
This question is a duplicate of Create tasks in Visual Studio Code per user but I cannot mark it as such as that has not been upvoted or accepted yet. Reproduced here:
It looks like this will be in v1.42, the January 2020 release. See https://github.com/microsoft/vscode/issues/89343 (user level tasks). And https://github.com/microsoft/vscode/issues/1435.
In addition to having tasks in your .code-workspace file and in
tasks.json in your open folder, you can now have tasks in a user level
tasks.json next to your user settings.json.
Open a folder that has some tasks. The vscode project is a good
example.
Run the Open User Tasks command to create a tasks.json file next to
your user settings.json file.
Add a shell or process type task to the new tasks.json. Only those two
types of task are supported here.
Run the Run Task command and verify that you see your new user level
task. Verify that you can tell that it's a user level task in the task
quick pick. Verify that you can configure your user level task by
clicking the gear next to it in the quick pick. Verify that you can
run the user task.
It is in the Insiders' Build already so presumably v1.42.
------- From the 1.42 release notes:
User level tasks
Tasks declared in tasks.json are now supported at the User Settings
level. If you have a build script that you use across many projects,
or if you don't want your tasks in a project folder, you can add your
tasks in the user tasks.json file. You can run the Tasks: Open User
Tasks command to create user level tasks. These tasks will be
available across all folders and workspaces. Only the shell and
process task types are supported here.
Related
We're trying to maintain a single set of Visual Studio Code extensions within our organisation, managed centrally. In our ideal scenario all end users have the same extensions installed, those extensions are updated on their behalf, and they are not able to install additional extensions.
We had achieved this to date by:
Installing extensions to a directory under C:\Program Files and setting the (undocumented) VSCODE_EXTENSIONS environment variable to point to that location.
Configuring a scheduled task (run as SYSTEM) that executes a powershell script with a list of extension_ids that calls code install-extension <extension_id> on each.
This solution worked until a breaking change in v1.74 expected to be able to write a new extensions.json file to the extensions directory.
Whilst we can get around this by creating a extensions.json file in that directory, I don't want to go too far down the wrong path. Is there a preferred method for centrally managing extensions for Visual Studio Code?
The situation is, I want to share my settings of vscode.dev to others. That could include
extensions installed
tabs opened (not files, but some extension related tabs such as panels or previews)
So the person who clicked on the shared link can go to vscode.dev, but with my configurations.
Try to use Settings Sync, its the easiest way: Settings Sync
You could try to create a settings.json too, and share that file with others.
I think the only solutions you have here is to use either GitHub Codespaces (Dev Containers) or store config in repository.
Basically you will not have a link for preconfigured vscode.dev. The idea is to have all required configuration in devcontainer.json file committed it to repository. So whenever the repository is opened VSCode uses the file to configure environment.
Also you can change you settings in Workspace and right click on extensions and click "add to workspace recommendations". That will create .vscode/extensions.json, .vscode/settings.json and commit .vscode folder into repository.
TLDR: commit VSCode configuration files into repository and open repository in vscode.dev
Look into Profiles, which can be enabled in your Settings (currently experimental but will be made generally available in vscode v1.75 due out very soon.
Current setting in Stable: Workbench > Experimental > Settings Profiles: Enabled
There is no setting for Profiles in the Insiders Build, it is just enabled by default. I assume when v1.75 Stable comes out that will also be the case.
See v1.75 Release Notes: Profiles:
We are happy to announce that the Profiles feature is now generally
available in VS Code. A Profile can include extensions, settings,
keyboard shortcuts, UI state, tasks, and user snippets. You can
customize VS Code for different development scenarios like data
science, documentation writing or for multiple programming languages
like Python or Java. If you have different VS Code setups based on
workflow like Work or Demo, you could also save those as different
profiles. You can open multiple workspaces (folders) with different
profiles applied simultaneously.
{image omitted]
You can also export and import profiles to share them with your
colleagues, friends or students to help them get started with VS Code.
The following video demonstrates how to export a profile using a
GitHub gist in order to share it with someone. Users that receive the
profile link can preview the shared profile in VS Code for the Web and
import it to their local VS Code instance.
There is a nice mp4 demonstration in the link, but it appears SO would take that format.
You can export a Profile to a Github Gist so that it can be imported by someone else or to a local file you can share (or yourself to a new maching, etc.) - my demo shows all the settings, UI State and extensions it can include.
More info on Profiles at v1.69 Release Notes: Settings Profiles
I tried searching with as many different terms as I could and couldn't find exactly what I'm looking for.
I have a C++ Project developed in Visual Studio 2019 and I am trying to build and deploy it in Azure Pipelines. It uses Boost and OpenCV. I skipped trying to include these in Azure Artifacts because of a rabbit hole with Azure CLI errors that took me almost half a day.
So it seems that there is a task to publish pipeline artifacts in the .yml file. How do I do this when my project needs to reference a certain directory, instead of one specific file or .dll? Here are images for how this is configured in Visual Studio:
include directory for boost image
include directory settings for opencv image
Edit: Still trying, see my comment. Thinking about switching over to CircleCI.
I found out what to do. Hopefully no one else wastes as much time as I did.
The key was MSBuild. One needs to first find out the values of $(IncludePath) and $(LibraryPath) by doing the following first in Visual Studio:
Right-click on your project, choose "Properties"
Go to the Build Events tab, and click "Pre-Build Event"
Click on and expand the Command Line row, and click "Edit"
Now click the button that says "Macros>>"
You will see a bunch of different variables and their values. Find the values for LibraryPath and IncludePath, copy and past them into a text file.
Now, assuming you already set up a local agent, follow these steps:
Put the text file in the root folder of where your agent is installed. For me, this was "C:\agents"
Have the first line be "LibraryPath=value" and the other line be "IncludePath=value". Use double slashes for the directory paths.
Rename the file to .env. If the agent is currently running, restart it so it can read in the environment variables it will use during your build.
In the MSBuild task of your pipeline, specify arguments. For my case, it was simply this: /p:IncludePath="C:\Program Files\boost_1_77_0;$(IncludePath)" /p:LibraryPath="$(LibraryPath)"
Run the pipeline. You can check your completed build on the local machine. For me, the path it kept going to was "C:\agents_work\2\s"
Is it possible to have vscode automatically open the newest folder within a specific path?
For example, with this configuration:
{
"folders": [
{
"path": "\\\\FromABC\\Archive",
"name":"From ABC"
},
{
"path": "\\\\FromXYZ\\Archive",
"name":"From XYZ"
}
]
}
I would expect these folders in the workspace to be pointing to \07\07 because those were created today:
\\\\FromABC\\Archive\\2021\\07\\07
\\\\FromXYZ\\Archive\\2021\\07\\07
Is it possible to create a workspace where the folders are opened to the latest folder within each configured path?
There's not enough information in the original question to fully answer it, however, I can suggest a few avenues of attack
Custom Command (error-prone and picky)
Modify Upstream Process (likely the best overall)
Combining Both (perhaps the best for your immediate case)
Creating a Custom Command
Create a new command per https://code.visualstudio.com/api/extension-guides/command#creating-new-commands
VSCode Commands Listing: https://code.visualstudio.com/api/references/commands
new command
detect latest folder through whatever logic you like
call vscode.openFolder to navigate to it
call your custom command through Activation Events (activationEvents) at either onStartupFinished or * (Start Up; less-preferable, but may be required to avoid confusing the editor)
https://code.visualstudio.com/api/references/activation-events#Start-up
Check out Start app when opening project in VS Code? for a few answers related to this
Modifying the Upstream Process
Cutting the gordian knot, it's likely some process (perhaps a human) is creating the directories for you
Change the upstream process so when it creates the directories, it also creates/updates a link to the directory labeled something like latest
/FromABC/Archive/2021/06/03
/FromABC/Archive/2021/07/05
/FromABC/Archive/2021/07/07
/FromABC/Archive/latest --> /FromABC/Archive/2021/07/07
/FromXYZ/Archive/2020/04/12
/FromXYZ/Archive/2021/08/18
/FromXYZ/Archive/latest --> /FromXYZ/Archive/2021/08/18
Then you can always refer to the latest directory and it will always be correct
This is quite common when something can change frequently, but another process is expecting a static path and/or has no way to know the schedule of change
I don't have any Windows systems to try this out with and you may be able to create a regular shortcut for this .. however, you may need a Junction (soft-link) or Hard Link to convince VSCode that the directory is a real directory
https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
This also provides an opportunity to include more files, such a beta versions of some software, which it's desirable to package into the same directory structure, but not truly the latest stable!
Combining Both
If your upstream process is either not modifiable (or some manual process it's annoying or error-prone to add extras steps to) you can likely combine both solutions to get what you really want
Use the * Action Event to call a script to detect and create the new directory - create a binary or PowerShell script to make your link
In this and with the upstream change, just point VS Code to the latest directory and it shouldn't mind
Not sure on which platform you are, I assume windows, but essentially similar.
Instead of trying to get VSCode to open the latest folder, I would create a script that updates a softlink for each folder to the latest subfolder in it. Then you can point VSCode to the softlink, which can be updated whenever needed to the latest subfolders.
When I created a Node task for Visual Studio Code it created a tasks.json file inside the .settings folder for the folder that you have open (node-app in this case as shown in the image below). ie: it creates a task per folder.
{
"version": "0.1.0",
"command": "node",
"isShellCommand": true,
"args": ["${file}"]
}
My question is how do you create a task per user rather than a project based task so that I can execute the node code from any folder rather that having to create the same task for each folder you open in Visual Studio Code.
Also how do you execute individual files without opening a folder.
It looks like this will be in v1.42, the January 2020 release. See https://github.com/microsoft/vscode/issues/89343 (user level tasks). And https://github.com/microsoft/vscode/issues/1435.
In addition to having tasks in your .code-workspace file and in
tasks.json in your open folder, you can now have tasks in a user level
tasks.json next to your user settings.json.
Open a folder that has some tasks. The vscode project is a good
example.
Run the Open User Tasks command to create a tasks.json file next to
your user settings.json file.
Add a shell or process type task to the new tasks.json. Only those two
types of task are supported here.
Run the Run Task command and verify that you see your new user level
task. Verify that you can tell that it's a user level task in the task
quick pick. Verify that you can configure your user level task by
clicking the gear next to it in the quick pick. Verify that you can
run the user task.
It is in the Insiders' Build already so presumably v1.42.
------- From the 1.42 release notes:
User level tasks
Tasks declared in tasks.json are now supported at the User Settings
level. If you have a build script that you use across many projects,
or if you don't want your tasks in a project folder, you can add your
tasks in the user tasks.json file. You can run the Tasks: Open User
Tasks command to create user level tasks. These tasks will be
available across all folders and workspaces. Only the shell and
process task types are supported here.