Just an update.. we have officially scheduled engineering resources to study/research/proof-of-concept a PyPi feed in late April (week of 23rd to be specific). Once that's complete, we will know exactly how easy or difficult it is.
Most likely, it will be very additive, and we won't need to tie it to a specific release schedule, as we could realistically include it in any maintenance release.
This is a results of network connections and traffic, and the message is coming from IIS or the ASP.NET hosting components. The server hardware itself is fine, but there's not enough network bandwidth to handle the load.
Keep in mind that your clients (NuGet, npm) will make hundreds (sometimes thousands) of simultaneous requests to the ProGet server to just a single "package restore". These requests are "expensive" and time-consuming, because often they'll need to check with a remote connector (which opens a new connection), backend database (network connection), validate security, etc. In addition, the workstations are typically more powerful than the server, so they will have more resources to make these requests.
So it really only takes a handful of users doing simultaneous package restores, and you are basically at a "denial of service" level of traffic. So, in this case, load-balancing is the way to do it.
This was introduced into 5.8; so please update to the latest v5.
Actually, the API isn't really any faster or slower.
If you find it faster to query NuGet.org's "v3" API endpoint, the reason is that it's a static index hosted on a massive Azure server farm. Your ProGet server is considerably less powerful. In addition, ProGet has connectors, authentication, package filtering, etc., and it would never be feasible or useful to generate a static index like NuGet.org does.
However, it is on our 2019 roadmap to implement this API, possibly as a new feed type or as an alternate API endpoint for an existing feed. But even so, if you need performance, you may still need likely need to stand up several ProGet servers in a load-balanced manner.
See How to Prevent Server Overload in ProGet to learn more.
The Integrated Web Server doesn't have many features, including request logging and tracking. So in this case, you'll want to upgrade to IIS:
Please refer to KB#1013: Hosting Through IIS Instead of the Integrated Web Server
This is not supported in ProGet, primarily because it's only useful in rare situations like this. But you can easily accomplish this in IIS by enabling logging, and then checking the corresponding the time of the ProGet error logs with the IIS logs.
It sounds like you don't have ASP.NET enabled as a role on your Windows server. The installer should detect it, but that checkmay have failed. Hard to say.
In the Server Manager feature of Windows, make sure to select ASP.NET 4.5 (or whatever the latest version is), by expanding the Application Development node.
It's hard to say, because we don't have enough information. The "code" you shared looks like it's part of a PowerShell script, or maybe it's a cmd script, which maybe they're executing from BuildMaster? Or they could be executing the process directly? Where does $targetInstances and $targetDatabase come from?
if they're just running a PowerShell script, then I guess they should just edit that powershell script as you suggested?
Can you just ask for the deployment plan? Unless it's v4 or earlier, it will be in OtterScript (a text file), and once you see it, it should be fairly clear how to change it.
This is likely the way that your client has it configured.
While there is support for Database Changes, BuildMaster does not use sqlcmd.exe to run these scripts, but instead lets you specify such options in a connection string.
However, I think your client is instead executing sqlcmd directly, using the "execute process" operation or something like that. So, you can probably fix it by checking the deployment plan where the scripts are actually run, and recommending they edit it.
Please have your colleague follow the instructions in Source and Symbol Serving; it's easy to miss one small detail, and then in this case, it won't work.
Please share the full stack trace / message under Admin > Message Center.
Unfortunately there is simply no workaround possible in the code; the mono bug fix you saw allows us to work-around another long-standing bug. After Microsoft publishes a new Mono/Docker container image, we can incorporate that into a ProGet release.
However, as a workaround, you can publish to a drop folder, use an earlier v4, or the Windows version of ProGet.
The Jenkisn Plugin can only be used to upload Universal Pakages to a Universal Feed.
You'll need to use Powershell-Publishmodule command to publish to ProGet.
What feed type? If you are using NuGet, make sure it's not a legacy nuget feed.
Does it work with http://localhost:8626? I don't think the standalone web server does its own TLS.
The NuGet library is definitely coming! Actually we wrote one for use in Romp, and will just ship that. We'll publish as a pre-release, and once we get it properly documented and whatnot, ship it. But it's fine to use now (the code is really simple).
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