Hi @Justinvolved , You should be able to see some kind of error message on Windows Event Logs, but my guess is that the account doesn't have access to the BuildMaster SQL Server database .. you'll need to grant that. Cheers, Alana

Hi @rhessinger , Verbose doesn't have much details, all "Capturing files..." messages. I changed buildmasteragent root directory and its working now, so as you said it might be something at OS level. Thanks.

Hi @jw , Ah, I can see how that would happen; I logged this as PG-2425 and we'll try to get it fixed in the upcoming maintenance release. Steve

Hello, This is most likely related to PG-2395 (ProGet 2022.30 fix) and PG-2390 (ProGet 2023.9 fix). We added support to handle when OSS Index removes vulnerabilities from their list. Unfortunately, this has brought to light the unreliability of the data returned from OSS Index. It looks like vulnerabilities are constantly removed and re-added, which caused assessments to be cleared out on vulnerabilities. In PG-2395 and PG-2390, we have updated ProGet to only add a comment if we see that OSS Index deleted it. This way the assessment is not lost when OSS Index removes the vulnerability. Thanks, Rich

Hi @caterina , This behavior is intentional, but not ideal. It should only navigation - such as the "Usage & Statics" page on a package, or the "List Projects" page which has a "Latest Release" column. As long as the Release is active, you'll still see new issues come up. That's really what determines if a release is scanned or not - Active or not. The reason for this... an SCA Release's "Release Number" is a free-form field, which means there are no sorting rules. So we can't practically/easily determine what the "highest" number. Instead, we just use the order in which it was created for display purposes. Thanks, Steve

Hi @falam_3608, That's great to hear. The will also be released in ProGet 2023.11. You will not need to roll anything back upon the next upgrade, InedoHub handles these automatically. Thanks, Rich

Hi @bardmorgan_7142 , That error seems to be a UI-related error with the Build Script Template editor. Basically that __ahempty value is meant to trigger a validation warning to force you to pick a package source. When you edit the build script, what do you have set for the package source drop-downs? It should be a ProGet feed, at least for publishing. But it's not required. Also, if you "Edit As OtterScript", you should be able to see where the __ahempty is being added to the script, and hopefully fix. Seeing taht would help us debug it :) Cheers, Alana

I'm pretty sure it's just due to Microsoft SQL's CLI cutting off the XML output @atripp, as the XML object would just be unfinished when viewing in my terminal. I'm gonna whip together a quick CLI to try to pull it out programmatically later today, and then I can let you know if it all works. I'm quite confident that's what's been causing my issue though.

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