We have been facing this issue quite since a long time, and this is repetitive.
Application : Team Foundation Server 2010
What is the Issue: Users report that the build definitions are not visible.
Who observe the issue: Members that are specific to a project report the issue. However, the Project administrators(Default Collections) can access and queue builds without issues.
What is done as a workaround: We restart the TFS server, and reapply account from the Application Tier, after which the builds are visible to respective project Contributors.
Can some one let me know, what would be the issue, root cause, how to fix it?
Please add for any queries.
Related
Got 5 different TFS, is there a way to search in all TFS's? Visual studio plugin?
Right now I've downloaded all the source code to my local machine and turned on indexing on serveral filetypes (properties and inside files)..
If anyone has the same problem, how do you solve this kind of problem?
Never heard this kind of tools or plugin.
In a sense, there are different Application Lifecycle Management system. They have different servers, SQL servers, users, permission settings and so on. Searching between them, how could this be possible to achieve. Unless, you choose to migrate different projects to one instance of TFS.
OpsHub Integration Manager supports bi-directional synchronization between a wide variety of systems including Team Foundation Server and Visual Studio Online. It can be used for bi-directional sync between TFS and VSO. For more information please reach out to OpsHub at http://www.opshub.com/main/index.php/company/contactus
I have a WebApi project, and an MVC project that consumes the WebApi project through RESTful calls.
I set my VS 2013 Professional system to start both projects at the same time.
If I run either project alone, I can set and capture breakpoints. If I run both projects, only breakpoints in the WebApi project are available. How do I fix this? As far as I can tell, there are no version issues with any common assemblies, and the multitude of answers on SO do not seem to apply.
So apparently the answer is shouting curse words at your monitor. After restarting IIS Express, Visual Studio, and my machine multiple times, Cleaning the solution multiple times, changing the build config back and forth multiple times, it just started working all of a sudden. No code or configuration changes. Whoever said insanity is doing the same thing repeatedly and expecting a different result was clearly not a developer. Either that or I'm insane. (could be both)
I'm working on a check in policy and while testing it the first time, I got an email from a teammate saying he couldn't commit any files, because when I installed the policy for testing on my machine, his TFS died, because he didn't have the policy DLL installed and registered. It seems that when I registered the policy locally, the TFS server registered it for the whole team, and the other members don't have it yet, so their commits blew up.
But how are you supposed to develop and test a policy if the only way to do this is installing in the global TFS server for everyone? Clearly, the policy code isn't ready for deployment before you ever try to test it, and you can't test it if testing breaks TFS for everyone until you test and deploy it.
What is the way out of this problem? Ideally, I'd like to have a local-only policy, but that doesn't seem to be possible.
Policies are set on a per Team Project basis. There is no local setting for check in policies, they are created against the Team Project and everyone who is using that Team Project will be affected, meaning that you will have to roll out the dll to all users.
Your best solution is to have a test Team Project where you can try out new builds / check-in policies and other bits and pieces in isolation.
Once you are happy with what you have, you can then apply the same items to the main Team Project that your team is working on.
We've recently upgraded to Visual Studio 2013 and we're having some issues with the new way publishing is handled. Previously, (in VS 2010) every user had their own local publishing settings, but in VS 2013 it's changed to the idea of shared publish settings. This is causing problems with our environment because every developer has a different local dev environment (paths, connection strings, email addresses to send things to). I realize this is not the optimal way to have things set up, but that's the reality of our situation right now.
We use config transforms to handle the various web.config changes for different developers, so just running through VS doesn't work for us because it doesn't run the transforms. This also causes a problem with the VS 2013 publish settings because the last build config used is stored in the shared publish settings. In order to keep all our settings different, it looks like we're going to need to have a different publish setting for each developer now as well (such as "Local - Erik", "Local - OtherDev"). This is just going further down a path I'd like to get out of eventually.
So my question boils down to: Is it possible to somehow disable the shared profile settings? I thought of just not including them in version control, but then Visual Studio complains that the files are missing on other developers' systems.
Thanks for the help!
You can do this by excluding the profile from the project after you create it. The publish wizard looks for any profile on disk, but newly created ones are added to the project by default. If you then exclude the .pubxml file from the project and remove it from source control, it shouldn't bother you again.
I'm trying to define a new build on TFS using VS2012. When I go to New Build Definition -> Processes I'm seeing "Build process template" and an empty drop down.
I click on the "New..." button selects the default template from
$/<My Project Name>/BuildProcessTemplates/DefaultTemplate.11.1.xaml
and click OK but then I'm getting the error:
TF277000: A build process template for '$/<My Project Name>/BuildProcessTemplates/DefaultTemplate.11.1.xaml' already exists for team project <Project Name>. You cannot create another build process template for the same file. Use the existing one instead.
the drop down always stay empty. I tried to clean cache(AppData\Local\Microsoft\Team Foundation\4.0) and other sort brilliant tricks like close and open but nothing helped - the drop down stays empty.
I would really appreciate aמy help.
I had a similar issue crop up recently.
Background: TFS 2012 Project with multiple solutions under 1 Project Collection project. The 'BuildProcessTemplates' folder did exist in the Project collection project and did contain the standard templates. The solution was created in TFS 2012 and being coded using VS 2012 ultimate.
Symptoms: Any attempts to create a Build Definition failed due to a lack of Templates.
Actions - unsuccessful: I created a copy of the default template and used that for a template. I wasn't able to create a Build Definition since even with that, the dropdown was still empty. Also tried creating a custom template with the same lack of success.
Actions - successful: I separated the solutions into their own Project Collections projects. That put the solution at the same level as the 'BuildProcessTemplates' folder. Once that was accomplished, I was able to create a Build Definition for those solutions.
Comments: I'm not sure if this is a bug in TFS 2012 or not. I would like to think if it is a bug in TFS 2012, it is corrected in TFS 2013.
Your thoughts?
Robert
I recently ran into the same problem with not being able to see build process templates when trying to add a new build definition. We are in TFS 2012. This team project also appeared not to have any build definitions. That was expected though because we had not yet used the TFS builds on this team project.
The problem was caused by someone with admin rights setting the "View build definition" and the "View Builds" access rights to Deny for everyone.
By just setting that back to allow on the TFS group, we suddenly could see the build definitions and also were able to select build process templates.
It was really strange that it let us add new build process templates, but we couldn't select them.