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.

Local packages are indeed prioritized over connector packages, my guess is that you have either a cached package or cached feed request happening on the client end. If you look at the feed rss (you may need to use fiddler or something to capture output), you can see the exact metadata that's being requested. In the metadata, there will be a url that points to the downloadable .nupkg.

This is something we're thinking of adding eventually (i.e. Retention Policy), but for the time being, you can delete the packages from disk via PowerShell if you're comfortable with writing a script like that. We'll try to get this feature into the next version.

Thanks, Tod. How to fix that? The exceptions are from the scm triggered build function.

Yes, this can be done with an Execute PowerShell Script action: http://technet.microsoft.com/en-us/library/ee177004.aspx

Based on the error message and symptoms (it was working fine, until it wasn't), it would appear that the indexing error is from a poison package. We made the mistake of using Microsoft’s Packaging libraries (System.IO.Packaging) to open this package, and among many other bugs, it will produce an un-catchable exception (fun fact: if you happened to be on a non-english Locale, it will terminate the whole process with a stack overflow exception). We cannot work around this problem, but the bug appears to be fixed in .NET 4.5.1. If you upgrade to that, the error should go away.

There's no hard date, but we're targeting for the next week or so.

The API is meant to administer ProGet itself, not anything related to packages - that method should actually be hidden. All it does is remove the entry from the DB, but when re-indexing occurs, of course it would get added back. If you on the other hand simply delete the file from the file system, or run nuget.exe delete then it will work.

This is almost certainly a user account issue. Can you invoke MSBuild manually as the same account used to host the BuildMaster service? That should give you the same error. If you install the licenses as the same user hosting the BuildMaster service it should work. The SRC directory becomes the WRK directory when there are target directories involved (in this case the build output).

First, make sure the service is running. You can rebuild the index by setting RebuildPackageIndex to True in the All Settings page. It will rebuild within a minute or so.

We've added a workaround for this in ProGet 2.2.7 that should fix it.

Can you change the IIS App Pool mode to "Classic"? This should correct the problem.

This setting is now configured at the Workflow-level instead of the Application-level. So, just edit your workflow in the application.