I have had issues in the not too distant past, maybe 3-6 months ago upgrading one of my installs of Otter to the latest version, 2.0.9 if memory servers. I would concur that the installs/upgrades could use some love. There definitely should be a 'cleanup' tool to remove all traces of Inedo installs. Ron, I wouldn't give up on using the products. Maybe you can spin up a vm to try this out on as well?

Thanks. That solved it.

Hello Eric, I think Docker requires at least one . in the hostname, and it's trying to access the default Docker hub. Another way that might work would be to add the port number to the hostname: <server name>:443/<feed name>/library/redis (the library part is optional to match the Docker hub, so <server name>:443/<feed name>/redis should also work)

Hello Scott, This is done for 1-part repository names to match the behavior of Docker Hub. You should still be able to access the container without library/; that is, this should also work: <proget_server>:80/<container_feed>/<container_name>:<tag>

Oh I see, you're migrating a legacy NuGet feed! Sorry I misunderstood. With the number of packages you have, a database transaction will put a strain on your database server, which is most certainly where the problem is. Instead, why not back up the database beforehand, then run the migration without verbose logging and a transaction.

Got it! Then this would likely fall inline with an upcoming major feature, and the communication between Otter servers ("main" and "secondary" as you describe) would be done using API/HTTPS/Web requests, in a direction of ("Publisher" -> "Listener").

Basically, you would create a Git-based raft in both instances of Otter, and have them both point to the same Git repository. The biggest gotcha would be that both instances can potentially update the raft, but as long as you're aware of that it wouldn't be a problem.

I see; in this cases, go to Advanced Settings, and change the base url property.

You can edit the connection string using Inedo Hub; it should be listed right under the Configuration tab. Note you will need to stop/start the service and web app afterwards. Might be best to stop both beforehand, however, so you don't have two potentially active databases.

Yes, ProGet supports this. However, you will need a paid version of Chocolatey in order to do that https://chocolatey.org/faq#i-would-like-to-be-able-to-offer-my-non-admin-desktop-users-an-option-for-self-service-type-of-installations

Just to close this post: this was fixed in InedoCore 1.0.12, after diagnosing the issue on a ticket (EDO-5683).

Are you saying you can't create a job from a template? The main purpose of the template is: Instead of specifying the plan and server targeting each time you create a job, you can create a job template that will specify these for you. The template can also specify variables that will need to be entered when the job is run. While this can save you a few steps when running jobs, the biggest benefit of job templates is that, once defined, you can now trigger jobs using a the job trigger API. This will allow you to use nearly any other tool, such as Jenkins or a PowerShell script, to trigger an Otter orchestration job. However, we plan to expand it to be a lot more useful with better variable selection, etc.

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