MadCap Flare: Cannot import project from a TFS repository - tfs

I am trying to connect MadCap Flare with our TFS repository.
I have the whole project check in the TFS Server, but when I try to import the project from the "Source Control Explorer" in MadCap Flare
I get this error:
Local workspace detected - MadCap Flare only supports server
workspaces. Please contact your system administrator to help resolve
the issue.
After that, I created a server workspace through Visual Studio but I still get same error.

Try moving the project on your local disk to another folder temporarily. Then import the project via Flare to a new empty folder on your computer.

The change you need to make is actually in Visual Studio. In the workspace settings under advanced there is a setting that allows for local or server workspace. You want to make sure you are using server and public.

Related

Unable to validate collection

I am trying to set up TFS for vscode. I am getting the error, unable to validate the collection assuming 'default collection', when signing in. Any recommendations oh how to resolve this issue.
Firstly make sure you have correctly set the TFVC support.
Below is a short list of steps to get up-and-running with TFVC support:
Install the Team Services extension for Visual Studio Code.
Team Foundation Server requires your domain credentials.
Ensure you have a TF command line client installed (either TF.exe or
the TEE CLC).
Set the tfvc.location VS Code setting to the full path of your TF
command line client.
Open a folder containing a Local TFVC Workspace and sign in when
prompted.
Set the SCM Provider to TFVC.
For more detail tutorial you could also take a look at my reply in this question How can I connect to on-premises TFS using visual studio code?
Back on the error message, it may related to the workspace. Check if you have correctly mapped the workspace. Just try to remap the existing workspace or create a new workspace and map sources to a new local folder, then check that again.
Also just try to specify the collection and team project name in the user settings like this:
{
"tfvc.location": "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\tf.exe",
"team.remoteUrl": "http://server:8080/tfs/collection",
"team.teamProject": "TeamProjectName",
"tfvc.restrictWorkspace": true,
"window.zoomLevel": 2
}

How to Setup VSTS to work with VS Code over Unix (TEE-CLC)

I had been trying to setup my VS Code and plugin VS Team Services 1.22.0 (need to setup TEE-CLC). But I have been hitting the same wall.
Checks:
-Java Installl
-Download TEE-CLC
-Installed VS Team Services Plug In
-Setup "tfvc.location"
-Created a local folder in my documents
Over TEE-CLC 14.123.1 I had accepted the Eula(Easy process), created a workspace using the TEE in VSTS(with success):
tf workspace -new MyWorkspace -collection:https://dummy.visualstudio.com/
Workspace 'MyWorkspace' created.
Then the part where I get stuck is mapping my local folder.
I had try official setup process(plugging over VS Code)
Used this How do you create new windows workspace with TFS command line client that is running on unix
Follow videos to setup TEE-CLC without success.
I know I'm missing something but don't find yet what could be.
If you use on-premises TFS, you must be running Team Foundation Server 2015 Update 2 or later.
After installing Team Services extension and TEE CLC (see how to set it up by viewing this video), you also need the following steps:
Set the tfvc.location VS Code setting to the full path of your TF command line client.
Open a folder containing a Local TFVC Workspace and sign in when prompted. Refer to this site.
Set the SCM Provider to TFVC. Refer to this site for more information.
If you are unable to access the existing local workspace using TEE
CLC, try the steps below:
using the CLC, run the tf workspaces -collection:<collection-url> command, to help the CLC be aware of the workspaces in the specified
collection.
Run the tf workfold command from the local folder being accessed from Visual Studio Code.
Running both commands should make the TEE CLC aware of the workspace
and as well as verify that access to it is possible.
I'd like to suggest go through the website below:
https://github.com/Microsoft/vsts-vscode/blob/master/TFVC_README.md

Why does "tf history ." claim there is no working folder in my mapped TFS directory?

