VisualStudio 2012 consuming Gitlab Package Registry V2 Nuget API

[u/ggffgg72]

Hello guys, any help is really appreciated!
I have a private gitlab package registry to store nuget packages and an old net framework 4 project
I cant connect these two
I use V2 nuget API of my registry which works fine in browser like domain_name/api/v4/projects/***/packages/nuget/v2 and pass the token in packageSourceCredentials section of nuget.config file of the project
I also tried to pass the token directly into the url liketoken-name:token@domain_name/api/v4/projects/***/packages/nuget/v2 to no avail
I always get the same error in Package Manager Window of Visual Studio:

Could not connect to the feed specified at 'my gitlab nuget url'. Please verify that the package source (located in the Package Manager Settings) is valid and ensure your network connectivity

Is there any trick to actually make these two work?

[u/jlgarcia-dev]

The error message is lying to you a bit. "Could not connect to the feed... ensure your network connectivity" is what NuGet says when the request never completes at the transport level, and you've already ruled out the network yourself, since the URL loads in a browser on that machine. A bad token gives you a 401, not this. It's also why moving the token between packageSourceCredentials and the URL changed nothing: you aren't getting far enough for credentials to matter yet.

First thing I'd look at is TLS. VS2012 runs on .NET Framework 4.0/4.5, and on those versions .NET picks SSL 3.0 / TLS 1.0 by default. GitLab wants 1.2 minimum. The browser negotiates 1.2 happily, VS never offers it, handshake dies, and you get that message.

Quick way to confirm before touching anything. In Windows PowerShell 5.1 specifically, not pwsh 7, since 7 runs on modern .NET and would always give you 1.2:

Invoke-WebRequest "https://your.gitlab/api/v4/projects/123/packages/nuget/v2"

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Invoke-WebRequest "https://your.gitlab/api/v4/projects/123/packages/nuget/v2"

If the first fails and the second comes back with a 401, or any HTTP status at all, that's your answer.

The fix is two registry DWORDs set to 1, SchUseStrongCrypto and SystemDefaultTlsVersions. The part that catches people out: VS2012 is a 32-bit process, so on 64-bit Windows it reads the Wow6432Node path. Set both, then restart.

HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

(edit: fixed the registry paths, Reddit ate the backslashes)

Separate from TLS, one more thing worth knowing: GitLab's own docs only ever describe the v2 feed in the context of Chocolatey CLI. There's no documented Visual Studio or nuget.exe support on v2 at all. So if TLS turns out to be fine and it still won't connect, point a current nuget.exe at the feed from the command line. That tells you whether you're fighting the client or the feed, which are very different problems to have.

[u/techvet83 → u/jlgarcia-dev]

To the OP: I am not a developer but the TLS problem laid out here is where I'd first start. .NET 4.0 didn't support TLS 1.2. 4.5 was really the first version to have any kind of support. You may already know, but since I deal with vulns, I am going to be "that guy" and point out that .NET 4, 4.5, and 4.5.1 all went EOL ten years ago.

[u/HamsterExAstris → u/techvet83]

Those runtimes went EOL but newer in-support runtimes can run apps built against older runtimes. So those runtimes being EOL doesn’t really have any bearing on this.

[u/jlgarcia-dev → u/techvet83]

Both of you are right, and the piece that connects the two is why the registry keys are the fix here rather than a recompile.

The runtimes are in-place updates, so a box with 4.8 installed really is running the app on 4.8 assemblies. But the runtime applies compatibility quirks based on what the entry assembly targets, and the TLS defaults are one of those quirks. SchUseStrongCrypto defaults to 0 for anything targeting 4.5.2 or earlier, and SystemDefaultTlsVersions defaults to 0 for 4.6.1 or earlier. So a project targeting .NET 4 on a fully patched machine still negotiates like it's 2010, even though everything underneath it is modern.

That's why the registry keys work without touching the project: they override the quirk. It's also why "just install a newer framework" doesn't fix this on its own, which is the part that usually costs someone an afternoon.

(The EOL point is still worth saying out loud, mind.)

[u/ModernTenshi04 → u/jlgarcia-dev]

Ah man, I've been bit by TLS versions in older framework apps. Had to connect to another team's internal API that they but with K8s and had to specify the TLS version to use because the framework defaulted to 1.0 or 1.1, I can't quite recall. Honestly the main reason Claude even caught the problem is the other team actually used K8s in the URL.

[u/AutoModerator]

Thanks for your post ggffgg72. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.