Awesome Ben, thanks for the quick action! I've followed the issue, will I get an automated notification when it's known in which version the fix is going to be available?

We identified a cause of this, and it was fixed in PG-1121 in ProGet 4.8.6

The fix for this is included in the latest release of BuildMaster (v5.8.1).

I should clarify my last post, it does a Return Select 0 only when it is successful.

Thanks for the reply. I didn't really think it was BuildMaster itself since I can deploy other smaller apps to the same server, same main web site, without issue. This particular app has a lot of files so I was somewhat suspicious of BuildMaster, memory, Windows or combination thereof having some issue with that large number. I am continuing to debug it and we have been looking at couple of possible issues. One thing that did come is a possible incorrectly registered DLL. Our IS dept had been registering it under the apps folder rather than the Windows/system32 folder but it's not certain that the one is this particular folder was the one registered. Unfortunately this is a live server so I have to use caution as to what I do on it.

Ignore. Someone had modified a property value incorrectly when combining two variables which was causing the Virtual Path to be invalid.

We've resolved this issue by running the Inedo agent service on the new build server under the same account as the Buildmaster service on our main server.

This is definitely on our roadmap; stay tuned!

I mean to add, I do have a Timeout set of 15 minutes which I would have thought would be long enough. I am bumping the timeout to 30 minutes. However, I was just looking to see if anyone else had run into issues with Symantec and/or Windows 2012r2 with artifact deployments.

You can use your same license key in this case, it's no problem! The licensing agreement for BuildMaster and Otter explicitly permit dedicated dev/test instances. ProGet requires a separate server... but if it's just a temporary migration then it's also OK too.

The best work-around for this is to create as secondary IIS site that points to the same root, and then configure no Windows Auth on that site. You will need to have two proget urls; one with WIA and one without. Unfortunately there is no other workaround, as NPM simply doesn'ts upport it, and IIS doesn't support having some parts of the site use WIA, and others not.

I have created an issue to add a feature to display a better error message when the base url property is invalid.  (PG-1107)

Thanks for your answer! We'll gladly wait for it and in the meantime keep using proget for our other sources. Thank you!

There is a DoNotClearTarget option on the Deploy-Artifact operation that, I believe, will accomplish what you are looking for. We don't have masking (which would allow you to deploy only some files out of an artifact), but you certainly could deploy the artifact to the working directory, then copy or transfer files to the target.

This is on our list to update eventually, but very low priority. If you need it right away, it might be easiest just to download the NuGet.Server package and extract the contents over the matching \bin DLLs of the v2.8.6 installation. Note that it requires .NET 4.6 (which you likely have already, but worth noting).

Unfortunately we don't have a good example case for this, because each scenario is kind of complicated. what's the best way to divide responsibility between the 'parent' and 'child' applications. Do I have to build the create releases for the child apps manually first and then have the parent look for those? You could certainly use the Create-release operation to create releases, but that may not be what you want. One factor to consider is, how different are each of these releases? Do you have a lto of variables you want to set? That will impact the ease of the interface you create. I'd like to have the parent orchestrate the whole thing to make the process easy for the operator (i.e. other team members) but I'm not sure I'm thinking of all of this correctly. For instance, I may only want to deploy 2 of the 5 child applications. If you only have 5 applications, then it's a lot different than 50 applications. One thing you could do, is five different variables (DeployApp1, DeployApp2, etc). You could also do a list variable that has all five of those in there. The more you generalize, the more complicated it gets... and with only five, maybe yo dont need to generalize that much. Just a thought, but one idea I have... You could write up your proposed-setup (and why you set it up this way), and we could review it. This could be something we do as a blog-post, so we could share it with others. Writing it up will help give you clarity on it as well.

Thanks for the heads up; the moment I saw this, I immediately responded. Now we're just waiting for responses on the other side of some corresponding questions. Again, thanks so much for the hand!

This is not currently a feature, but we could investigate adding it to the extension. I am not an expert in AWS, so can you help us to understand a usecase? Why would you want to use a custom KMS key? How does that benefit vs using built-in? Note it's open source ... https://github.com/Inedo/inedox-aws/tree/master/AWS/InedoExtension/FileSystems

Hello Jason, I've filed [BM-3081], which will allow you to do this: foreach $ConnectionName in @DatabaseConnectionsInEnvironment($EnvironmentName) { Execute-ChangeScripts ( Connection: $ConnectionName ); } The default value for environmentName is the current environment ($EnvironmentName), so you can also just call @DatabaseConnectionsInEnvironment() with no argument (once this is released).

Hi Matt, If it's not too much trouble, what time did the executions start in the stage that unexpectedly succeeded? It should say in the Deployments section of the package page. (I'm mainly wondering if they started on the same second or on different seconds.)