![\"settings\"](\"https:\/\/sysprogs.com\/w\/wp-content\/uploads\/2017\/07\/settings.png\")
<\/a>In order to use Team Settings, you will need to share a directory (via Windows Shared Folders) and tell VisualGDB to store the settings there:![\"shared\"](\"https:\/\/sysprogs.com\/w\/wp-content\/uploads\/2017\/07\/shared.png\")
<\/a><\/p>\nVisualGDB will rely on the Windows file permissions to manage read\/write access to the shared settings and will automatically prevent two users from editing the shared settings at once. Once the\u00a0directory is specified, VisualGDB will let you choose\u00a0the precise settings to share. I will give you an overview of each type of shared settings below.<\/p>\n
Remote Hosts<\/h2>\n
If you are using remote Linux machines to build\/debug your projects, you can share the corresponding connection entries: Once an entry is shared, it will automatically appear in the remote computer lists\u00a0on all of the computers using the same shared settings location. All options\u00a0(like proxy server and file transfer mode) will be\u00a0automatically transferred as if they were manually entered on each computer.\u00a0For each connection you can choose to share the password, or let the users\u00a0re-enter it (private keys won’t be automatically shared and would require entering a password to reconfigure the key).<\/p>\n If you periodically change the physical machines beyond some common roles (like the primary build machine), host aliases<\/a>\u00a0let you\u00a0do the change in one place only, instead of modifying all of the related projects. Sharing host aliases makes it even simpler: change the\u00a0alias target on any machine with write access to the shared settings and the new value will be immediately propagated to all of your development machines: Another type of setting that could be\u00a0easily shared is the per-host settings (e.g. default\u00a0temporary directory) and remote toolchains: If you are using\u00a0any of the cross-toolchains or BSPs shipped with VisualGDB,\u00a0you\u00a0don’t need to install them manually on each machine anymore. Simply check the specific versions you want installed on each of your development machines and VisualGDB will\u00a0do it for you: Similarly once you decide to move on from an older version of a toolchain\/BSP, uncheck it and VisualGDB will remove it on each\u00a0machine where it was auto-installed via Team Settings.<\/p>\n Quick Debug<\/a>\u00a0allows easily debugging programs without creating Visual Studio projects for them. It could be useful for occasional debugging of small tools built via\u00a0build scripts, or\u00a0to debug code built with domain-specific IDEs. With Team Settings you can simply share any of your\u00a0Quick Debug presets with other team members and they will\u00a0be immediately able to start using them: Note that once a Quick Debug preset is shared, it cannot be edited\u00a0and can only be saved under a different name.<\/p>\n If you are relying on custom project templates<\/a>, you can make project\u00a0creation one step easier by sharing the default template directory setting with other team members. Once the directory setting shared, every development machine will use\u00a0the specified directory to look for project templates: Team settings are stored in an XML file in the\u00a0shared settings directory. VisualGDB will\u00a0do background checks (usually once every minute) and if the file was changed, it will automatically resynchronize the settings in the background (VisualGDB keeps a local copy of all shared settings, so losing the connection to the shared directory won’t break your projects). You can also synchronize the settings manually by running VisualGDB.exe \/teamsync:<\/strong><\/p>\n Lastly, if you are deploying\u00a0VisualGDB to many machines at once, you can configure team settings via command line. Simply run VisualGDB.exe \/teamsync:<network folder with team settings><\/strong> and it will automatically\u00a0import all the settings and remember the directory, so further changes will be synchronized automatically.<\/p>\n You can download VisualGDB 5.3 Preview 4\u00a0here<\/a>. As always, we will be excited to hear your feedback, so don\u2019t hesitate to reach out to us via our support page<\/a>\u00a0 or forum<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Since we released the first version of VisualGDB, it has evolved from a basic debugging plugin to a comprehensive\u00a0extension that helps\u00a0manage numerous toolchains, packages, build machines, project templates and more. VisualGDB offers\u00a0GUI for managing those artifacts on the developer machines, however setting up a new development machine\u00a0from scratch could be annoying\u00a0due to necessity to setup … Continue reading Introducing the new Team Settings Engine<\/span> <\/a><\/p>\nHost Aliases<\/h2>\n
<\/a><\/p>\nHost Settings<\/h2>\n
<\/a>E.g. if\u00a0your Linux machine contains a yocto-based toolchain that needs to be\u00a0manually located when creating a project, you can share it via Team Settings and it will automatically appear on all development\u00a0machines\u00a0in your team. Note that the toolchains and common settings like temporary directory are\u00a0specific to\u00a0each remote host, not a host\/user combination. So you can share those even if\u00a0your team members use different Linux user accounts that are not shared via the Team Settings.<\/p>\nPackages<\/h2>\n
\n<\/a><\/p>\nQuick Debug<\/h2>\n
<\/a><\/p>\nCommon Settings<\/h2>\n
<\/a><\/p>\nSynchronizing Settings<\/h2>\n
<\/a><\/p>\nGive\u00a0It a Try<\/h2>\n