SQL Server Management Studio add-in: How to specify API key?

elofgren

If I set requireApiKey to true in C:\Program Files (x86)\Red Gate\Deployment Manager\NuGet\Web.config and attempt to publish to Red Gate Deployment Manager's nuget feed I get the following error:

Failed to push to package feed at 'http://mysub.mydomain.com/nuget/'. This may be because the server requires an API key to push packages.
(The server responded with: [500] Internal Server Error)

It works fine if change C:\Program Files (x86)\Red Gate\Deployment Manager\NuGet\Web.config back to:
<add key="requireApiKey" value="false"/>

I would like to require an API key to publish packages to my Deployment Manager package feed. Is there a way to tell the SQL Server Management Studio add-in the apiKey value to use for the nuget feed?

Thanks for creating this amazing tool!

- Elijah

Edit: I am using the latest versions of Red Gate Deployment Manager and SQL Server Management Studio add-in as of June 11th or 12th, 2013. Thanks!

James B

Thanks for your post.

You actually need to enter an API key on the first step (see screenshot below)- you'll find this on your user profile page within the DM console (i.e. click on "Administrator" at top right)

elofgren

Ah, I see the shared API key must have been replaced with the user-specific API keys. Thanks!

James B

Actually, that may not help after all (mainly because I didn't properly read your original post!)

The out-of-the-box Nuget server that comes with DM wasn't really intended to be reconfigured in any way; and as a result, the SSMS plugin doesn't have the functionality within to pass the key (the key you need to enter is a DM API key, not a Nuget key)

If you want to use authentication on the feed like that, then you need to publish from something that's able to do it. This would normally be part of a bigger CI solution using something like TeamCity, and you can then utilise SQLCi.exe with the key needed to push to your Nuget repository. We'd generally assume by this point you've configured your own Nuget as opposed to still using the default-installed one too, although this wouldn't be required specifically.