ProGet does not support being installed in a virtual directory; it must be at the site root.

We have upgraded to Buildmaster 4.0.9 (B31) and the "Execution Status" == succeeded work better but still not correctly. The predicate test is on the Action Group which contains 2 separate actions. The first action fails (and shows as failed in the log) then the next action succeeds and this marks the Execution Status as succeeded again to the remaining predicate tests pass. It would seem that the Execution Status should not be set the succeeded after it has been set to Failed.

Additionally, if you have publish profiles saved in your solution, you can add the following additional argument that will exhibit the same behavior as AutoParameterizationWebConfigConnectionStrings=false for the chosen ProfileName: /p:PublishProfile=ProfileName

The "default" folder (usually the SRC subfolder) is unique to applications and deployables, and is housed under the <bmas-tmp>\A<appid>\S<depid> folders. It is cleared during the "preparing agents" step at the start of every action, unless it's a re-execution of a failed deployment. Only one execution within an application is permitted at the same time, so the second one created will be queued until the first completes.

Yes; if there is no deployable, then "0" is used as part of the path (e.g. <tmp>\A12\S0\WRK\my-path)

It's not available now, but we are strongly considering targeting that (and some related features) in v4.2, which should ship in March.

It appears the user that is running the web application does not have the needed permissions to restart the BuildMaster service. If you either 1) change the user account to one that has permissions to do so, or 2) manually restart the BuildMaster service, you should see the extensions.

Hi Tod, I was aware of this extension but it didn't work for me (gave me all sorts of build errors). I took a closer look and you did help me on my way. I am now creating an artifact from a TFS build, make a temporary deployment and zip up this deployment into a new artifact. Everything works now, thanks!

Command line works just fine..

This is caused when BuildMaster cannot determine the CPU ID or MAC address of the server it is installed on. Here is a detailed description: http://inedo.com/support/kb/1005/this-machine-cannot-be-uniquely-identified Typically, restarting the server fixes this problem. If that still doesn't work, you can also try the following steps to resolve: Stop the Windows Management Instrumentation service. Go to the %SystemRoot%\System32\Wbem\Repository folder. Delete all of the files that are in the %SystemRoot%\System32\Wbem\Repository folder. Restart the computer. The files that were deleted are recreated when the computer restarts. The Windows Management Instrumentation service will start automatically when you restart the computer. (These steps were taken from: http://minasi.com/forum/topic.asp?TOPIC_ID=5772)

There is no officially supported desktop client; however, one of our VIPs at Leaping Gorilla built a custom one. The repository is at: https://leapinggorilla.kilnhg.com/Code/Open-Source/Group/Buildmaster-Tray

I can't think of any tangible benefits to doing so, and can't think of any real drawbacks either. The only possible issue I could think of would be cookie related -- e.g. if you have the same hostname for both products differing only by port, there could possibly be conflicts with the cookie names. Using different hostnames would solve that, however.

Hi Tim, Multiple Active Builds will not auto-reject builds when another one in the same release is deployed to the environment. It's mostly used when testers need to consider which build (of many) will be promoted to the next environment. There is a limit of "one connection per deployable" in the Express Edition and yes, the packager uses the same metadata table. Also... as an FYI, Express Edition Upgrades do not include support/maintenance, and we are planning to phase them out soon.

Thanks for the report. This happens because the default package storage path for a feed uses the feed name, but doesn't rename the directory when you edit the feed name. You can fix this either by specifying a storage path for the feed, or renaming the existing storage path to match the new feed name.

Were you able to resolve this? Can you try clearing cache & cookies, and try again? Also, if you're hosting in IIS, can you run "iisreset" from the command to restart IIS... or restart the ProGet service from the services management console?

Thx Todd. It was exactly that.

Thanks, in our case the variables do not actually get used in the first environment, they are entered for consistency. Good to know it will be fixed in the future.

Hi Tod, I could fix this problem and now all my servers are have their agents up to date. I had to remove everything from buildmaster from the server. I have uninstalled buildmasters agent, from Programs and Features, deleted BuildMaster website, application pool and the agent files from BuildMaster directory. Then, I have run the agent installer again in the server. Now, the status shows "Ready" and I am not receiving those "Error scanning agent for..." anymore. This is just a heads up, but it seems that the agent installer is not updating the existing agents in the server. Thanks

I’d rather not send through a package with our production code in it, so I’m going to see how the working package compares to the failed ones.