We did not change the way the integrated web server worked... so I would try to monitor the ProGet website and service to see if it gets shut down. That seem unlikely, since it doesn't happen consistently. Maybe it's also network related.

The Linux Agent/Extension has been deprecated as of 4.0, and is now built-in to BuildMaster. You should just be able to set up an SSH-based agent and execute shell scripts w/o problems.

I just noticed you actually have already released 2.2.5 I confirm that it does resolve our issue. Great support, thank you!

Well sure, I <em>could</em> just script this stuff myself ;)

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.

Tod, thanks for answering. I really had 2.2.3 version. After installing 2.2.4 problem disappeared.

We'll put this on our feature list, but since it's not a necessity it won't be high in priority.

Before directly executing a stored procedure, you will need to set the CONTEXT_INFO. This information is used to trigger events and set the value of the CreatedBy and LastModified user name. This only needs to be done once per connection, and you can use this script to set it: DECLARE @B VARBINARY(MAX) SET @B = CAST('yourname' AS VARBINARY) SET CONTEXT_INFO @B Obviously, "yourname" should be replaced with a more meaningful string, but it doesn't have to be your username. It could be "SQLAPI".

At the moment that is not an option but we'll look into adding it. As an alternative, you can workaround the issue with an Execute Command Line action invoking MSBuild directly, e.g.: Executable: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe Arguments: "C:\path\to\sln" "/p:Configuration=Release;" "/p:OutDir=C:\path\to\output" "/t:TargetName"

The .NET-based actions were included in the Windows SDK extension, yes. The "Build .NET Project" action was renamed to "Build MSBuild Project".

Steve, Yep seen that article, tried it all, except the installing visual studio, as the server admin has a big problem with us doing that. He has tasked me with exhausting all the possible avenues before we pull that trigger. Will see, if that ultimately is the only solution that will work, then he will just have to like it...

I added an older version of the ProGet website to my server and enabled it. This website returned an error that my app pool's Managed Pipeline Mode was in Integrated and should be Classic, switched to Classic and the site worked, switched back to the latest version of the ProGet website and it worked. Switched back to Integrated and the site broke with the same 403-14 error message. I am not sure why the app pool was ever in Integrated mode.

The SOAP-based agent is the IIS-hosted agent, so IIS would need to be enabled. The installer for that agent will automatically set up IIS for you.

Strange, those error messages are coming directly from the TFS SDK. Are you perhaps using hosted TFS? I've found an MSDN thread that might detail why you're seeing that message: http://social.msdn.microsoft.com/Forums/vstudio/en-US/b50ee81b-b2cc-449c-8deb-3d9bafc84d58/access-denied-elastic-build-needs-the-following-permissions-to-perform-this-action-edit?forum=TFService

Actually I was able to reproduce this in our test environment - when the action was rewritten that field wasn't marked as persistent for some reason - one of our devs will publish a new version of that extension in the next few minutes and it will be available from the gallery.

That field is supposed to be required. We will update the behavior of the control to display an error message if no group name is supplied.

We've been making a lot of changes to our SDK during the 4.0 beta period - looks like you found a spot that we missed. I've updated the extension. The Gallio extension (v4.1) should have this issue resolved for you.

Thanks that fixed it

Thanks for the additional debugging information; we now see why this doesn't work. It would appear that NuGet stopped streaming all versions of the packages at some point, and now appends the following at the end of its package search XML... <link rel="next" href="http://www.nuget.org/api/v2/Packages? $filter=tolower(Id)%20eq% 20'ravendb.client'&$orderby=Id& $skiptoken='RavenDB.Clie nt','RavenDB.Client','1.2.2005-Unstable'" /> So, we will need to add support for this as well... I've added this as PG-140, but it's not scheduled for a release yet. If an enterprise (i.e. paying) user requests this, we can expedite it of course.

I ran into similar problems myself with the latest version of ProGet as of 10/22/2013. It seems that the name of the DB has been changed to BuildMaster. I didn't see any ProGet database but there was one called BuildMaster so I followed the directions substituting "BuildMaster" instead of "ProGet" and it seems to have worked.