This particular issue just means that the web server and service cannot communicate; doesn't have much to do with VOR SECURITY, and you can simply resolve it by restarting the web/service.

To resolve this on our end, I had to use local paths to the extension folders instead of relative in the Advanced Settings page. I was hoping to use relative in our 3 web node NLB environment.

The /symbols/feed giving a 404 is an expected result; when you visit the page, you will get a 404, but also see instructions on how to configure visual studio. Unfortunately we're not able to reproduce this "unable to check the enable box" error, nor have any idea what might cause it. It's a simple page that sets a flag in the database.

I'm guessing that you're referring to this from the docs. I'll give it a try. ...Feed API key authentication is performed using HTTP basic authentication. To authenticate using a Feed API key, supply "api" for the user name and the API key for the password. feed api keys

Very nice to hear that. Thanks Alana.

Hi Ken, Thanks for contacting us. We are aware of this issue and have traced it to be a bug in a database script, that only affects Linux. The good news is we already have issued a fix for the problem (https://inedo.myjetbrains.com/youtrack/issue/PG-1101), it just needs to be reviewed and tested.

This would require feed-scoped privileges, which is a paid feature. See Features by Edition for more differences.

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.

Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md Unfortunately at this time we don't have a timetable for if or when this gets implemented, but it is on our list.

The ProGet server doesn't modify packages, except to strip embedded symbols and source code if that option is enabled on a feed. It certainly doesn't modify a package such that the folder structure is flattened. Are you certain the package isn't flattened on the server, and in addition to that, actually being downloaded from ProGet at all (versus the NuGet cache or something like that)?

That's great news. Thanks!

You will need to open both ports; the npm api uses both HTTP and HTTPS.

You can use the following docker command: docker rmi tag-name

Thanks. I was able to resolve this by running the full 4.8.2 installer which appeared to have a minor DB schema change. Once the DB was updated by the installer, ProGet was able to load from the web nodes when updated to the 4.8.2 binaries. I wish there was better documentation on updating ProGet in a NLB enviroment when there are updates to the DB.

Hi Tod That is great news +1 Thanks for the very fast reply and hotfix release, which i look forward to. For now we have stabilised by loading a backup of our Proget server, rolling back to 4.6.7 so we are good for now :-D Regards Thomas

This was a regression: https://inedo.myjetbrains.com/youtrack/issue/PG-1085 We will have a maintenance release out today to fix this.

Hi Travis, thank you for the additional update. I was very confused by this as well... the problem is the documentation that says if "LDAP" is enabled... it should say "if Integrated Authentication is enabled then the API key is ignored". When those docs were written, those 2 were 1 in the same. I guess the whole point of this is to never use a feed "NuGet API key" since it duplicates what the "ProGet API keys" already do in terms of authentication.

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.

Just to clarify, .NET PDBs with "full" debugging information (i.e. Windows PDB format) are supported, it is just .NET "portable" format that is currently not supported. Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md Unfortunately at this time we don't have a timetable for if or when this gets implemented.