Unlisting requires that Feeds_DeletePackage is part of the task.

You can fairly easily switch directory providers, so you could just try that and see if it works. A lot of organizations will have a dedicated ProGet test instance (note this requires a separate server license) to test upgrades and major configuration changes. For most organizations, both LDAP and the Multi-domain configuration "just work". So long as service account running the ProGet web application has the appropriate permissions to query, and the domains are set for proper trust, then users will be retreived as expected. But for some, it doesn't, and the only way to find out why is to do a detailed analysis using our code. 90% of the time it's a domain configuration problem. But there's no easy way to identify it because the AD libraries do not tell us why certain users or their groups are not returned in a query.

That did the trick! Thanks for the hint.

Thanks for the bug report. We'll investigate and get a fix in the next release. We probably will also change the group syntax in dependencies to use a / instead of a colon, so you could just specify: "Root" (or "group/Root", etc). Of course, we would retain compatibility with the : syntax as well, but this would make things less ambiguous.

The way is correct, but it appears there's a bug in the evaluation while accessing the variable; this will be fixed in [BM-2278], which brought code in from Otter that fixes this bug.

Hi Alana, thanks for that. Preliminary checks have given me no further timeouts. My push action takes just over two minutes (funny, I thought my internet was faster).

You can Log-Information to see what $WorkingDirectory is. Unless you set a value, it will be something like C:\BuildMaster\_SVCTMP\_Ennn\D0 where nnn is internal identifier of the execution. Log-Information Working-Directory is $WorkingDirectory;

Thank you. The source code makes it explicitly clear what is going on. I was assuming that the OtterScript variables were being parsed out directly from the text input rather than being passed to the PSParser before hand. This also explains my troubles with the List and Map variable types as I was attempting to utilize them inline in my PSExec steps. I would suggest mentioning this parse behavior in the PSExec documentation link text and in the "Inline Script Execution" section of link text

Very cool, thanks for sharing! I actually ended up doing the same thing by making a curl call, but I like your way better. I'll try to give the plugin a try sometime.

Yes; that behavior was added in v3 because there were a lot of execution collisions (the default working directory used the ApplicationId). This was undesired by nearly all users. The v5 engine uses ExecutionId for the default working directory,, and any collisions outside of working directories should be resolvable with a global lock.

Just enter the license key in Admin > License. You can request a key at my.inedo.com

You can use the ProGet Native API to create feeds, and we will soon have a better endpoint available for that.

You will need to reactivate ProGet from the Admin UI. there will be instructions on how to do so within the software.

We did remove the dropdown for prerelease from the NuGet feed browser to make it more in line with how NuGet.org is these days. As of v4.5.0, we always show the latest version in the browser, including prerelease packages.

Apologies, I've created an account and now have a license. Thanks

I get the same result with versioin 4.5.1. I try to change the connection string during the install but it still uses the default connection string and not the one I entered. I also tried to set it using the silent option. Then the installer fails without any message at all, not even to the specified log file.

Thanks Steve! That solved the issue.

Thanks for the bug report; this is fixed in v4.5.1, which was just released.

Yes indeed, take a look at Asynchronous Blocks. Here is how you would do it in OtterScript: foreach $value in @list { with async { ... items ... } } await;