is it possible to have a project / a workspace in vscode that includes a extension?
I want to have a language extension as part of my project workspace so I need only one repository to sync.
I know there is something like a recommended extension settings, but it's not a public available extension.
I'm working on a project for which I have created a custom language extension for my own script language. I don't want to make a public release for the language as I only use it for my private projects.
VS Code seems to install the extensions in the folder %userprofile%.vscode\extensions\
Is it possible to pull the extension into the project / workspace without relaying on files in the default extensions folder?
We've updated to Visual Studio 2017 and switched to Team Services (VSTS) as our source control. I've migrated a few old projects and am using the Microsoft Installer Project extension to provide compatibility for the original setup projects.
However, there seems to be a potential issue with source control when working with the setup projects. Attempting to make any change results in the error:
The command you are attempting cannot be completed because the file 'Setup[Productname].vdproj' is under source code control and is not checked out.
Modifying files of other projects within the solution work correctly and trigger checkout from the repository.
I have not been able to determine a way to properly check out the setup project and work with it under the new source control. I'm unsure if it's a bug with the extension or if it simply lacks support for VSTS.
Has anyone successfully been able to work with setup projects (.vdproj) in conjunction with VSTS? If not, is there a workaround?
Edit:
Image of context menu:
You can apply the following workaround, since it seems to be a bug in the installer extension:
Choose 'Open file in File explorer' in your context menu
Open the project file in your favorite texteditor
Make a dummy change (adding a space character in an empty spot is enough)
Visual studio will prompt to reload the project and has explicity checked out the project file.
see also here
I submit a feedback here: The command you are attempting cannot be completed because the file 'Setup[Productname].vdproj' is under source code control and is not checked out
The workaround is that you can check out the project manually. (Right click the installer project > Check out for edit)
I often like to use VSCode to quick view some projects to pull snippets from them. However, this leads to a ton of additional .vscode folders being placed on my drive in any folder I use the right-click -> Open with VSCode option.
Is there a way to disable this folder from being created every time vscode loads somewhere new?
This issue was due to the 'C/C++ for Visual Studio Code' extension being outdated.
Upgrading to the latest version of this extension has fixed the problem.
That is not the standard behaviour of VSCode, normally the .vscode only gets generated once there is something like a launch.json put into it. Mind checking what's actually in there?
We want to share an eclipse Qt project via an SVN repository.
Of course we need to share the .pro file of Qt to be able to build the project.
The problem is, that without the project files you can not handle the project in eclipse but we cannot use the same as they contain local references.
Also it would be nice to use the Eclipse SVN plugin to manage this.
I already tried to check out the project and create a Qt project on Checkout but this overwrites the checked-out project file.
Any suggestion would be appreciated.
These are some lines from the .cproject file that are autogenerated, so I can not change the absolute paths:
<storageModule moduleId="org.eclipse.cdt.core.pathentry">
<pathentry base-path="/usr/include/qt4" include="" kind="inc" path="" system="true"/>
<pathentry base-path="/usr/include/qt4" include="QtWebKit" kind="inc" path="" system="true"/>
...
There are 2 rules for Subversion (independent of Eclipse, should be the same all the time):
If the tool will regenerate a file, and you don't have to change it:
==> don't check it in your version management (may it Subversion, Git, CVS, ...).
If the file contains parts that are manually changed by a user
==> it should be checked into version management.
If you have the second case (not clear from your question), you should try to change the paths to be relative, so that others could use your project at the same location.
If you cannot change that, stick to the location in the file system. Every developer has to use an identical setup.
If you have to support different operating systems, and the files generated by the tooling are not compliant (shame on the tool makers), you should hold templates for all operating systems in your version management, and should initially (manually) make a copy, depending on the operating system you are working in.
If you have to change that file for some purpose, you have to change the templates as well and should remember that all developers have to make a new copy after that.
Sorry, I don't know Qt and have never developed in a C-environment on different platforms, so my tips are pretty vague.
Finally I found following solution:
No .cproject .project file in SVN!
Import the code files from SVN (also the .pro file for Qt)
Eclipse will ask you to create a project, so create a Qt Project with the same name (or some else, but you will then have to delete the files)
When the project was created, revert it (right MB on the Project in Project Explorer -> Team -> Revert) to the state of the repo checkout
Done, now you can work with the project
We normally use Eclipse for a particular Java project, but recently I imported the project into NetBeans to use its dialog building features.
Since I'll probably come back to this, I wanted to store the NetBeans project files into version control. However, I don't want to commit files that are "mine" versus "project", i.e., files with my own settings that would conflict with another user's.
NetBeans created the following structure in the top-level project area:
nbbuild
nb-build.xml
nbproject
<various files>
configs
private
Clearly nbbuild is build output, so that won't go in. The nb-build.xml file seems likely, as does most of nbproject. However, nbproject/private suggests it's "mine". Peeking at "configs", it's not clear to me if that's mine or project...
Anyone have some guidelines?
The NetBeans knowledge base article on project files & version control discusses the NetBeans project files, with loose advice about which files are project specific (i.e. can be shared via version control), and which are user specific.
Here is the section on version control:
If the project is checked out of a version control system, the build (or nbbuild), dist (or nbdist), and the nbproject/private folders should not be checked into that version control system.
If the project is under the CVS, Subversion, or Mercurial version control systems, the appropriate "ignore" files are created or updated for these directories when the project is imported.
Though nbproject/private should be ignored, nbproject should be checked into the version control system. nbproject contains project metadata that enables other users to open the project in NetBeans without having to import the project first.
It turns out that both Thomas & Petercardona are correct, in a way. NetBeans recommends that you only import source code and/or documentation. Oh and the nbproject folder but not the *nbproject/private** folders.
From the NetBeans Knowledge Base article on importing Eclipse projects:
Version Control Considerations
If the project is checked out of a
version control system, the build (or
nbbuild), dist (or nbdist), and the
nbproject/private folders should not be checked into that version control
system.
If the project is under the CVS,
Subversion, or Mercurial version
control systems, the appropriate
"ignore" files are created or updated
for these directories when the project
is imported.
Though nbproject/private should be
ignored, nbproject should be checked
into the version control system.
nbproject contains project metadata that enables others users to open the
project in NetBeans without having to
import the project first.
None.
Only source files, build scripts, and documentation that is not automatically generated (e.g. - the output of tools such as JavaDoc and Doxygen) should be checked into a repository. Things like project files, binaries, and generated documentation should not be checked in.
The reason is two-fold. First, you don't want to overwrite another developer's project settings with your own. Second, other developers might not be using the same IDE as you (or even an IDE at all), so don't give them any more than they need to build (the project or its associated documentation) or run the project.
As tested with Netbeans 6.8, only the project.xml, configurations.xml and the main makefile (the customisable one in the parent dir of the 'nbproject' dir, with pre/post target definitions) must be distributed via the repository. All other files will be automatically (re)generated by Netbeans (Makefile-impl.ml, Makefile-variables.ml, all the Makefile-$CONF, Package-$CONF.bash). The 'private' dir should also be ignored, obviously.
You can check also
https://github.com/github/gitignore/blob/master/Global/NetBeans.gitignore
This open source project contains
A collection of useful .gitignore templates
Toptal has a useful tool for developers wanting to find out what should go on a .gitignore file.
https://www.toptal.com/developers/gitignore
For netbeans, just search Netbeans and it should return a template something like
**/nbproject/private/
**/nbproject/Makefile-*.mk
**/nbproject/Package-*.bash build/
nbbuild/
dist/
nbdist/
.nb-gradle/
Copying and pasting this into a .ignore file on your project's directory should solve your problem.