Hello. What we noticed is that when we receive this error if we delete the nuget package in the feed and then reload it the problem disappear. We still have a legacy feed. Do you think that info could be relevant?

Most definitely; it's a must-have as we transition from a "private NuGet server" to a "private repository manager". I suppose we should explicitly list it under "New repository formats". I'll add a +1 to our (internal) tracker!

Ah; well, that would explain it :) Your PDB files contain no links to source files, which VS and ProGet are unable o index/locate them. This means you'll need to adjust your complication process to incluse them. A quick search surfaced this article, which may be of assistance: Correctly Creating Native C++ Release Build PDBs. Please do post an update if you find the issue/setting in your project/build file that prevented this from happening.

This will be the simplest resolution. First, upgrade the database instance to SQL Express 2008 or 2014; this will increase your limit to 10GB. Just download and run the installer from Microsoft, and instruct it to upgrade the instance. Then, upgrade to BuildMaster 4.8, which will have retention policies that allow you to delete/purge execution logs (which are taking a lot of space).

Thanks, all good now.

Actually, one more comment re: this. It appears that the package ID is synonymous with its name. I thought there was a separate ID value. When I grabbed all packages and versions and tried to serialize in PowerShell, it failed due to the size of the content, so it was good to discover that I can query for the specific package name/ID.

This sounds like it's an issue with your workstation communicating with the server; the 400 indicates a problem with WIndows/NTLM authentication. That's not done by ProGet, but it's handled by IIS/Windows. It could be a whole lot of things, from system clock being off by a few minutes to domain/security issues. Unfortunately there's not a whole lot we can help with, though i'd suggest to search "Windows Auth not working" while including specific messages you're seeing, and try to narrow down form there. Please share what you find, as someone else might come across the same configuration problem.

If you don't specify the symbols option, but include everything in a src directory, then it will work. Keep in mind a NuGet package is just a zip file, so if you're having trouble using nuget.exe with nuspec files and native packages, then you might find it easier to workaround by creating the zip file. Just remember to follow the conventions.

Yes; this would ultimately be done through the typescript compiler (tsc.exe), so it really depends on how you plan to build/use them. For .NET projects, it's something that msbuild calls, and you can specify whether or not to generate the .d files in the project properties. Otherwise, you could simply call the tsc.exe directly with the desired parameters. ONce you have those, you can capture the artifact from there.

It can do that, but it won't automatically. You have to configure the deployment plans. Think of the deployment plans as a script that will run each time you deploy to an environment. For stored procedures, those should be treated as code and kept in source control, as they can be recreated simply with a DROP/CREATE/CONFIGURE script file. This way, they can be redeployed like any other artifact (i.e. extracted to some directory and executed from disk). As mentioned in the previous post, DDL/DML database changes cannot be automatically rolled back because once you DROP a column, it's gone for good until you restore from backup. Configuring a deployment plan to take a database backup is probably a good idea in this case :) You could go one step further and configure the deployment plan to restore from that backup on some condition if you really wanted to, but I would hope once the deployment is automated that these failed deployments will be kept to a minimum.

Yes; BuildMaster can do anything it is configured to do in its Deployment Plans. There's a few backup strategies you could use: zip contents of target project and move it to a backup folder deploy to a target directory then swap directory names deploy straight from a BuildMaster artifact, then a zip backup would be kept automatically (recommended) The 3rd option gives you a pretty easy way to rollback, provided there aren't API-breaking database schema changes (you'll have to restore the DB in that case, since you can't unDROP a column). See the following for more information on rollbacks: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

We do same in our company. I download Proget from here http://inedo.com/proget/versions and the free verion option is available.

Hi Steve, good question. We don't currently have a custom description per each action, but that's going to be in the v5 style plans. You can use the action group description if feasible. We do have a "show full path on hover" coming in 4.8.1 (due later today), but we can probably add in a view as well.

Yes; deployment automation is a core function of BuildMaster. The pricing is specified here, BuildMaster Licensing and Pricing, and we have service partners around the globe that can help determine cost of services (or, you can learn/use BuildMaster yourself).

Yes indeed! BuildMaster has built-in database change script and database connections for running sql scripts in various environments

Just letting you know that we have added a feature to BuildMaster 4.8 that we're calling Ambient Script Variables that should solve this problem. Basically, it allows you do define script variables that BuildMaster will evaluate and assign before running a script. So, in your case you'd just add one called ReleaseNumber that contains the value $ReleaseNumber (the value can evaluate to anything though, and use any variables/functions that are in scope when the script runs). 4.8.0 should be released tomorrow.

For completeness, this specific issue was related to invalid credentials, in this case, the username was being entered with a domain prefix when the SVN server did not require one.

I had the same problem, the packages still showed up after deleting the conector. SOLUTION Restart Proget DETAILS I browsed the database and the packages folder for the offending packages and could not find them. The connector was also deleted from the database. Running feed cleanup also did nothing. In short, I could find no evidence of a problem that would persist after a restart, so I restarted the server Proget ran on and after restart it no longer pulled in packages from the deleted remote. I have proget version: Version 3.7.5 (Build 3)

Which API are you calling, the SOAP or the JSON API? And which method in the API are you trying to call? The value for the API key can be any text, and for the JSON API, would be passed in as: http://buildmaster-server/api/json/Method_Name?API_Key=yourKey&Argument_1=value1&Argument_2=value2 The easiest way to go about your issue is to create a URL-Triggered Build. Note the screenshots are a bit out of date but the information is the same.