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.

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.

Hello Steven, Try visiting this page in a browser: http://<ProGet hostname>/feeds/<feed name>/NuGet.Frameworks/4.7.0-rtm.5148 There should be an error message like this: The version number provided is invalid, but would be valid if this NuGet feed were migrated to SemVer2. You can migrate a legacy NuGet feed to SemVer2 by clicking the button at the top of the feed management page.

This error message is coming from the NuGet client, and it's regrading your server's SSL configuration. Unfortunately I don't have enough information about your server or network configuration to tell you how to begin troubleshooting, but if you search that error, you can find lots of tips on how to ensure you have certificates set-up properly, etc.

If the package does exist, and you can download the package from the ProGet UI, then it indicates that there is no problem with ProGet. The UI uses the same download URL, and whatever is shown in the UI will be shown in the API. To further troubleshoot, I recommend you to use Fiddler and trace the HTTP requests. You can also inspect the ProGet message center to see what error requests are being made tot the ProGet server.

Turns out I needed to migrate the feed to the "new format" that supports semver. Everything worked like a charm afterwards. Thanks

For the Windows service, the only requirements for the service account are (assuming default file system package store configuration) read/write access to the directory where the underlying packages are stored (default is in ProgramData), read/write access to the service installation directory (default is in Program Files), and granted access to the ProGet database role named ProGetUser_Role. For the web application (Windows service or IIS application pool identity), the requirements are the same as the Windows service, plus read/write access to the website installation directory. Note again that the Desktop Hub installation privileges is orthogonal to the account that ProGet runs as, since it would obviously require more privilege to create/update/grant in the database and also create subfolders in Program Files & %ProgramData%. As an extra word of caution, if D: is a mapped drive, be sure to use the full UNC path in configuration settings within ProGet.

Thanks for the clarification. Unfortunately I can't mention any commercial products because the site this will be published on requires that commercial products be sponsors of the site. Unless Inedo wants to be a sponsor for 4sysops ;-)

I see what you mean. Though in this video the suffix is used for dev versions or release candidates. But I guess we could (ab)use this for branches. Will try and see how it goes.