Did the multi-part API get implemented for universal packages? This is still an issue.

Hey Steve, Seems something was stuck somewhere, I re-created the resource and reset the service and now I can connect. Cheers, Justin

Hi, seems like we're dealing with a loopback issue on the IIS itself. Pushing from other servers on the network works. Thank you! :)

Hi @pariv_0352, Thanks for clarifying; looking closer, ProGet requires that X-Forwarded-Host is simply a hostname. You're right, there is no "standard" for this, but that's what ProGet does for the time being.. and if the input is invalid, then you get the error you'll see. I would change your reverse-proxy header configuration to: X-Forwarded-Host: www.testdomain.com X-Forwarded-Port: 82 Hope that helps, Steve

If you're looking for nuget.org-specific metadata, I recommend querying nuget.org directly; of course if you need to work-around internet access issues, you could configure a special feed/connector with no caching. But if you're looking for latest version of a package, the registration API is your best choice. That's what Visual Studio (NuGet client) does for every package and dependency, every time a restore happens.

hi @msmith_2315, Oftentimes, this is related to a database backup that's occurring; if you change the database recovery model to SIMPLE, this generally makes backups much quicker. It could also be related to a scheduled job; you can see which scheduled jobs ProGet is running by going to Admin > Scheduled Jobs. There are logs, and you can see execution times, etc. Cheers, Dean

Hi @aivanov_3749 , I'm afraid the reply is the same :( ProGet 2023 is effectively a new database architecture entirely, and while we tested every possible scenario we could imagine (as well as dozens of customer databases), some regressions are to be expected. It's also possible that there was a bug or edge case in the old retention rules, and the packages that should have been deleted weren't/ Upgrading to ProGet 2023 will automatically disable all retention rules on all feeds, and you'll be prompted to attempt a dry run before re-enabling them. The best way to troubleshoot retention rules deleting unexpected packages is to use the "dry run" feature. This will let you tweak the rules, and find which setting is behaving unexpectedly. If you can let us know specifics or provide those execution logs, we will definitely do our best to identify the underlying cause. Thanks, Steve

Hi @rosario-digiovanni_1930 , In an ideal environment, when a user is logged into a domain-joined Windows workstation, then Visual Studio or Edge/Chrome should never prompt the user when WIA is enabled. This applies to ProGet, or any other site/webapp that uses WIA. However, there are many things that can go wrong, and cause WIA to break. Even something as simple as an out-of-sync clock on a workstation. We've written some docs that try to explain how WIA works and give some tips on how to troubleshoot the issue: https://docs.inedo.com/docs/various-ldap-troubleshooting#integrated-authentication-not-working My personal opinion is that WIA was designed for a time before password managers and when everyone worked in an office without VPN. You may find it just not worthwhile to use. NOTE: you can still use your domain credentials (i.e. Active Directory / LDAP), but users will just be required to enter them into ProGet. They can use an API key inside of Visual Studio. Cheers, Steve

@v-makkenze_6348 said in Reporting & Software Composition Analysis (SCA) shows many unresolved Issues: I repackaged the Owin package but didn't relalize that that would break all my builds as the dll's are now in a 1.0.0 folder where all the project files expect them in the 1.0 folder. I guess this would work if the projects are in sdk project format but most of them are not. Unfortunately, a consequence of those quirky versions. Hopefully it won't be too bad to update those projects/references with a bit of search/replace :)

@guyk thanks for letting us know; unfortunately this would require a substantial change to the way we handle authentication on connectors; if we see more of this down the line we'll definitely consider it further :)

