@atripp said in NuGet no longer works after upgrading to 2024:
Offhand, I believe it's a result of "bad data" (duplicate packages) that are in your database, and it's the same issue behind here: https://forums.inedo.com/post/15730
Hi Alana,
before we run into the same thing, is this by any chance the same "bad data" you mentioned in EDO-10311?
We're in the final stretches of ProGet 2024 now (looks like we're on
ci-27as of this morning); you're welcome to try it, we've been using it for a bit ourselves. It seems to mostly work.
I've been looking into ci-30 a bit, since I had some issues with the SCA API, but it seems they still persist in this version.
https://docs.inedo.com/docs/proget-sca-releases-get
I cannot get the /api/sca/releases?project= to work, I always get some Persisted object is not a ProjectReleaseConfiguration. HTTP 500 error.
According to docs ReleaseInfo does not contain the id, it would be good to have that there. From what I understand the id is needed for the /api/json/Projects_GetBuildInfo?ProjectBuild_Id= API
Few docs issues
releases endpoint should probably be builds now/api/sca/releases?name= is mentioned a few times but the parameter should probably be projectExport SBOM for both formats is still broken for me in this version.
Version number is cut off in the UI
The SCA Events seem quite granular
Do these really fire for every single "noncompliant package", "vulnerability detected" or "issue opened"?
I was hope something along the lines of "Build Added" that fires after a new SBOM was imported, containing the build id, project name and build version
Thanks for squeezing these all into the upcoming release.
On semi-related notes:
Does it make sense to give feedback about SCA 2024 issues for the 24.0.0-ci.5 version, or will there be a RC before the release?
I'm afraid this is a bit too granular for us now, but it's something we can consider re-evaluating down the line, especially as we will likely want to add specialize permissions for projects, policies, etc. We expect that will happen later in the year, after ProGet 2024's new features get more adoption. We'll see if anyone else requests package-level permissions, etc.
Thanks for the feedback, let's see if there is more demand.
As for the Advanced, I put a note in ProGet 2024's final touches to address that. Honestly I thought those were only on Debug builds only, but clearly not... thanks for reporting!
Glad to hear it is just an UI issue, I was worried users could mess with metadata.
Cheers
As of 2023.32 the right to mark a package as deprecated is tied to the Unlist Package permission.
This permission also allows modifying download rules and unlisting, which is not something we want developers to be able to do.
We would like to have a dedicated Deprecate Package permission that just allows that and nothing else.
Thank you for considering.
Also a question:
The text boxes Advanced tab on the Set Package Status popup seem to suggest that publish/download metadata could be changed here, but changing anything has no effect.
What is the intention here? These text boxes should probably not be there?
I think it makes sense to put the SCA 2024 Preview UI feedback in a different post, or this one will get too long.
Here a some of the issues my colleagues reported to me.
Version: 2023.32.
For a user with the following permission set:
/Link leads to 403 page and exception is recorded in admin log.
=> The replication link should be hidden if the feature is not licensed or at least be moved into the admin panel. A user without permissions should never be able to see that link, since they usually have no business configuring it.
/packages and/containersThe bulk edit menu is always visible, clicking on it shows a menu with delete or promote option. Selecting Delete selected results in no action at all, which is misleading.
=> The "bulk edit" link should be hidden for users that do not have delete or promote permissions in any feed.
What might be a bit more tricky to handle is the case when users have local feed permissions. Some feedback to the user about what did or did not happen would probably be a good start.
/feeds/nuget-feed/package-name/1.0.0The Repackage Package and Reanalyze Packge link both lead to 403 pages and exceptions are recorded in the admin log.
=> Both menu items should be hidden
/feeds/nuget-feed/package-name/1.0.0/metadatadetails link causes 403 and exception is recorded in admin log.
=> There should probably be two links "view" and "edit"
View should be available for everyone regardless of permission, since they can just navigate to the file tab and find the embedded license file directly. Edit should only be visible with appropriate permissions.
My colleagues have reported a few issues with the ProGet UI to me. Usually it revolves around them seeing a link or a button but when they click that element, either nothing happens or they receive a 403 error, either in-page or as popup.
From permission point of view this makes totally sense, as they are trying to access resources which they are not authorized for.
I tend to agree with them that from a UI/UX perspective this is a bit annoying.
From what I could gather from the ProGet UI is that the general design philosophy seems to be to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.
Is my assumption here correct and does it make sense for me to report those issues that my colleagues and I have found?
Looks like success!
Thanks for addressing this so quickly. 
Updated my test instance from SQL Server 2016 - 13.0.4001 to 13.0.6435.1, which should be the latest if one ignore Azure features - still no luck.
This is what the activity monitor looks like during job execution. The average seems to be around 900-1000 batch requests/sec. No idea if that is normal or resonable.
Is it always failing with the follow?
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
Yes, the error is exactly this one every time.
Looking over your Prod dates... did you happen to upgrade after 2024.03.14? Or maybe that's when you enabled the preview feature?
The production instance was coming from 2023.29, the .30 was skipped and the .31 applied only on 22.03.
My test instance is a bit tricky, since I did not track when I was updating something or enabling preview features. Inedo Hub says my last installation was on 17.03.2024, so that must have been the upgrade to .31, I was slightly off in my screenshot.
Inedo Hub log does not seem to reveal which version was installed in the logs. Can I find that somewhere else?
Could you try running
sp_updatestatsand cleaning fragmentation on those tables usig SQL Management Studio? Clearly there's something we're missing here...
Just ran the command on my test instance. According to the output nothing was updated. Ran another VulnerabilityDownloader job to double check, but it failed again.
I will now try to patch my test instance (SQL Server 2016) to the latest version and see if that helps in any way.
I have found that my test instance also suffers from the same problem.
Both instances and their SQL-Servers are running on Windows and were installed with Inedo Hub. The only modification that was done to SQL Server is making the instance remotely accessible via TCP.
Hardware should not be an issue, both VMs have 4 (or 8) cores, 8GB RAM and SSD disk space assigned to them.
What is interesting that the error is not actually time related. On my local test instance, that has a more powerful CPU, the same error occurs, but already after 6-7 minutes.
From the execution logs it seems like it is unrelated to a particular version or upgrades and rather some issue that appears over time.
The screenshots below show all available execution logs for the VulnerabilityDownloader. I marked the date when ProGet was updated to to a particular version left in the tables.
Production instance:
Microsoft SQL Server 2022 (RTM-GDR) (KB5032968) - 16.0.1110.1 (X64)
Nov 9 2023 22:31:58
Copyright (C) 2022 Microsoft Corporation
Express Edition (64-bit) on Windows Server 2022 Standard 10.0 <X64> (Build 20348: ) (Hypervisor)
Test instance:
Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)
Oct 28 2016 18:17:30
Copyright (c) Microsoft Corporation
Express Edition (64-bit) on Windows 10 Pro 6.3 <X64> (Build 19045: ) (Hypervisor)
ProGet 2023.31 (Build 5)
Executing the VulnerabilityDownloader job always leads to the error below:
Updating local PGVD index...
Downloading latest vulnerability definitions from Inedo Security Labs...
Download complete. Unpacking database...
Processed 1000 entries.
Processed 2000 entries.
Processed 3000 entries.
[...]
Processed 37000 entries.
Processed 38000 entries.
Processed 39000 entries.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
Update complete.
Few observations:
Initially we thought our anti virus is slowing down things too much, but even after excluding everything ProGet-related this error still appears.
Another somewhat related question:
When a SBOM scan is uploaded, no issues are created initially even though the UI suggests that analysis was done already. One has to run analysis a second time with the issue checkbox set for issues to be populated.
Is this intentional or what is the idea behind that?
I was expecting to get a full analysis after uploading either via API or UI.
I can understand that this is a lot of effort and really appreciate that this request is not discarded right away.
The workaround you proposed is something that I have already looked into myself.
To make this work smoothly, a webhook for SCA events would really be immensely helpful. Is something like that already on the 2024 SCA roadmap?
However, the package metadata should already be in ProGet by the time you upload the sbom. When doing package restores from ProGet, the packages will be cached automatically. If that's not happening for you, make sure to clear your nuget package caches.
Not all packages will always be acquired via the remote restore mechanism, as I eluded to here.
They still should be analyzed by SCA and not show up on SCA as "inconclusive".
For example, I just cannot get the System.Security.Cryptography.Primitives populated in the ProGet cache, via regular dotnet restore. The package is always taken from the local dotnet SDK installation folder.
There are also other cases like these framework packages. We have a number of people working via VPN and for performance reasons they are access nuget.org directly, via Microsoft's CDN, which gives them much better performance. Their restore operations will not trigger cache population in ProGet.
Bottom line, there are plenty of scenarios why a package might not be readily available in the ProGet package cache.
Ultimately we designed the SCA feature is designed to be used in conjunction with ProGet as a proxy to the public repositories. It's not a "stand-alone" tool, so it won't work well if packages aren't in ProGet.
The reason is, if the package metadata isn't in ProGet, it has to be searched for on a remote server. In your sample (one build, two packages), you're right.. it's just a few seconds to search that data on nuget.org. But in production, users have 1000's of active builds each with 1000's of packages... and that *currently * takes about an hour to run an analysis.
That is how every other SCA systems works, that does not have a built-in package server.
Right now we are using DepTrack behind ProGet as a caching proxy. If DepTrack wants to analyze any package it will just pull the information from ProGet, if that package is already cached, great. If that package is not cached ProGet will download it and it will be cached from here on out, zero manual intervention required.
This very same scenario will not work in ProGet without manual intervention by either adding packages on some exclusion list or downloading them manually to populate the cache.
This limitation will always put ProGet SCA in a disadvantage when being compared to other systems.
Adding 100k's of network requests to connectors to constantly query nuget.org/npmjs.org for server metadata would add hours to that time, triggers api rate limits, and causes lots of performance headaches. Plus, this "leaks" a lot of data about package usage, which is an added security concern. This is a major issue with tools like DependencyTrack - they're basically impossible to scale like ProGet.
I agree, this is not how things should be set up. If someone decides to run a setup like this, they are not doing a good job.
ProGet should always be in the middle as a caching proxy and the cache download should only be there to fill the gaps for packages that for whatever reason are not available yet.
I was pleased to see that the license files for OSS licenses are now part of the ProGet database and can be accesses via API, so thank you for that.
There might be a small problem with ill-formed files. I have only verified this for the Apache-2.0 license, but others seem to be affected as well.
Viewing the files from the ProGet UI, there seem to be line breaks missing:
A comparison between what can be downloaded from the ProGet /api/json/Licenses_GetAllLicenseData API vs. what is stored in the SPDX GitHub repository:
https://raw.githubusercontent.com/spdx/license-list-data/main/text/Apache-2.0.txt
Hi @apxltd
Thanks for the response. I will try to not reiterate the cache issue too much, as I have raised it here before
https://forums.inedo.com/topic/3953/proget-sca-missing-package-because-of-nuget-proxy-cache-miss/6?_=1710244266850 and also in my mail about ProGet SCA Feedback to you.
We were really hoping this would be improved as part of the SCA 2024 changes. Both current solutions, either manually downloading missing packages or maintaining exclusion lists seems like a workaround to something that could be fully automated.
I expect this to be one of the first questions my colleagues will ask me, once I introduce them to the SCA features. ProGet should try to do its absolute best to create the most complete analysis possible, even if that means it takes a few extra seconds. All the manual effort that should go into it, should be focused on solving the actual issues, like assessing and fixing vulnerabilities.
Package detection is still a lot hit or miss like in the previous version.
Here are two packages pulled in via nuget.org ProGet proxy, one is detected perfectly fine the other one raised an issue as "Package not in feed". When navigating to both of them they are found and reported with green label (no vulnerabilities or license violations).
What is also a bit confusing is the "inconclusive" label. To me this would mean the state of the package could not be determined, but on the issues package it gives a proper "Package not in feed" explanation. I would expect to see this state here too.
Three closely related issues:
/projects, I get a popup with the following error:(500) Server Error
The DELETE statement conflicted with the REFERENCE constraint "FK__ProjectIssues__Projects". The conflict occurred in database "ProGet", table "dbo.ProjectIssues", column 'Project_Id'. The statement has been terminated.
The button Disable ProGet 2024 Projects (Delete All Builds) does not work
When clicking the button the page reloads, but nothing changes. This might be related to the error above.
**Edit
Just found out it actually works, the builds are removed only the projects stay there, as the button text actually suggests.
I did not find any other menu option to delete a project or a build anywhere in the UI
The only thing I found is the project bulk delete option which suffers from the issue above.
Am I missing something?
Thanks for the update, looking forward to the next release.
When trying to upload a SBOM JSON file create with recent tooling to ProGet 2023.30 (Build 16) the following error is returned:
(500) Server Error
Unsupported specification version: 1.5
Are there any plans to support this spec version?
Famous last developer words: "Changing this one flag can't possibly break anything" 
Thank you for considering
Cheers
We are also interested in README rendering.
I've been looking to find where the project URL is displayed, but were unable to find it. Maybe this could be added aswell?
https://learn.microsoft.com/en-us/nuget/reference/nuspec#projecturl
Also related is the releaseNotes field, that would be similar to README rendering
https://www.nuget.org/packages/Microsoft.Extensions.Configuration/9.0.0-preview.1.24080.9#releasenotes-body-tab
https://learn.microsoft.com/en-us/nuget/reference/nuspec#releasenotes
Essentially we are looking for a way to make changelog information of a given package easily accessible to developers.
I'm looking to enable HTTP to HTTPS redirection in ProGet.
Is this something that could be added?
An option to opt-into this behavior would be very much preferred to having to install another webserver/proxy just to handle this redirection.
Hey @atripp,
Thank you for that snippet, very insightful.
Oddly enough that issue is still on the .NET 8 Planning milestone, even though .NET 8 was already released this November. Ah.. one shall not question Microsoft's planning... ;)
On a server with multiple IPs, I tried to bind ProGet only to one of those IPs with Port 80 and 443 while using the integrated webserver and bind another webserver to the same ports of a 2nd IP.
<WebServer Enabled="true" Urls="https://192.168.0.1:443;http://192.168.0.1:80" Subject="mycert" Store="My" Location="LocalMachine" AllowInvalid="True" />
I observed that for some reason ProGet is using the Kestrel server when the binding a port on all IPs (https://*:443 ) but switches to HTTP.sys when binding a specific IP like I tried with the config above. This can be observed with tools like netstat or TcpView. With Kestrel the ports are held by the application exe itself, while with HTTP.sys hosting the ports are occupied by the System process.
The problem with HTTP.sys-based hosting seems to be, that even though the ports are only bound on one IP, they are also blocked from being used by another process on another IP. Once the ProGet service starts, both ports show up in the port exclusion list netsh int ipv4 show excludedportrange protocol=tcp.
As far as I know there usually is no reason to use HTTP.sys unless specific features are required (see here). Kestrel should also be capable of binding to concrete IP:Port combinations.
Also with Kestrel all these netsh http add urlacl settings don't seem to be required anymore. I made a small test app and I could bind my process to a port below 1024 without urlacls just fine when using Kestrel and running the process as Network Service.
I'd be interested to learn why ProGet is switching between Kestrel and HTTP.sys for these two IP binding scenarios. Also any pointers how to reuse the ports on another IP would be very welcome.
Thank you for the pointers.
I think I finally got it working, though I must admit I'm still not a 100% sure what combination in what order actually led to success.
I'm already in contact with @apxltd about your planned SCA changes. I will try to write up what tripped me as part of that feedback.
Hi @stevedennis
I have this feed feature enabled:
Or are you referring to the SCA setting "Vulnerability Download Blocking Configuration"?
Hi @atripp
I tried what you suggested. Here is the output from the PackageAnalyzer job:
DEBUG: 2023-10-17 11:53:19Z - Fetching list of licenses...
DEBUG: 2023-10-17 11:53:19Z - Found 327 licenses.
DEBUG: 2023-10-17 11:53:19Z - Analyzing 1 feeds...
INFO : 2023-10-17 11:53:19Z - Beginning analysis of nuget-proxy feed...
DEBUG: 2023-10-17 11:53:19Z - Fetching list of known NuGet vulnerabilities...
DEBUG: 2023-10-17 11:53:19Z - Found 0 vulnerabilities.
INFO : 2023-10-17 11:53:19Z - Recorded data for 1 packages in nuget-proxy feed.
DEBUG: 2023-10-17 11:53:19Z - Analyzing 1 active releases...
DEBUG: 2023-10-17 11:53:19Z - Analyzing TestProject 1.0.0...
Sadly, no matter what I do (delete and reupload, overwrite, clicking on "analyze" on the Release), the vulnerability is never shown.
Is there anything else I could try?
Ran into some potential bugs when evaluating SCA vulnerability scanning.
Tested on Version 2023.20 (Build 14)
Saving and reopening this shows:
I've been trying to get vulnerability detection with SBOM scans to work for nuget.org packages, but so far no luck.
Here is an example SBOM that should pop up on any scan:
https://privatebin.net/?ca7ad862057815c8#7WzmrR54i6opxoD37dxaE1X7GS67GfcJ79zEps2BTtaS
Clicking on the package shows that the vulnerability is recognized:
The package is also in the package cache, I've manually downloaded it to avoid this issue.
Yet there is not a single mention of this vulnerability anywhere on the SCA release pages:
Is there something I have missed?
This paradigm "SCA in ProGet only works correctly when a package was previously put in the cache" should be revisited.
There already seems to be functionality in ProGet that can determine which feed provides a package, otherwise this link here /packages/from-purl?pUrl=pkg%3Anuget%2FMicrosoft.AspNetCore.Mvc%402.2.0 would not work. So the feed identification where to get the information from does not seem to be the issue.
Then on the subject of cache. Caches should be something that are fully transparent. If a package is not in the cache or caching is not available, then the required information should just be pulled from the source.
I do not see a difference between someone restoring a package from a feed and an SBOM requiring a package for running a complete SBOM analysis.
It would be really nice if this could be considered as an improvement to the NuGet SCA experience in ProGet. All the parts already seem to be there, they just need some wiring. Doing this externally with scripts or other hackery seems counterproductive to a well-rounded product.
Hello @atripp,
this is a tricky subject indeed.
As for this particular case, we've seen this too - and just found that downloading the package caused the issue to go away, and that was simple enough since there weren't too many packages (just lots of annoying clicking).
While it can easily be resolved by downloading the packages manually, this is just not sustainable in the long run. Packages change, frameworks change and with every change there is the risk of yet another package missing in the cache and someone having to click again.
I don't think we want to have ProGet automatically download/populate the feed with packages, but perhaps a better way to handle this is some kind of rule or ignore setting for missing packages??
And it'd be nice if ProGet automatically shipped with a list of these too. I really can't think of any reason why anyone would ever want a notice of "Microsoft.Extensions.Localization" being missing. Can you?
Ignoring these packages does not seem like a good solution. Just because they are shipped with the .NET Runtime/SDK does not mean they are not susceptible for vulnerabilities, so I would rather have them being treated as regular packages with full vulnerability scanning etc.
This is probaly something unqiue to NuGet as opposed to other package managers.
Without knowing enough about the ProGet internals, this seems more like a proxy/caching issue for me. The question I would ask first is why ProGet does need the full package in its cache for the SCA tracking to work correctly.
Maybe some degree of metadata would be enough for that?
Maybe a parameter to SBOM uploading/analyzing could be introduced that enables downloading the required metadata or packages (depending on what is really needed) before analysis is started.
I configured a NuGet caching proxy for nuget.org.
When uploading a sbom.json I noticed that a number of open source NuGet packages are reported as "Missing Package". One such example is Microsoft.Extensions.Localization.
These packages do exists on nuget.org and ProGet is also showing them correctly. The issue is that these packages are never actually downloaded during the dotnet/nuget restore process (in fact, they are never part of the build machine's local NuGet package cache) because the dlls of these packages are shipped together with the DotNet SDK.
ProGet SCA is reporting these packages are missing, because since they were never restored, they are not part of ProGet's proxy package cache.
It is possible to click on each missing package, get redirected on the package page and then hit the download button to populate the proxy cache and this also resolves the missing package issue, but this is very inconvenient.
I think there should be a way to automatically populate the proxy caches when uploading SBOMs.
Am I missing something here?
Version 2023.18 (Build 15)
It also leads to an error in the Logs:
The release itself seems to be deleted though, guess just a proper redirection after deletion is missing.
In 2023.10 the field is populated and the history page shows it correctly.
The $UserName variable for web hooks (tested with Teams integration) still shows Anonymous for the same package though.
I pushed the package via nuget.exe with API key.
Assuming I'm actually looking at the correct column (ProGet.dbo.FeedPackageVersions.PublishedBy_User_Name), in does indeed say "Anonymous".
I've just installed 2023.9 but the upload user is still shown as Anonymous on the history page.
Was this issue addressed yet?
Just installed 2023.2 and .snupkg pushing works again for me, so the original issue is solved.
As for the lost packages:
Tried reimporting all the packages and triggering re-indexing once again. This time it completed cleanly.
Looking in the InedoHub Logs, the last version of ProGet I installed was on 05.03.2023, so whichever version was current at this date is the one I updated from to 2023.1.
I cannot find any ProGet version number in the InedoHub installation logs, which is a bit weird...?
Good to hear.
As for the re-indexing, yes I had the option checked and I also recall that the log was full of warnings that hashes of the packages wouldn't match. After the process was finished the feed was completely void of any package.
Unfortunately I did not save the logs, which in retrospect was no so smart..
Just tested this with another package I had already pushed before - Same exception.
Also, yes, the feed is still configured correctly.
**Edit
Still no luck.
The NuGet package is created on disk, so this shouldn't be a permission problem. The matching .snupkg produces errors and is subsequently missing on disk and also not indexed.
API key is configured for both the package as well as the symbol source URLs.
.snupkg support is enabled on feed.
nuget.exe output:
D:\test>nuget push -Source https://192.168.x.x/nuget/nuget-hosted/v3/index.json SourceLinkTestLib.2.0.6.nupkg
Pushing SourceLinkTestLib.2.0.6.nupkg to 'https://192.168.x.x/nuget/nuget-hosted/package'...
PUT https://192.168.x.x/nuget/nuget-hosted/package/
Created https://192.168.x.x/nuget/nuget-hosted/package/ 231ms
Your package was pushed.
Pushing SourceLinkTestLib.2.0.6.snupkg to 'https://192.168.x.x/nuget/nuget-hosted/symbolpackage'...
PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 67ms
PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 7ms
PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
InternalServerError https://192.168.x.x/nuget/nuget-hosted/symbolpackage/ 56ms
Response status code does not indicate success: 500 (Internal Server Error).
Server log:
System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'.
File name: 'C:\ProgramData\ProGet\Packages\.nugetv2\F1\SourceLinkTestLib\SourceLinkTestLib.2.0.6.snupkg'
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream, String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at Inedo.IO.FileEx.Open(String fileName, FileMode fileMode, FileAccess fileAccess, FileShare fileShare, FileOptions fileOptions)
at Inedo.ProGet.Extensions.FileSystems.DirectoryFileSystem.OpenReadAsync(String fileName, FileAccessHints hints, CancellationToken cancellationToken)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.InstallOrUpdateSnupkgAsync(Stream stream, Nullable`1 publishDate)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.PutHandler.ProcessPutRequestAsync(AhHttpContext context, WebApiContext apiContext, RequestData urlData, NuGetFeed feed)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context)
Thanks for the update, looking forward to the release.
Is there any news on this subject by any chance?
There is updated documentation with step-by-step instructions here:
Thanks for the query, this has indeed fixed the 2nd issue and pushing packages now works without error.
About the 1st issue. Since the source code for nuget.exe is public, one could try to debug this directly in the client, to see what the expectations from a server are.
Hi,
since we're highly interested in this feature, I spend some time trying it out, but ran into two issues.
When only having an API key set for the package feed itself, I get a password prompt for the symbol package.
Pushing SourceLinkTestLib.2.0.0.nupkg to 'https://192.168.x.x/nuget/nuget-hosted/package'...
PUT https://192.168.x.x/nuget/nuget-hosted/package/
Created https://192.168.x.x/nuget/nuget-hosted/package/ 54ms
Your package was pushed.
Pushing SourceLinkTestLib.2.0.0.snupkg to 'https://192.168.x.x/nuget/nuget-hosted/symbolpackage'...
PUT https://192.168.x.x/nuget/nuget-hosted/symbolpackage/
MSBuild auto-detection: using msbuild version '17.4.1.60106' from 'C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin'.
Please provide credentials for: https://192.168.x.x/nuget/nuget-hosted/v3/index.json
UserName:
When also setting an API key for the */symbolpackage URL, this prompt goes away. But according to the Microsoft guy, this should not really be required.
Log message:
An error occurred processing a PUT request to https://192.168.x.x/nuget/nuget-hosted/symbolpackage/: The EXECUTE permission was denied on the object 'IndexedSymbolEntry', database 'ProGet', schema 'dbo'.
Details:
Microsoft.Data.SqlClient.SqlException (0x80131904): The EXECUTE permission was denied on the object 'IndexedSymbolEntry', database 'ProGet', schema 'dbo'.
at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__207_0(Task`1 result)
at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at Inedo.Data.DatabaseContext.DbResult.CreateAsync(DbCommand command, DatabaseContext context, DateTimeOffset startTime, Stopwatch stopwatch)
at Inedo.Data.DatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.SqlServerDatabaseContext.ExecuteInternalAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.Data.DatabaseContext.ExecuteNonQueryAsync(String storedProcName, GenericDbParameter[] parameters)
at Inedo.ProGet.Feeds.NuGet.NuGetFeed.InstallOrUpdateSnupkgAsync(Stream stream, Nullable`1 publishDate)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.PutHandler.ProcessPutRequestAsync(HttpContext context, WebApiContext apiContext, RequestData urlData, NuGetFeed feed)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetApi.ProcessRequestAsync(HttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.NuGet.NuGetFeedHandler.ProcessRequestAsync(HttpContext context, WebApiContext apiContext, NuGetFeed feed, String relativeUrl)
at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(HttpContext context)
ClientConnectionId:ab40b37a-98dc-4cf4-be5d-7ff3ed663d8f
Error Number:229,State:5,Class:14
You're right, caching SourceLink enabled PDBs would be somewhat useless for outages.
Though there are still plenty of "old-school" PDBs around, especially for native code (C/C++).
I've looked at the Event log, but it is pretty inconvenient, since one has to click through all the events to find out which package the log entry is actually about.
It would be nice if my two points from above could make it into v2023.
This together with the support for .snupkg would probably allow us to migrate from Nexus.
Pretty much for the same reason to cache NuGet packages from nuget.org.