NuGet

The proxy implements the NuGet v3 protocol, so any client that speaks it can restore through ShieldedStack.

Endpoint: <proxy-url>/nuget/v3/index.json

Authentication: the API key, sent as the password in HTTP basic auth. The username is not checked; _ is the conventional placeholder.

Configuration below is written for nuget.config, which the dotnet CLI, nuget.exe, and IDEs all read. Paket resolves from the same feed but does not read nuget.config at all, so it is configured separately further down.

nuget.config

Create or update nuget.config, usually in the project root or %APPDATA%\NuGet\:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="shieldedstack" value="PROXY_URL/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <shieldedstack>
      <add key="Username" value="_" />
      <add key="ClearTextPassword" value="YOUR_API_KEY_HERE" />
    </shieldedstack>
  </packageSourceCredentials>
</configuration>

Replace PROXY_URL with the base URL. The samples on this page use a bare PROXY_URL rather than <proxy-url> so that the file stays valid XML before you substitute it.

<clear /> matters: without it, the default nuget.org source stays in the list and restores can satisfy a package from there instead of through the proxy.

ClearTextPassword holds a secret. See Committing the configuration before putting this file in source control.

Against an HTTP-only deployment, the source has to be marked insecure explicitly:

<add key="shieldedstack" value="PROXY_URL/nuget/v3/index.json" allowInsecureConnections="true" />

dotnet CLI

The same source can be added from the command line instead:

bash

dotnet nuget add source <proxy-url>/nuget/v3/index.json \
  --name ShieldedStack \
  --username _ \
  --password YOUR_API_KEY_HERE \
  --store-password-in-clear-text

PowerShell

dotnet nuget add source <proxy-url>/nuget/v3/index.json `
  --name ShieldedStack `
  --username _ `
  --password YOUR_API_KEY_HERE `
  --store-password-in-clear-text

Clear the HTTP cache afterwards, so restores do not serve metadata fetched before the source changed:

dotnet nuget locals http-cache --clear

Paket

Paket keeps its own source list in paket.dependencies and ignores nuget.config entirely. A solution that restores correctly through dotnet restore still resolves from nuget.org under Paket until this file is changed.

Replace the public source rather than adding to it:

source PROXY_URL/nuget/v3/index.json username: "_" password: "%SHIELDEDSTACK_API_KEY%" authtype: "basic"

Deleting the source https://api.nuget.org/v3/index.json line is the half that matters, and is Paket’s equivalent of <clear />. With both sources listed, Paket can satisfy a package from either.

Paket expands %VARIABLE% in credentials on every platform, not only on Windows, so the line above is committable as written and the key comes from the environment at restore time.

paket.lock records the source each package resolved from, so a lock file produced before the change still points at nuget.org. Re-resolve after editing:

dotnet paket update

Committing the configuration

Keep the source definition in source control and the key out of it. Commit a nuget.config carrying only packageSources, and supply credentials at runtime through dotnet nuget add source or the environment, so no committed file contains ClearTextPassword with a real value.

paket.dependencies is safe to commit as written, because the %SHIELDEDSTACK_API_KEY% reference is expanded at restore time rather than stored.

Verify

dotnet CLI

dotnet restore

Paket

dotnet paket restore

The restored packages appear under Packages in the Portal, attributed to the project name on the API key.

Names in package filters

Package IDs are case-insensitive, as they are on nuget.org. A filter written as Newtonsoft.Json is saved and shown as newtonsoft.json, and it matches the package however a client spells it. Separators are not interchangeable: Foo.Bar and Foo-Bar are different packages. See Package names for how every ecosystem compares names.

Troubleshooting

401 or 403. Confirm the credentials block’s source key matches the name in packageSources exactly. They are matched by name, and a mismatch reads as an anonymous request.

Packages still resolve from nuget.org. <clear /> is missing, or another nuget.config higher up the directory tree adds the public source back. NuGet merges configuration from every nuget.config between the project and the drive root.

Paket resolves from nuget.org although nuget.config is correct. Paket does not read nuget.config. Check the source lines in paket.dependencies, and re-run dotnet paket update if paket.lock predates the change.

Stale metadata after switching sources. dotnet nuget locals all --clear for a full reset.

File not being read. Confirm the file is in the project root or %APPDATA%\NuGet\, and that its name is exactly nuget.config.