Done... ticket #EDO-1612.... hope it helps, and thanks in advance for all your efforts and attention.

Thank you for the report, it appears to be a regression with that event listener that will be fixed in the next version. A patch is also available for download here, simply extract the zip file and execute the contained SQL file against the BuildMaster database. Note: This patch may only be used for versions of BuildMaster between v5.0.0 and v5.2.3 (inclusive) and will be already included in v5.2.4 and later.

OK, I was supposing it but I didn't find it explicitly in documentation. Thanks for your quicker answer.

A bit late in the game for an answer, but I thought I would add my two cents: Tod is 100% correct, you do not want to use variables within Buildmaster for this, but you do not need to go the length of over-managing either. To resolve this issue: Passwords: Resolve this with the credentials for the database. Database name differences: Have your DBA create a Synonym across the board. For example, if your app is named "DirtyHarry" and on DBDEV is called "RevolverDB" and PRODDEV is called "MagnumDB" just create a synonym "DirtyHarryDB" on both servers, resolving to the actual DB name. Then in all your change scripts use DirtyHarryDB... or just set a synonym on DEV to be the same as PROD DB name or vice-versa. There are quite a few ways you can resolve issues like this, but it is always better to be genericized. We have the same in that we utilize snapshots in DEV that can be in any database location, but in production they are referenced to linked servers. -Kevin

Here are the exceptions that I'm getting when add my extension(nothing descriptive for me): Details: URL: http://localhost:81/administration/extensions Referrer: http://localhost:81/administration User: Admin User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Stack trace: at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async) at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size) at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination) at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) And another one: URL: http://localhost:81/administration/error-log/entry?messageId=139 Referrer: http://localhost:81/administration User: Admin User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko Stack trace: at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async) at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal) at System.Web.HttpResponse.Flush(Boolean finalFlush, Boolean async) at System.Web.HttpWriter.WriteFromStream(Byte[] data, Int32 offset, Int32 size) at Inedo.IO.SlimMemoryStream.CopyTo(Stream destination) at Inedo.Web.PageFree.SimplePageBase.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Update to 4.1.3 has solved this issue for us.

We just updated our server from 4.0.8 to 4.2.0 and now we encounter this problem too. After confirming that the package/version should be deleted, you are redirected back to the feed but the package/version is still there. In the log there are no errors whatsoever and the recent error log shows "There are no recent errors."

I'm migrating all our "workflows 4.9.7" to pipelines 5... then converting our legacy plans to the new plans...maybe in the future will not so often than now...but actually I have that situation almost every time, and sometimes the errors appears after 10 or 20 minutes of an execution...

In ProGet v4.2, there is an option right under Disk Path that says Package Store. [image: vYDcll0.png]

Yes, it's posible, and that's a common workflow; there are operations to do all of these things. I would try to follow the [BuildMaster tutorials])(/support/tutorials), some of them have some workflow similar to what you're doing. The other things (like SEnd Email, Execute SQL Scripts) are just differnet types of operations you can run during a plan.

If it's showing up on the one page, but not the other, then i'd say it's definitely a bug. I've logged as PG-595, so we will look to fix in next maintenance version.

This is only available as a legacy action as of 5.2.1; there is no corresponding Operation built for it yet, but we will get one going soon.

Alright, v5.1.2 was released and it should be correct now :)

If you're able to get it up and running, then we'll definitely support as per usual. Basically we just don't have the knowledge/expertise to help install / set-it up on Azure (we haven't even tried it ourselves). But it should work... they seem to support a lot more parity with regular SQL Server, and a lot of installs are on SQL Azure.

Please refer to the ProGet Silent Installation page.

Hello, I was not able to reproduce this. Here is what I did. Create a new PowerShell Asset... Name: Test Script Parameters: none One ambient variable: MyEnvVar ==> $EnvVar Contents : Write-Host My var is $MyEnvVar; Create a variable on MYSERVER: $EnvVar = my server var Create a new application with a deployment plan that has a single action (targeting MYSERVER) that calls Test Script Output is My var is my server var, as expected I also deleted $EnvVar from the server, and then created it on an environment the server is associated with, and it works as expected. When I deleted $EnvVar from the environments, it produced the literal output (My var is $MyEnvVar) upon running. So, my guess is there's a typo somewhere... best, Alana

Understood! Thanks for the quick response. Btw, it would also be nice to have a "Clear All" button in the recent errors section, because when we start having a ton of the same error, it fills it up and we can't clear them easily. Thanks again!

This is not currently supported, though we will look to add this in a future version. pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported. You could always write a simple powershell script, and remove the service, webapp, and installation directory. That's pretty much all that is installed.

As of v4.2.0, the ProGet Chocolately package does not have an uninstall script. At the time we build the package, the uninstall scripts were not at all in common use or recommended. However, in the latest version of Chocolately, it seems the client inspects the registry to see what was added to the "remove programs" keys, and then attempts to run the commands. Like most "uninstallers", pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported.