Thank you for the report - it appears the uninstaller is relying on a configuration value that does not exist; the uninstaller will be fixed in v5.0.8. For reference, here is a quick summary of what the uninstaller does: (IIS only) delete ProGet application pool (IIS only) delete ProGet website stop & delete INEDOPROGETSVC and INEDOPROGETWEBSVC Windows services delete %ProgramFiles%\ProGet directory delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ProGet hive from registry (optional) drop ProGet database (optional, SQL-install only) uninstall SQL Server 2016 from "Add or remove programs"

This will be fixed as part of PG-1204 in v5.0.8 - due out early next week.

Apparently this "works" if you do: IIS::Ensure-AppPool Test ( Runtime: "", Enable32BitAppOnWin64: true, Pipeline: Integrated ); Might be better to do something like: set $NoManagedCode = ""; IIS::Ensure-AppPool Test ( Runtime: $NoManagedCode, Enable32BitAppOnWin64: true, Pipeline: Integrated );

This is a "false positive"; https://inedo.com/support/kb/1113/anti-malware-false-positives-code-signing-and-safety-of-inedo-products Please report it to Cylance

You can uninstall, then reinstall. If you follow KB#1013, and make sure to keep the application pool and websites names as specified, then the installer will detect them next time and upgrade as needed.

The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue: https://inedo.myjetbrains.com/youtrack/issue/PG-1203

The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue: https://inedo.myjetbrains.com/youtrack/issue/PG-1203

The issue is related to packages missing SHA1 hashes in the ProGet databases; at some point packages were able to be added without them. We have updated the migration process internally to perform them if they are missing, and this fix will be included in the next maintenance release. Here is the tracking issue: https://inedo.myjetbrains.com/youtrack/issue/PG-1203

Hello Leandro, Feeds_GetLicenseUrls hasn't existed since 4.7.0. It's possible that the error you encountered was from a custom extension which is not compatible with 5.0. ProGet 5.0 uses the Inedo.SDK NuGet package instead of the Inedo.ProGet.SDK NuGet package, and loads extensions that end in .inedox instead of .progetx.

Thanks for letting us know; we've since fixed the regression in v5.0.7.

Hello Phil, This appears to be a bug where NuGet packages with no stable versions keep their first-uploaded version as the "latest". I've filed PG-1201 with a fix. As a workaround, uploading a version of the package with a version number that does not include a hyphen (with a lower version number than the actual latest version of the package) will make the latest version update correctly.

Thanks Dean, the images are available now.

First and foremost, an InedoAgent will respond to any request with the proper AES encryption token (like a password), so if you don't want BuildMaster talking to a server/agent, then don't configure a valid connection to that agent. Are you connecting your Standbox server to the same SQL SErver database? This is a big problem, don't do it... ** Never have two instances of buildMaster talk to the same database ** Are you restoring a database back up to sandbox? It's strongly not recommended, because of the problem you describe. The agents will be configured to talk to eachother. Instead,, when setting up a sandbox, create a representative and testable version of your applications and processes. /you'll never be able to get a "perfect test" (since you can't talk to exact same servers), so at best you should test the broad functionality instead of the connectivity.

The Execute SQL Operation will only capture output specitically printed to the host. To capture the output of select statements, you might want to use a tool like "isql.exe" instead, that prints the results of a select statement to the console.

That's not a known bug. It's really hard to say; the function should work, and an error should be logged if it's not deleting. You may find errors in Admin > Erros.

hi Markus, you should be able to put credentials in your Connector. Then you should be able to connect.

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database. The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

It looks like this is just an oversight on our part, because the unlisted package is the latest version. I've logged this as PG-1194 and scheduled to fix in a maintenance release.

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

Manage Pipelines cannot be scoped to an environment, because pipelines are not associated with an environment. They deploy to a series of environments. you can restrict deployment to environments. You can restrict editing of configuration file instances to a particular environment, and as long as that configuration file is associated with an environment.