I have a Project Group in Visual Studio 6 (.vbg). The projects are under source control (TFS). When I start debugging Visual studio there is an error Path/file access error: Path/name.vbg and dialog for "Save Project Group As" follows when canceled debugging runs without problems. To circumvent this annoyance I need to have the group file checked out or mark as readable just by file attribute. Is there a way how to avoid this behavior?
Notes: Situation was the same when Visual Source Safe was used. By my observation .vbg is not changed when the change is allowed. The problem can be connected with using English Windows with non English regional settings.
No. Just keep the VBG in version control, and make the files read-write in your local directory.
The easiest solution would be for you to save your VBG files to a folder outside of source control. It won't make a difference to the running directory - that is based on the EXE project (if any).
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?
I'm sorry to bother , I don't know if I can ask this
Visual Studio Code, suddenly can't use debug mode to set interrupts to test.
It seems that it is talking about the folder name problem, but after accessing the folder, it will not be renamed. How can I solve it now? I can't upload photos so I'm capturing the important parts.
i.e.: the module "queue" could not be imported because it is shadowed by:
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/queue/__init__.pyc
Please rename this file/folder so that the original module from the standard library can be imported.
Not sure how to change folder name or duplicate name, these actions are forbidden after accessing the folder, or is this some other problem?
This looks like an actual issue in VSCode - https://github.com/microsoft/debugpy/issues/886
In case you're using python 2.7, Downgrading the python VSCode extension should help.
I'm programming a client side applications using SharePoint Designer 2013.
I want to change to VSCODE since it supports a lot of extensions for some Javascript library like angular, jQuery. And because of the Chrome/Node.js debugger extension.
But when I try to start any Debugger, I got the error:
Unable to create 'launch.json' file inside the '.vscode' folder (Error: UNKNOWN: unknown error, mkdir '\\servername\DavWWWRoot\sitename\Style Library\.vscode').
I get this error because it's impossible to create a folder in SharePoint where the name starts with dot.
So there's a possibility to change the name of this folder or the file location to any directory in my local computer?
No, it's not possible to move/rename that folder. VS code is a tool that bases project management on folder content. So it is essential that the project settings reside in the folder being managed.
You can move the "extensions" folder, but unfortunately not the argv.json (so the ".vscode" will, at least be recreated on vscode launch)
https://github.com/microsoft/vscode/issues/17691#issuecomment-559234574
I hope that'll finally change sometime .
https://github.com/microsoft/vscode/issues/3884
https://github.com/OmniSharp/omnisharp-roslyn/issues/953
My team is taking over a project from a previous team. We use a different TFS server than the original team, and we are also not interested in keeping the history of the project because we are accepting the latest version of the code as the beginning of our history with the project. Branching is not an option since we want to start our history from the current version of the code. We just want a fresh project with the existing code.
I have not been able to create the new project from the old code successfully. I keep getting an error: "Source control cannot add the solution: Solution would span multiple workspaces"
My process for attempting the new project creation:
Create a workspace for the previous team's version of the code.
Get latest version of that code into local mapped workspace directory
Open the solution.
Unbind all projects and solution.
Close solution.
Create a workspace for the new version of the code on our TFS server.
Copy the unbound code on my local box to the new local workspace mapped folder.
Open the solution from the new directory.
"Add to source control" from the new solution.
Then I get the error. I have tried removing the TFS security files out of the code directories in the unbound version and tried changing source control instead of adding to source control (but it just binds back to the original instead of letting me bind to the new).
Is there any other way to do this besides recreating the solution/projects and adding back all the files and references? It doesn't seem like it should be this difficult...
Any advice much appreciated!
Your way should work...there's probably some minor discrepancy in your steps or your initial state that I'm misinterpreting. Rather than debug to death, let's abandon what you've got so far and do this instead:
Fetch the previous team's code onto your machine somehow. Preferably just a straight robocopy from a colleague or the old build server; no TFS connections. If you do have any workspaces associated with the old TFS, delete them now.
Unplug from the network, or otherwise ensure the old TFS is not reachable.
Open the solution.
You'll be prompted: "work offline" or "permanently remove bindings"? Choose the latter.
File -> Save All.
Reconnect to the network.
Create a workspace that maps a superset of the code dirs to some path on the new TFS.
Solution Explorer -> rightclick root node -> "Add to source control."
Per the rules I describe on my blog, step 8 should succeed w/o user intervention (no "browse for folder" dialog, no error popups).
Note: steps 2-4 assume you have VS 2008. If you have 2005 you'll have to manually poke around in the Bind dialog.
We're using TFS and we're having problems when we switch branches, it's throwing up problems with the TFS bindings every single time.
We still have
.vspcc files
.vsscc files
which is I'm guessing where it stores the bindings, does anyone have any advice on how to easily switch between branches in TFS without pain?
These files are used to store files that are excluded from source control - and yes, they are themselves under source control. I've never had to worry about these before, so I don't think that's where the problem is.
Bindings are normally stored in your actual proj and sln files.
If you have problems with binding, you actually have some problem with your workspace. Either make a new workspace in a new local folder, and get everything from the server there from scratch (i.e. setting up the workspace mapping through visual studio, opening your solution via the source explorer etc. Don't use any clever tricks here - otherwise strange things happen), or try going to File -> Source Control -> Change Source Control, unbinding all projects and rebinding them. VS will blindly write the binding info anew into your project and sln files if you do this.
Especially make sure that all server paths you're checking out can be mapped to a local path.
Switching between branches is just done by opening the appropriate solution file from the appropriate folder/branch. It's not normal that this gives you problems, obviously.