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.

Interesting - was there an error message or indication as to why the first project failed to build? It does appear that the arguments were passed in correctly. The 2nd error would be expected because the added target changes the way MSBuild outputs the target files. The action is expecting the output to be in the \TMP\Release\Package\PackageTmp directory.

This issue is resolved now. The problem was that when ProGet is using LDAP (AD) for authentication so the requests always use NTLM (ignoring any user specified on the command-line or config). Changing the build-agent service to run as a domain user resolved the issue. Note: this was encountered with Bamboo build-agents, but I'd expect similar issues with Jenkins/Hudson build slaves, or other CI tools.

This sounds like a problem with Windows Authentication on your IIS installation. If the LOGON_USER is blank, that means IIS is not passing it in. There are a lot of things to try to resolve this, i'd try amore general search like (LOGON_USER header missing), etc.

While there's no direct support for this, if you've already retrieved them from Visual Studio, the PDBs should be cached locally in the symbol cache. Another way I can think of to do this is to get the package directly from disk on the ProGet server or share. You can't download them from the web app because it strips the PDBs out of it. Once you have it, you can open the .nupkg as a zip file and grab the PDBs from the lib/netXX directory.

PowerShell parameters are now supported in v4.2 of the Windows extension.

I've submitted the info to support and also created a fork of the Leankit integration in GitHub. Thanks again!

Thank you for the detailed report. This has actually already been fixed in ProGet 2.2 and later versions.

The only access to add packages via an API is through the NuGet API itself. If you'd like to move packages, you can simply move them from one feed's storage on disk to the other.