Just to be clear... you can't go from Windows >> Linux, because it's PostgreSQL vs SQL SErver. But if you're already on Linux edition, you can just upgrade the container; the database files and package stores are already configured to point outside the container.

You can request a free key at https://my.inedo.com/

We believe we have fixed this as PG-1377, which will be included in ProGet 5.1.11. Thank you!

I'm afraid I don't really understand the requirements for what you're trying to accomplish... Here are the differences between the two extensibility points: A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic. A Package Access Rule Allows for rules to block downloads of packages based on additional logic. The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

It is a working feature, but there are some known issues (PG-1343 and PG-1344) that we will have fixed soon. You can find the documentation here.

Hello, Just following up: The root cause of Windows images from connectors not working is that ProGet was not telling the connector that it supported v2 manifests, and the v1 manifests generated for Windows images by Docker Hub are broken. This is PG-1351.

The tracking issue for this is here: PG-1337

Of course, modifying a package file (i.e. stripping symbols/source) will cause the hash code to change, which is what the integrity check uses. There's no way around that. The stripping feature is important, because Visual Studio will not use a symbol or source server if the package has embedded symbols in it. You aren't supposed to put these in a nuget.org package, but some people clearly do (as the example above). So, just pick which is more important to you.

The problem comes from the anonymous user, after allowing anonymous users to publish on the proget server it works Sylvain

What errors are they getting? Almost all non-certificate-related issues with HTTPS are related to forcing TLS v1.2 support. See this thread for more information and a resolution: https://inedo.com/support/questions/8831

Basically the error message is saying that the client (it appears, your web browser) cancelled the request halfway through completing it. You can reproduce it by, like requesting the URl and quickly closing the browser, or hitting back button, or something. It could also be intermediate equipment that cancelled the request, too. Basically the error means that the response could not be sent because the server can no longer talk to the client(browser). There's no other information that the web server (IIS, in this case) can know. It's not uncommon for a loadbalancer to do this, and you can generally ignore this error in the diagnostic center.

Hi Martin, Thanks for reporting this problem. We do make the standard (old) installer available as well so it can be used in case of bugs like this with the new one. We will issue an update for InedoHub to fix this, but for now you can still use the old installer (available here under the "Traditional Installer" links).

There is an ountstanding feature for this, and you can follow the progress here: PG-1331

The problem was solved when remove dash from package name.

"Windows Authentication" is built in to Windows (web server), and is happens below the application layer (i.e. ProGet). It's by design (Microsoft), and the intention is to use domain/service accounts to control access. I'm not sure I see the security hole to be honest, since pushing to a feed isn't that sensitive of an operation. Just don't let these users overwrite/delete packages.

Assuming you don't any server misconfiguration or SQL Server latency issues, then the biggest performance bottleneck tends to be the network. Each client/user will make dozens or hundreds of simultaneous requests, often using machines more powerful than the server, and these requests can be expensive... particularly if you're using connectors... because they have to be forwarded to another server. These requests "pile up" and eventually, the underlying infrastructure can't handle it (IIS, network card, etc), and you start getting timeouts like that. This is where load-balancing comes in, and is pretty important in your configuration as you add users and packages. See How to Prevent Server Overload in ProGet to learn more.

This is a feature of the paid edition of ProGet; once you have that, you can scope security tasks to specific feeds. Otherwise, everything is global.

My workaround for supporting scripts and modules is to essentially trick it. either specify the source and script source with the fqdn version of the url and then a shortversion of the url or, what I do, set up a iis front end for redirect urls. i.e. if your server name was repos and your domain was mycompany.com then you might set source to repos.mycompany.com:8624/nuget/myrepo and set script source to repos:8624/nuget/myrepo You can list and publish scripts or modules to the same repo and find-script will differentiate from within the repo. The more elegant solution, but more difficult, is to create a dummy website with real or virtual paths that use http redirects to the right sight. So you could set your source to something like repos.mycompany.com/source and that folder would redirect to the path on the different port. That's just a quick summary of the workaround, I realize that, I can provide more thorough examples if you would like.

Hello all, ProGet 5.1.7 fixes an additional issue that was causing SemVer2 NuGet packages to fail to download: PG-1329

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.