Was able to connect to TFS 2008. After the upgrade to TFS 2010, I am unable to connect.
I reconfigured jenkins to use the new VS2010 tf.exe.
I reconfigured my job to point ot the new URL.
Verified my password is correct...
Within visual studio I can connect and use TFS 2010 without any problems.
However I am getting permissions problesm when trying to use Jenkins.
I have updated to version 1.20 of the TFS plugin and the problem still persists.
I have restarted the service before and after configuration changes...
Any ideas on what might be wrong? I changed the group/account in the log for safety.
Log is:
[workspace] $ "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf" workspaces -format:brief -server:http://sbn01p-tfs1001v:8080/tfs ********
TF50309: The following account does not have sufficient permissions to complete the operation: <group>\<my account>. The following permissions are needed to perform this operation: View collection-level information.
FATAL: Executable returned an unexpected result code [100]
ERROR: null
Team Foundation Server, beginning with TFS 2010, adds a new concept called Team Project Collections. Your Team Project Collection needs to be specified in the URI, for example:
http://sbn01p-tfs1001v:8080/tfs/DefaultCollection
Related
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
}
I am trying to build a project with build server and it keeps giving me the following error:
C:\Program Files (x86)\MSBuild\InstallShield\2013Limited\InstallShield.targets (108): -7159: The product license has expired or has not yet been initialized.
I have added the account used by Build in the build collection administrator group and project collection administrator group. I also activated installshield both through Visual Studio (creating new setup project) and then going in this location
c$\Program Files (x86)\InstallShield\2013LE\System\TSConfig.exe
I have VS 2010 (Shell), VS 2012 and VS2013 installed.
I have also added this user in the administrator group on that server. I have restarted the build server multiple times. I am not sure what else to try. Could anyone please help
Be ensure that the BuildService is not running with a local account such as "NT_AUTHORITY\Network Service". If so, please change it with a domain account and add the user account to the administrator group. Restart TFS build server machine, and re-queue the build.
In addition, please also have a check on this blog for the details on how to work with Installshield with TFS build:
http://blogs.msdn.com/b/girishp/archive/2014/03/04/installshield-and-team-build-on-tfs.aspx
I have configured TeamCity to work with our TFS repo. I have configured the VCS Root and used the "Test Connection" to ensure that the settings are all correct. When I run a build it gets to the "Updating sources" and just hangs there. Here's the build log.
[13:33:45]Collecting changes in 1 VCS root
[13:33:47]Clearing temporary directory: D:\TeamCity\buildAgent\temp\buildTmp
[13:33:47]Publishing internal artifacts
[13:33:48]Using vcs information from server. Reason: no revision information for build configuration "Build Development trunk" and checkout directory D:\TeamCity\buildAgent\work\db23c120e1319dcb on agent
[13:33:48]Clean build enabled: removing old files from D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Checkout directory: D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Updating sources: server side checkout (1m:21s)
[13:33:48][Updating sources] Will perform clean checkout
[13:33:48][Updating sources] Clean checkout reasons
[13:33:50][Updating sources] Building and caching clean patch for VCS root: Development trunk
The checkout folder is empty. Any ideas?
EDIT
I've written a Windows batch file that gets the code out from TFS rather than using TeamCity to do this. My batch file runs perfectly when run from the Windows command prompt but fails when run from TeamCity. I am using the fully qualified path to TF.EXE because TeamCity doesn't seem able to find TF.EXE (even though the path has been added to the PATH environment variable).
My batch file correctly configures the TFS workspace before trying to GET the source code. But it still fails.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /collection:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /s:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workfold //fails!!
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" get $/MSM\Development\Trunk /force /recursive //fails!!
The error I am getting is "Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'"
But as can be seen I am already specifying the workspace in the batch file.
Any ideas why these commands work from the Windows command line but fail from TeamCity? How do I get them to run from TeamCity?
The solution in my case was to upgrade my Team Foundation Client from 2012 to 2013. There are known timeout issues with the 2012 version and upgrading to 2013 has resolved these.
I had the same issue (TeamCity builds that fetched code from TFS would get stuck indefinitely at the Updating sources stage, blocking the agent).
The solution for me was to make sure that the TeamCity Build Agent ran under the same service account as the TeamCity Server. The server would be able to access the TFS project and instruct the agent to do a build, but the agent itself got stuck when it was not authorized.
When that account mismatch was fixed, it all started working as it should.
As a side note, when the parameter “teamcity.tfs.mode=java” is set, the TeamCity agent does not get stuck, but instead fails with an instructive error message (detailing the current service account name), if it runs under an unauthorized account.
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.
When attempting to create a new TFS Team Project from VS2012 I received the following error after pressing finish.
TF30279: Plug-in with ID "Microsoft.ProjectCreationWizard.Build" of type "Project Creation Plugins" could not be loaded
TFS and VS were both installed on a Windows 7 laptop for evaluation. When setting up TFS I configured the build server without error.
In attempting to get round the problem I uninstalled all 2012 components VS, TFS and Sql Server, then reinstalled them. I tried both TFS express and VS2012 for web express and full TFS trial and VS2012 premium trial (to rule out that it wasn't an issue with the express versions)
Each time the error would persist across re-installs.
Although I could not find why the problem has occurred I did eventually manage to fix the issue after reading up on process templates and understanding where the plugin models were sourced from.
1) I opened VS2012 command prompt and ran as admin
2) changed dir to %programfiles%\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
3) ran gacutil /i for each dll in the folder that looked like it was anything to do with build.