Thank you for the kind words, PJ. No, LOCAL SYSTEM is not a requirement at all, and obviously not recommended for most installations (which is why it is not the default). If you had followed the instructions in the error message that you received, you would know that you could grant the user account hosting the web application the specific ability to control the service by selecting the AllowServiceControl menu option when running bmservice.exe. I've also gone ahead and censored the email address that was entered into the public-facing "Name" field to prevent spam bots from scraping it.

There shouldn't be. It's probably trying to create a new record for whatever reason and that is triggering the dupe check. There's no other provider with that name.

We've added support for extensions to allow HTML issue descriptions as of 4.1.0, but we still need to update the TFS extension to indicate this. We should have it available within a day or two.

Every .NET project that consumes NuGet packages has a packages.config file, and that should be in source control. Unless I'm missing something, the deployment plan actions should be as simple as "Getting Latest" from TFS, then an "Install NuGet Packages" action followed by "Create NuGet Package".

Hi Matt, The BuildMaster agent doesn't need to be installed on the TFS Server itself; whatever server you're using as your build server (could be same server BuildMaster is installed on) should have the TFS Client (Team Explorer) installed. As for the agent error... the "IIS agent" is "SOAP Based" --- so you'd want to make sure to add a SOAP Based agent from the BuildMaster servers page. To test that IIS agent is installed, you can do http://localhost:81/agent.asmx -- if that page shows up, the the agent is configured in IIS correctly.

In case anyone else runs into difficulty with this, as I did, here are a couple of things to keep in mind: You WILL need to install Team Explorer 2012 on the server that will be connecting to TFS -- in my case, since I don't have a dedicated Build server, that means I needed to install Team Explorer BuildMaster server. Installing Team Explorer (http://www.microsoft.com/en-us/download/details.aspx?id=30656) WILL install a "shell" version of Visual Studio 2012. If (like me) you don't want extra tools like VS on your server, it's possible that you may only need the DLLs -- but according to Inedo support, that would be a violation of Microsoft's licensing rules for Team Explorer. In the "Server Name" field, you should enter the complete URL to the TeamProjectCollection you'll be working with, NOT just the main server or web access URL. In my case, this was http://tfs_host:8080/tfs/MyProjectCollection I hope these help someone else; it took a lot of guessing and finessing to figure all this out, as Inedo support reps really don't tend to explain things clearly AT ALL, at least if you're using their Free Support.

That's great news John! (I had a 3 failed builds last night because of this issue)please let me know if you have any questions or if there is any additional information I can provide.

The Branch Action is designed for "tagging" builds (Subversion and CVS), and actually, it's been renamed in 3.2 and will only be displayed if you have one of those providers. You're definitely on the right track for labeling each build, but merging... it's not really something you can do on an automated basis because of conflicts. That said, if you do want to merge, you can simply call tf.exe merge.

We just released our TFS2012 extension - http://inedo.com/buildmaster/extensions/tfs2012

We do use the specific paths under the project root. The issue still occurred, but we altered our labels to have a text precursor and now it works. It appears to be an issue with mostly numeric labels and TFS. If two apps in the same root project happened to get similar release numbers... then it bombed.

Some providers, including the TFS provider, do not include the branching functionality. Generally, our branching actions are only implemented for providers that don't allow labeling (such as SVN which only allows tagging). One way to branch is to use the "Execute Command Line Action" against tf.exe command line utility to perform the branch with the appropriate arguments (http://msdn.microsoft.com/en-us/library/d73s8b27.aspx). Since our providers are extensible, we could always add this functionality to the provider. We prioritize features like this based on usage, so if you could send your use case to support at inedo dot com we'd be glad to help further!