i updated to PowerShellGet 1.1.1.0 and it solved my issues. Release Notes PowerShellCore support Security enhancements including the enforcement of catalog-signed modules during installation - Authenticated Repository support Proxy Authentication support Responses to a number of user requests and issues

With regards to my question above, I have found this blog article that has helped me: https://richardspowershellblog.wordpress.com/2015/01/04/creating-a-powershellget-repository/ It talks about Proget and using a Nuget feed type, but the same methodology applies using the Powershell feed type.

Thank you. That was the solution. I had already rebooted once, because the Windows Powershell update required it. I rebooted the machine again and now BuildMaster is reporting the correct version. Thanks again.

Ah, yes... definitely a bug. Seems to be related to some unanticipated changes in the latest WMF preview, but easy for us to fix. Can you please try upgrading to v1.0.3? Also please note that, due to a bug in the latest WMF5, it now appears you may need to specify a module name for some non-built in resources; it's supposed to be optional, and search all installed modules if not specified. We don't know when Microsoft will fix this, but the work-around is fairly simple: PSDsc xWebAdministration::xWebAppPool ( Name: AccountsAppPool, Ensure: present );

In the v4 execution engine, your best bet is to create a file with that name, and then read the file contents into a variable. In the v5 engine, you will be able to export variables via powershell a little easier (example: PowerShell & Scripting from Otter docs.

Yes, we are in the investigation phase of adding this feed type. If it turns out it's as simple as sharing the functionality of the NuGet feed, it will be released earlier rather than later, but we do not have a scheduled date yet as to when it will be shipped.

In the v5 plans (which we will ship in 4.9), you can have "output variables" from your powershell scripts. But currently, you can't communicate back to the BuildMAster execution engine via a script with anything but exit codes.

Just letting you know that we have added a feature to BuildMaster 4.8 that we're calling Ambient Script Variables that should solve this problem. Basically, it allows you do define script variables that BuildMaster will evaluate and assign before running a script. So, in your case you'd just add one called ReleaseNumber that contains the value $ReleaseNumber (the value can evaluate to anything though, and use any variables/functions that are in scope when the script runs). 4.8.0 should be released tomorrow.

I can't seem to reproduce this. I've added both an action that simply runs a script and another action that runs a Script Repository script, and both of them write to the output log using write-output. If you're using the "Execution PowerShell Script" action, did you make sure to check the "Log Output" option? Can you export the deployment plan of a simple application that demonstrates this behavior?

@J.D. - can you post this a new question? It may only be tangentially related to the original post in this thread.

You can try this method with the BuildMaster service (INEDOBMSVC) or agent (INEDOBMAGT) if it's running on a remote server: http://www.codeproject.com/Articles/4891/Interact-With-Desktop-when-Installing-Windows-Serv

Currently, parameters are not supported by that action, though it is likely we will add them. For now if you drop the 'param($SolutionPath)' line it will work.

Awesome! It looks like the API is working without a hitch in powershell. At this point, we probably have enough to to start with and a few angles to test. If we have any issues with the API or procs, we'll come back here. Thank you!