Hello and thanks for the suggestions, @atripp! I tried doing an Invoke-WebRequest against the repository URL. It appears to work fine, which is nice but also a pain as it indicates the problem is more complicated. PS C:\> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 PS C:\> $test = Invoke-WebRequest -UseBasicParsing "https://${progeturl}/nuget/${repository}/" Invoke-WebRequest: You must log in to issue this request because the anonymous user does not have the Feeds_ViewFeed privilege. PS C:\> PS C:\> $test = Invoke-WebRequest -UseBasicParsing "https://${progeturl}/nuget/${repository}/" -Credential $credential PS C:\> $test StatusCode : 200 StatusDescription : OK Content : <?xml version="1.0" encoding="utf-8"?><service xmlns="http://www.w3.org/2007/app"><workspace><title xmlns="http://www.w3.org/2005/Atom">Default</title><collection href="Packages"><title xmlns="http://…"> RawContent : HTTP/1.1 200 OK Cache-Control: no-store, must-revalidate, no-cache, max-age=0 Pragma: no-cache Server: Microsoft-IIS/10.0 X-ProGet-Version: 22.0.7.3 X-Powered-By: ASP.NET Date: Sat, 24 Sep 2022 … Headers : {[Cache-Control, System.String[]], [Pragma, System.String[]], [Server, System.String[]], [X-ProGet-Version, System.String[]]…} Images : {} InputFields : {} Links : {} RawContentLength : 273 RelationLink : {} PS C:\> echo $test.Content <?xml version="1.0" encoding="utf-8"?><service xmlns="http://www.w3.org/2007/app"><workspace><title xmlns="http://www.w3.org/2005/Atom">Default</title><collection href="Packages"><title xmlns="http://www.w3.org/2005/Atom">Packages</title></collection></workspace></service> I will attempt to use a tool like Wireshark or Fiddler to see what's going on.

@atripp Thanks for the pointers. Investigations did indeed reveal that proget was replying with the http url if FindPackagesById() request and that the subsequent redirect back to https was causing the credential to be dropped from the request. I've configured the BaseUrl with advanced settings and confirmed success with that in place. I now have a functioning proget instance and I'm able to efficiently work with the repo from Powershell. Much appreciated!

I'll see if we can get a new version built that includes an option to output the full log to the console after a job completes. In the meantime, you could call romp with a simple batch script like: romp install %1 romp jobs logs Then invoke it with: romp.bat <packageName> Let me know if that's helpful!

Thanks Philipe; all operation documentation is automatically updated within the software once the latest version of the relevant extension is installed (i.e. the Windows extension in this case). The documentation on the website will also get updated with any minor version of the software is released, or the Inedo.SDK is updated. Hope this helps, -Tod

Jon, I haven't found too much on this besides what we already recommended. I did find this option specifically for Import-module : https://stackoverflow.com/a/28512164

Typically this is caused by a Windows extension that hasn't been updated to the latest version following a BuildMaster v6 upgrade.

The problem is that OtterScript attempts to parse those variables first. Just use quotes: set $foo = true; set $bar = true; set $foobar = $PSEval("$foo -and $bar"); Log-Information `$foobar = $foobar; # prints: $foobar = True

I'm just following up to see if you were ever able to work-past this, or if it's still an issue?

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

The root of the issue is the NuGet team's decision to force SemVer: https://github.com/NuGet/Home/issues/3050

This is also being discussed here; long story short, this is a bug in Microsoft's PowerShell Gallery (and in the packages) in that they have two conflicting version numbers, and sometimes one is used, sometimes the other is used. The docs have been updated for now: https://github.com/Inedo/inedo-docs/commit/10c42c3ad546ac2feb4748b7736db06567c7a6d6

I ended up using powershell to add variables to a properties file of env.properties. Then used the "inject environment variables" post build step to add the file with those variables to by environment. #Powershell "APP_VERSION=$appVersion RELEASE_NUMBER_VAR=$releaseNumber IIS_APP_ROOT_NAME=$iisAppRootName APP_EMAIL=$appEmail" | Out-File env.properties -Encoding ASCII Then then used the Get-Release API to check and see if my selected release was a valid release. If not I created it with the Create-Release API. Then used the Inedo_BuildMaster Plugin for jenkins. Create BuildMaster Package - Post Build Step Variables: appEmail = ${APP_EMAIL} appVersion = ${APP_VERSION} buildNumber = ${BUILD_NUMBER} buildType = ${BuildTypeParam} iisAppRootName = ${IIS_APP_ROOT_NAME} iisHostNamePrefix = ${BuildTypeParam} After I figured out myself how to inject the Variables and use them properly this rout was much better because it let me know when the package was done deploying, if it failed, showed me the deployment log on failure and failed my Jenkins Job on Failure. Thank you for your answer though Josh!

Thanks John, that's good news! I'll check back next week and try the latest build. Cheers.

These will be included in the next maintenance release as per this issue: PG-1406

Hi Alana, Thanks so much for the update and the workaround solution. I'll be sure to upvote the linked issue. Best, Michael

My workaround for supporting scripts and modules is to essentially trick it. either specify the source and script source with the fqdn version of the url and then a shortversion of the url or, what I do, set up a iis front end for redirect urls. i.e. if your server name was repos and your domain was mycompany.com then you might set source to repos.mycompany.com:8624/nuget/myrepo and set script source to repos:8624/nuget/myrepo You can list and publish scripts or modules to the same repo and find-script will differentiate from within the repo. The more elegant solution, but more difficult, is to create a dummy website with real or virtual paths that use http redirects to the right sight. So you could set your source to something like repos.mycompany.com/source and that folder would redirect to the path on the different port. That's just a quick summary of the workaround, I realize that, I can provide more thorough examples if you would like.

Are you sure you're using the right server context when calling the BuildMaster Powershell Asset? If you print out the server name in your asset using $env:computername do you get back the expected server? If I create a simple plan ##AH:UseTextMode for server $MyServer { PSCall GLOBAL::Test_Powershell_Asset; } Where my powershell asset is defined as this one-liner Invoke-Expression C:\Path\To\PowerShell\script.ps1 Then I am able to run this script, no problem.

I'm not too familiar with how OneGet fits into all this; you'd really be better asking this question at the Chocolatey or OneGet forum. You'll still use ProGet to host the packages, but I'm really not sure which client tool (choco, etc) will do the download and install on a desktop.

The Jenkisn Plugin can only be used to upload Universal Pakages to a Universal Feed. You'll need to use Powershell-Publishmodule command to publish to ProGet.