I presume you have "Integrated Windows Authentication" enabled. When this is the case, IIS will issue 401 before the request ever comes to ProGet.
In this case, the client must support it. PowerShell does, but you must explicitly advise credential use with the "UseDefaultCredentials" flag.
Invoke-RestMethod
-Uri http://srv-proget/vsix/[vsixapi]
-Method Put
-InFile [vsix]
-Headers @{"X-ApiKey"="[api key]"}
-UseDefaultCredentials
I don't believe curl will support this.
API Keys are required for all of our end points. This is by design, because API and interactive (user) access are quite different, and they resolve access differently.
If you want to not use an API key, you could create one called "dummy" and always pass that in the URL; however that's not recommended, because it's like a password.
In this case, WIA is only used to "authenticate" the request, not authorize it.
ProGet's Universal Packages and Feeds certainly support full SemVer2.
If you're designing modern delivery processes but are still planning to shoehorn your applications into NuGet packages (i.e. meant for .NET DLLs), you really ought to consider fixing that as well. We also released Romp which extends universal packages, and gives some nice deployment options as well.
That being said, NuGet feeds and packages have whole lot of quirks (e.g. 0.01.0 != 0.1.0, etc) that make SemVer2 nearly impossible to implement without some major breaking changes. NuGet.org had a lot of problems too when the quasi-supported it in the client. So we're planning on making those changes in ProGet v5, which is scheduled for November.
Is it a "Portal PDB"? This is the new format and is not yet supported.
If not, then the next step would be for you to submit a ticket with the NuGet package attached so that we can debug the pdb parsing.
You'll want to make sure that extension directories are configured (Admin > Extensions), and the InedoCore extension is in the extensions folder. This is what contaisn the user directories.
You will need to open both ports; the npm api uses both HTTP and HTTPS.
We do, however there were some problems with the postgres code; we are currently still testing and will push an update as soon as available,.
In this case, the symbol file may be corrupt or otherwise not readable. Hopefully rebuilding the symbol file will work.
The most common scenario for this is that ASP.NET 4.5 is not installed/enabled on IIS, which is causing our application code not to be executed at all.
Note that it must be ASP.NET 4.5, which is a separate role/feature than .NET.
Note also that you may only have .NET 4.6 available as a feature; that's also OK, since it replaces .NET 4.5.
Hi Travis; thank you for the very detailed write-up.
Basically it would seem that, in any situation, a 403 is issued when you try to push a NuGet package?
In this case, it's likely that something is intercepting the request and issuing a 403. I think that a "nuget push" does a PUT, which is often blocked by things like WebDAV. So I would make sure it's disabled, and that the load balancer isn't disabling it.
This is definitely on our roadmap; stay tuned!
This is the first request for such a feature; after v5 ships, we may consider putting this on the roadmap as a feature, depending on if anyone else requests it.
These sorts of features may not be worth doing, because they are added complexity, more things to test, and only save a little bit of time during initial set-up.
It's not clear when that error is occurring, but
You can use your same license key in this case, it's no problem! The licensing agreement for BuildMaster and Otter explicitly permit dedicated dev/test instances.
ProGet requires a separate server... but if it's just a temporary migration then it's also OK too.
This is OS & .NET Framework dependent.
Many users have reported that setting the follow registry will resolved this issue:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
Value: SchUseStrongCrypto
Data: 1
Note that this will involve a reboot. See this guide on TLS in .NET for more information