We don't have that as a retention policy currently, but can consider adding it in the future!

You could use the API to delete one by one of course, but If you delete the packages from the store on disk, and then manually run the feed clean-up indexer (Admin > Tasks), then it will do the same.

Hi, yes -- There are quite a few users that have BuildMaster to do just that. I'm not sure about the Oracle/SOA services, but if it's something that you can write in a quick script, then it'd be fairly easy to add as an action as part of your deployment plan.

hi, I'm not sure I understand the question? But, you can set up multiple database conenctions in your application, and pick the ones you want to use... either directly or with a variable.

In my case, I was generating the "real" packages in Release build configuration but generating the symbol packages in Debug build configuration. Once I realized the symbol server wouldn't respond correctly when the build configuration differs between the packages, I published the symbol packages in Release build configuration so the packages matched and everything started working correctly. Hope this helps someone else in this same situation!

You really shouldn't use API keys with ProGet, actually. From the docs: An API Key is used by NuGet client tools (such as nuget.exe and NuGet Package Explorer) as an authentication mechanism for publishing packages. It makes a lot of sense for the NuGet Gallery, as it's a community-run site where anyone can publish packages they own. In enterprise environments, the notion of individual package ownership doesn't quite translate, nor does the usage of API Keys. With ProGet, a principal (user or group) either has privileges to publish a package to a feed, or does not. This allows ProGet administrators to more easily control access and usage through LDAP and Groups instead of through community mechanisms like API Keys. So, if they can authenticate to the feed (using basic auth or windows integrated auth... or even an api key in the form of user:pass), and they are authorized, then the can push a package.

Thanks, Dan. It looks like this resolves the issue I was seeing as well! Now I just have to figure out why my ProGet server won't do a full index of npm without having the connection forcibly closed, but at least I'm back in business.

In order to do this, you'll need to set up a separate configuration profile. you can do this in Admin > Extensions > TFS.

If the installer is signed by Inedo, then you can be assured it's a false positive. We have no control over how A/V companies detect "viruses", but if you could please report this as a false positive, then they will be less likely to falsely detect our installers.

It's not that "tags appear to become meaningless once a newer version of a package is present", it's just that tags are part of an individual package's metadata (see the NuSpec Reference) just like name, description, authors, etc. The VS Client, nuget.org, and every other package manager UI we've worked with will only do metadata search on the most current version of a package by default; otherwise, outdated and irrelevant packages would come up in results. As you can see, it's possible to use an API to search for these things... but tags are simply not intended to solve the problem I think you're trying to solve.

Here are the actions that aren't supported via SSH agent currently: Unit Test Actions HTTP Reporting Actions Generate Release Notes Action (unless running on BuildMaster server) Execute Database Change Scripts Action Rename Files Action (shell script is recommended for this) Set File Attributes Action (shell script is recommended for this)

You can just edit the workflow step and select the deployment plan you want for that particular workflow step. There was a bug fixed in the v4.7.4 version that caused this behavior, typically when combined with Build Steps and multiple workflows. If you upgrade to the latest maintenance release for your minor version (i.e. v4.7.5) the copy should work as designed in all cases.

The page was changed in v4.8.2 to only show the first 30 releases for perf reasons, so if you have more active releases than that, the list would be truncated to the first 30 ordered by when they were created. We're open to making this behavior configurable instead of a strict limit of 30.

I see, that's perhaps the most common usecase for ProGet, so it should just work. I suggest to attach Fiddler, or Wireshark, then compare the results between one computer and the next. Then you can see exactly what the results are. Something could be filtering it in between, redirecting to the wrong server with a hosts file, etc.

The Build MSBuild Project actions effectively just run msbuild.exe against your project files; so, I would start there. KB1052 offers some troubleshooting tips, see the "Issues with third-party tools and integrations" section for how to dig into the details.

Nice. It would be even better if you could see this log info next to "Last updated" while browsing a package.

I'm afraid I don't have enough information to help diagnose this problem. Please keep in mind, BuildMaster isn't actually looking for anything -- it's essentially just executing a third-party tool like nuget.exe and msbuild.exe with the arguments you specify, so it's important to look at both the arguments to those commands and the working directories those commands are being run in. These will be logged near the top log for the action.

The issue turned out to be more of a Nuget issue, I believe. According to Nuget's docs, I should be able to mirror my package by specifying the push package URL in the following format: (proget server)/api/v2/package/. However, this just grabs the first feed under /package. Instead I needed to specify the feed name: (proget server)/api/v2/package/myfeed

Is there any other error information e.g. stack trace or error details? You can look in the Windows Event Log for more info.

the error was not occuring when trying to select project. Browsing worked perfectly, i was able to browse and choose my SLN file. the error occurred upon clicking "next". All that aside, installing .NET 4.5 seems to have resolved the issue. 4.5 is not a requirement for vault or for BuildMaster, but seems to have changed something. I found an unrelated artical on google saying that they were getting a MaxArrayLength error, and that the error went away after installing .NET 4.5, so i figured it was worth a shot, and sure enough issue resolved!