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.

Thanks for the report - I have logged the issue and included it as part of 4.0.8 (BM-1299).

What screen were you on when you clicked the button to re-execute? I can't seem to reproduce this in our testing environment.

I've added this as BM-1297,and it should be fixed in the next maintenance release of BuildMaster (4.0.8).

This should be resolved in v4.2 of the extension: http://inedo.com/buildmaster/extensions/perforce

To change the connection strings in BuildMAster, just edit the *appSettings.config files in the WebApp and Service directories.

As you recommended, I installed .NET 4.5.1 and it fixed it. FYI, the server locale is French (FR_CH). Thank you for your help. Regards,

Everything seems to be back in working order now.

Thanks for this report. This issue has been corrected as of ProGet 2.2.6.