I am trying to modify my project so that on build it queries for the current TFS changeset for the local directory and uses that to form the build number (using http://florent.clairambault.fr/insert-svn-version-and-build-number-in-your-c-assemblyinfo-file as a reference).
Since we currently are not using team build or any continuous integration for this particular project at this time I plan to use:
tf history . /r /noprompt /stopafter:1 /version:W
However, when I test this command out using the visual studio command prompt in my project's directly (where I work from TFS) it claims:
There is no working folder mapping for xxxxxxxx
The folder is shown as mapped in my workspaces in Visual Studio's Source Control Explorer (shows as the local path), and when I edit my workspace.
Why is the command line utility claiming there is no working folder when it is?
You will see this error message if you are using Visual Studio 2012 (and the corresponding Team Explorer 2012 client) and you are using tf.exe from Team Explorer 2010.
TFS 2010 clients store their local workspace cache in a different location on-disk than TFS 2012 clients. Thus, if you are to create a workspace with a TFS 2012 client, the TFS 2010 client cannot see that workspace data until it has connected to the server and populated its own local client cache.
It sounds like you're okay with using the TFS 2012 version of tf.exe, so I would make sure that your PATH contains an entry to that one first, and this should resolve your problem.
If you really wanted interoperability between the two versions, you would need to make sure to connect to your TFS server from both clients in order to make sure the workspace cache was complete for both. However make sure that you are using only server workspaces in this case, as TFS 2010 cannot connect to a TFS 2012 local workspace.

TFS 2010 Windows Shell Extensions, how do I connect to a workspace?

I have VS 2010 and a TFS 2010 server set up and it's all working fine. I've checked out files to my local hard drive.
I installed the TFS Power Tools to be able to get to TFS through context menu in Windows. If I right click in a TFS project on my hard drive I get all the icons and it works.
My question is that how do I get the TFS menu if I have no source code from TFS on my hard drive?
Regards,
Magnus
"how do I get the TFS menu if I have
no source code from TFS on my hard
drive?"
First, you need to define a workspace and map server (source control) paths to local directories. You can do this in either of two ways:
Use the tf workspace command to define a new workspace.
Use Source Control Explorer to Create a Workspace and Get Files.
Once you've setup your workspace, you can right click any file or folder in your workspace you will find a Team Foundation Server option, expand it and you will see other version control options like checkout, check-in etc.

Team Build Error: The Path ... is already mapped to workspace

When creating a new build in Team Foundation Server, I get the following error when attempting to run the new build:
The path
C:\Build\ProductReleases\FullBuildv5.4.2x\Sources
is already mapped to workspace
BuildServer_23.
I am unable to see a workspace by that name in the workspaces dialog.
Use the command line utility TF - Team Foundation Version Control Tool (tf).
You can get a list of all workspaces by bringing up a Visual Studio Command Prompt then changing to your workspace folder and issuing the following commands:
C:\YourWorkspaceFolder>tf workspaces /owner:*
You should see your problem workspace in the list as well as it's owner.
You can delete the workspace with the following command:
C:\YourWorkspaceFolder>tf workspace /delete /server:BUILDSERVER WORKSPACENAME;OWNERNAME
Just delete the contents of the following folder(s):
C:\Users\UserName\AppData\Local\Microsoft\Team Foundation\3.0\Cache
Where UserName is actual or current user, and 3.0 is the version number.
I had a similar issue and to remove the workspace that was causing me a problem, I logged into another machine with TFS client installed and performed the following:
On the File menu, point to Source Control, Advanced, and then click
Workspaces....
In the Manage Workspaces dialog box, tick the Show remote packages checkbox.
Under the Name column, select the workspace that you want to remove, and then click Remove.
In
the Confirmation dialog box, click OK.
I received this error, which was caused by having two build definitions that pointed to the same source. The issue was that I used a static build directory in the Build Agent.
This forum post describes my issue and resolution exactly:
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/
We had the same problem but deleting the workspace's from the TFS server did not work.
(I should mention that I grabbed my colleagues VM that was already set up with his credentials.)
For me this worked:
http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx
I just went into the : ...\Local Settings\Application Data\ made a search for VersionControl.config, opened up the folder that contained this file and deleted all of it's contents.
Previous to that I tried manually editing the file but it continued with the same error message.
I hope this helps.
For some reason I was having trouble deleting the workspace from the command-line utility. Luckily I found Team Foundation Sidekicks 2010 (from this post) which is free and provides a GUI for viewing and deleting TFS workspaces, and many more useful TFS features.
I had a similar problem with Visual Studio 2010 complaining about an already-mapped-workspace, but instead of deleting the entire workspace, I used the following from the Visual Studio Command Prompt: "tf workspace PROBLEM_WORKSPACE_NAME". This brought up an "Edit Workspace" dialog. From there I was able to remove the path in question from the "Working Folders" list, which got rid of the error.
the rest was fairly easy.
Simply go to this folder:
C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4\Cache
and delete all that's in the folder.
I was getting an exception telling me that the file was already mapped in another workspace:
"The path {File Path} is already mapped in workspace {Workspace Name}."
This workspace was deleted beofre.
With the help of friend of mine I found out that TFS save workspace info under the user local settings dir. We found a file named:
VersionControl.config under {User Documents and Settings dir}\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache.
This file contains all the local mapping of TFS. Probably when you use the Map method and don't use:
public void DeleteMapping(WorkingFolder mapping); before deleting the workspace the mapping information is not removed from this file which is used by TFS to check if you've alreay mapped a specific path.
To resolve this problem delete all the keys from the config file. Don't delete the file because you'll get it again from the server cache.
Here is what I did (well what I do):
Using TFS Sidekicks clear out the user and server filters so they are blank. This will let you get all workspaces.
Check the build error for the workspace name. In the OPs case it is BuildServer_23. It is different in my environment but basically just match up the error name with the one in the tfs sidekick list.
Click the red x to delete the workspace.
Viola!
If applicable, you can also clone the build definition and change its name. This workded for me.
I tried all the following solutions such as :
Use sidekicks to delete WS.
Use tf commands to delete remote server workspaces.
Delete the TFS cache folder.
The following worked for me:
tf workspaces /remove:*
If you don't have permissions on the server to delete other people's workspaces, you can just change the name of the build definition. TFS will create a new workspace and map it to "C:\Build\ProductReleases\new build name here\Sources".
While trying to 'Get latest version' of a project which I had previously mapped to a local directory and then deleted, I saw this same error message.
First I tried the SideKick tool and then the Visual Studio 2010 command prompt, both of which told me I had no workspaces mapped.
Next I searched for 'VersionControl.config' within c:/users/myuser/appdata, and deleted the 4 references it found.
I re-opened Visual Studio and I was able to re-map the project, no more error!
Simplest way to do this is to go to your AppData and delete the TFS cache (depending on the version 3.0 or 4.0)
C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\3.0\Cache
or
C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4.0\Cache
TDN's solution worked for me when I was having the same issue. The Build server created workspaces under my account. Checking this box allowed me to see and delete them.
I got same issue in Visual Studio 2017 and TFS 2017. DefaultCollection must be mapped first to you local path. Somehow this step was skipped and I got only MyFirstProject mapped.
All you need to do is:
- 1. Go to your TFS web page and remove the project from the server.
- 2. Remove the project from your local "Worksapces"
- 3. Go to "Manage Connections" which will refresh your Home page in TeamExplorer.
- 4. You will get Configuration page which will allow you to setup root path to your DefaultCollection.
- 5. You should get message that it been done successfully. Now you can create your project.
It's important to map root of your collection to your workspace first and then map a new project.
My issue was related to using multiple accounts. This is how I was able to switch accounts.
Open Team Explorer
From the big drop down menu near the top of the pane...
Navigate to:
Projects and my Teams>Manage Connections
Navigate to:
Manage Connections>Connect to Team Project
Use the "Switch User" link to switch accounts.
Now the workspace names will match the chosen account.
I couldn't get any other solution to work.
I had a new account created and the old account no longer had permissions (both on same machine).
I tried:
1) Deleting the workspace (couldn't see in VS with or without remote workspaces checked)
2) Deleting from the command line
3) New owner command
4) Deleting the cache
So I simply opened VS as admin and mapped to a different folder.
Deleting the workspace and cache was not sufficient for me.
I had to also restart the "Visual Studio Team Foundation Build Service Host" service.
Go to the Source Control Explorer
In the toolbar there is a dropdown list of Workspaces.
Click the dropdown and go to workspaces.
Remove the unwanted workspace.
Map to your local.
I changed
Build Definition -> Workspace -> Build Agent Folder
from
c:\some\path
to
$(SourceDir)
and it fixed the issue.
I had this issue with this with Azure DevOps automated builds in an on-prem TFS build agent. Removing the workspace using TFS Sidekicks did not work. And tf.exe could not even find the workspace to delete it.
This solution should work for TFS 2017, TFS 2018, Azure DevOps, and possibly other versions:
Take note of the workspace GUID in the error message.
On the machine where the build is taking place, navigate to: %USERPROFILE%\AppData\Local\Microsoft\Team Foundation\ (where %USERPROFILE% belongs to the user that triggered the build).
Search for and remove all instances of the workspace GUID under that directory. There will likely be a folder in a 'cache' directory, as well as entries in 'LocationServerMap.xml' and 'LocalItemExclusions.config'. Remove them all.
That worked in my circumstance.
Simply delete the workspace:
workspace /delete "the-workspace-name"

Resources