Thank you for the report - we have just released a new version of the extension that should resolve this issue.

Looks like it is fixed in version 4.05 (build 3)

Thanks for the report; I've logged this as PG-149 and we can fix in a future maintenance release.

Great, thanks for your help !

BuildMaster Enterprise is licensing on annual or perpetual/lifetime basis. If you purchase an annual license, then you'll receive a key that will active the software for a year, and we will provide maintenance/support during that period. To continue after the first year, you'd have to purchase another license. If you purchase a perpetual license, then you'll receive a non-expiring key and a year of maintenance/support. You can renew support/maintenance after that, but the software will work regardless. Hope that helps.

Hi, thanks for reporting this. It looks like a regression was introduced in the 4.0 line which prevents remote process execution over SSH from working properly. This will be fixed in the next maintenance release.

Hi Ivan, Good question... I haven't been able to reproduce this. What version is B referencing? Do you think it's a symbol cache problem? Alex

You mentioned, "alpha vsix" ... are you using ProGet Client Tools? Do you get this same behavior with NuGet?

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.