The Web-BaseUrl setting did work! I have removed the proxy_set_header directives in my Nginx configuration. PS:\>install-module mranagios -Repository powershell-internal -Verbose VERBOSE: Suppressed Verbose Repository details, Name = 'powershell-internal', Location = 'https://proget.domain.com/nuget/powershell-internal'; IsTrusted = 'True'; IsRegistered = 'True'. VERBOSE: Repository details, Name = 'powershell-internal', Location = 'https://proget.domain.com/nuget/powershell-internal'; IsTrusted = 'True'; IsRegistered = 'True'. VERBOSE: Using the provider 'PowerShellGet' for searching packages. VERBOSE: Using the specified source names : 'powershell-internal'. VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'. VERBOSE: The specified Location is 'https://proget.domain.com/nuget/powershell-internal' and PackageManagementProvider is 'NuGet'. VERBOSE: Searching repository 'https://proget.domain.com/nuget/powershell-internal/FindPackagesById()?id='mranagios'' for ''. VERBOSE: Total package yield:'1' for the specified package 'mranagios'. VERBOSE: Performing the operation "Install-Module" on target "Version '1.3.2' of module 'MrANagios'". VERBOSE: The installation scope is specified to be 'AllUsers'. VERBOSE: The specified module will be installed in 'C:\Program Files\WindowsPowerShell\Modules'. VERBOSE: The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'. VERBOSE: Downloading module 'MrANagios' with version '1.3.2' from the repository 'https://proget.domain.com/nuget/powershell-internal'. VERBOSE: Searching repository 'https://proget.domain.com/nuget/powershell-internal/FindPackagesById()?id='MrANagios'' for ''. VERBOSE: InstallPackage' - name='MrANagios', version='1.3.2',destination='C:\Users\admin123\AppData\Local\Temp\2\889763007' VERBOSE: DownloadPackage' - name='MrANagios', version='1.3.2',destination='C:\Users\admin123\AppData\Local\Temp\2\889763007\MrANagios.1.3.2\MrANagios.1.3.2.nupkg', uri='https://proget.domain.com/nuget/powershell-internal/package/MrANagios/1.3.2' VERBOSE: Downloading 'https://proget.domain.com/nuget/powershell-internal/package/MrANagios/1.3.2'. VERBOSE: Completed downloading 'https://proget.domain.com/nuget/powershell-internal/package/MrANagios/1.3.2'. VERBOSE: Completed downloading 'MrANagios'. VERBOSE: Hash for package 'MrANagios' does not match hash provided from the server. VERBOSE: InstallPackageLocal' - name='MrANagios', version='1.3.2',destination='C:\Users\admin123\AppData\Local\Temp\2\889763007' VERBOSE: Validating the 'MrANagios' module contents under 'C:\Users\admin123\AppData\Local\Temp\2\889763007\MrANagios.1.3.2' path. VERBOSE: Test-ModuleManifest successfully validated the module manifest file 'C:\Users\admin123\AppData\Local\Temp\2\889763007\MrANagios.1.3.2'. VERBOSE: Validating the authenticode signature and publisher of the catalog file or module manifest file of the module 'MrANagios'. VERBOSE: Catalog file 'MrANagios.cat' is not found in the contents of the module 'MrANagios' being installed. VERBOSE: Checking for possible command collisions for the module 'MrANagios' commands. VERBOSE: Module 'MrANagios' was installed successfully to path 'C:\Program Files\WindowsPowerShell\Modules\MrANagios\1.3.2'. Thanks again, Espen Blikstad

Hi @atripp, Thanks for the response! It turns out I was overlooking the fact that the docker container cannot access the files of the host. So the directory was non-existent from the perspective of the ProGet instance. I ended up solving the issue by copying my bulk import directory into the docker container itself, which allowed the bulk import service to detect the directory.

Hi @Justinvolved, You can create Global pipelines and scripts, which you can then use across applications. You can see this in action here, in one of our extensions: https://buildmaster.inedo.com/applications/18/scripts/all?global=False Click on "Global (shared)" to see all the scripts. Same is on the Pipeliens page. Cheers, Alana

Hi @chrisblankde, Can you please tell me what metadata you are trying to update? If it is just the version, you can use the Repackage API. If it is something other than the version, in ProGet 2023, we added the ability to edit the upack metadata directly in ProGet. You can do that by navigating to the package version in your universal package feed and then click "Edit Package" in the upper right corner. If neither of those options works for you, then what you suggested (download/extract/edit/repack/upload) would be the way to handle this. Thanks, Dan

@stevedennis Thank you!

Great to here it will be resolved soon. Thanks.

Hi @chuck-buford_5284 , Thanks for letting me know; can you let me know what queries were deadlocked? We shouldn't see any deadlock, but I guess it'd be possible for SELECT * FROM [NuGetFeedPackageVersions_Extended] to deadlock on itself depending on the query plan sql server uses. There are a few other things we can try, but we can't repro this at all, even in a test lab that's just hammering the database. Are you using SQL Server Express (i.e. what Inedo Hub installs by default)? It should work the same of course... Caching packages use that "CreatePackage method", so it's basically the same thing as installing a package I suppose. Cheers, Alana

Hi @PMExtra , Looks like this didn't make it to the 2023 codebase; I've just merged it in via PG-2388 (shipping this friday in ProGet 2023.8). Cheers, Alana

@mness_8576 thanks! We definitely welcome feedback on the UI/UX - this is a new feature, so there's a lot of room to improve :)