Schedule Triggers haven't been replaced; we only really consider those legacy because of the way the variables are handled by them. See also: https://inedo.com/support/questions/9736

Most likely, Visual Studio is trying to talk to nuget.org and other services. You can use Fiddler to see what connections are being made.

According to the Package Markdown Support](https://github.com/NuGet/Home/wiki/Package-Markdown-Support) and Packaging Documentation within the nupkg pages maintained by Microsoft, this is an expiremental work-in-progress and the specs are still in review. I would hope Inedo does not implement anything until NuGet settles on a standard, and this has been a work-in-progress for almost 2 years. So, check with Microsoft :)

Of course, modifying a package file (i.e. stripping symbols/source) will cause the hash code to change, which is what the integrity check uses. There's no way around that. The stripping feature is important, because Visual Studio will not use a symbol or source server if the package has embedded symbols in it. You aren't supposed to put these in a nuget.org package, but some people clearly do (as the example above). So, just pick which is more important to you.

Apologies for the delay, I had to reach out to gather this information. What I learned was that this was a custom operation. Below is the link to its source: Yes, I made that operation to accommodate DSC Configuration scripts (multiple DSC operations encapsulated in a PowerShell script). I had built this on a fork of of inedox-windows. I just merged in the latest changes for the main master (it has been 6 months, so there quite a few changes). I have built it, but have not tested it since the merge. https://github.com/MarkRobertJohnson/inedox-windows/blob/dsc-ensure-config/Windows/InedoExtension/Operations/EnsurePSDscScriptOperation.cs

Make sure to set the Web.BaseUrl setting in Admin > Advanced Settings as well.

We don't have one yet (we're working on the documentation now, expected for the official 5.2 release), but there are examples in ProGet itself for: adding packages: click the Add Package button on the feed overview page after you've added one installing packages: once you have a package in a feed, browsing to it will show you how to install it with pip

Thanks, I've filed this as a bug here: BM-3307

In this case, your best bet would be the backup the database, and then only the package files of that feed. In case of DR, your other feeds wouldn't really work (no package files), but your other configuraitn (usernames, etc) would remain.

Keep in mind that Timeout (or cancellation in general) is not guaranteed, and requires that the task (generally, an operation) properly check for a cancellation token. For example, an operation that simply did a Thread.Sleep for 1000 seconds could not be timed out after 10 seconds. In a case of a stuck execution, restarting the service is the best way to clear things. So, we'd need more context to identify if it's a bug in the operation, or simply something that isn't support.

Thanks for the suggestion, it's handy to know that's possible (with a bit of scripting to move packages into the top level directory). It also seems to work pretty well running the Feed Cleanup under 4.7.14 and then upgrading.

Both of these package types will be supported in 5.2. PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

PyPI support has now been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

PyPI support has been added and published as a pre-release version of 5.2.0. Visit the ProGet Versions page to download, or get it from the Inedo Hub download.

On version 5.1.17 this setting is called Web.BaseUrl

Upgrading to v5 seems to have fixed this

There was an issue (PG-1208) with semantic version-enabled NuGet feeds and retention policies fixed in v5.0.8 - an upgrade should resolve this.

Here are the features by edition: https://inedo.com/support/documentation/proget/administration/license ProGet Free is allowed for companies, however that edition only receives "community support" (i.e. this forum).

Maybe some kind of checkbox in existing UserNamePassword would be a good solution? For example, a checkbox that clearly indicates that these credentials can only be used in PowerShell?

Yes, that is OK, the differences for each edition are outlined here: https://inedo.com/support/documentation/proget/administration/license