That shouldn't cause a problem. But you can verify it by disabling the group with your batch file calling, and then replace it with the sleep action,

Tod, Thanks very much for this piece of info and the source. Very useful. I've been able to do complete my extension, working all good!

Thanks Jon, I can how that was ambiguous! I've now updated it w/ more accurate info.

Although we do not provide a reseller discount, we do work with quite a few software resellers who purchase on behalf of their clients, as those clients prefer to have a single source for all procurement. If, as a reseller, you purchase directly from the MyInedo portal, just contact us with the end-user information, and we will update the licensing information. You can also submit a quote request as needed.

So I stand corrected. This just doesn't work for me. I have an application variable set for the BUILD scope, it's a string with the other variable of $MajorVersionNumber in it and it will never get expanded regardless of how I use it. Is this variable not available during Build? It's marked as a Release variable which I took to mean anytime during the entire process, build, deploy, etc.

update, I have found that after I have Deployed the app to our Development plan I can now see the links to the reports on the that build page. However they do not show under the Build plans results page which is where I would also expect them to appear. Still nothing showing on the applications Overview page either.

The Publish action (for NuGet extension v4.7.1) requires that the URL is entered into the action itself (Server URL property) or it uses whatever is in NuGet.config, it doesn't fall back to the server URL specified in the configurer.

Thanks for the report, I logged this as an issue to further investigate... PG-492

Thanks, I'll add this as a feature request; there should be a link on the "perform manual action page" that links to the execution, but you can see all current executions on the home page dashboard.

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

Thanks Jon, I've added this as an issue -> https://github.com/Inedo/bmx-nuget/issues/14 We'll likely get this in v5, since we want to do some additional refactoring as well. And perhaps updagde the client version.

Thanks Alana, that's very useful to be aware of, I'll follow up with the nuget team as well.

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 );

Alana. I have made a pull request https://github.com/Inedo/bmx-windows/pull/30 Thanks for pointing me in that direction. It was indeed very easy to modify the codebase.

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section

This would be very easy to do with a PowerShell script, so as an immediate solution, I'd suggest to do that. It'd also be very easy to patch/modify that particular action (CreateIisAppPoolAction.cs) That being said, this all applies to the "v4 execution engine", which will very soon be replaced with an indescribably better execution engine (the one that Otter currently uses). When we migrate the "v4 App Pool Action" to the "v5 App Pool Operation", it will basically look like the Ensure-AppPool Operation. So, as you continue to explore BuildMaster, do keep this in mind :) If you're doing server/infrastructure configuration (which, creating applications is definitely a part of), I'd strongly recommend looking at Otter as well!

This is unfortunately not trivial to debug, and will require understanding/learning how the symbol/source serving work (and the arcane tools to inspect said files), since it could be any number of things at this point, from your local pdb cache to improperly build pdb files. But take a look at some of the other Q&A posts with symbols tag, specifically this one which shows how to use pdbstr.exe to inspect. If you find out specifically what the issue was, please do share it.

Hi Joel, thanks so much for trying out Otter! The best place for issues would on the Submit Ticket form, but you're also welcome to email us direct at support - at Inedo - dot com. Pricing software is always difficult, but we tried to keep it competitive with other IaC tools, which are still insanely less than traditional SLM tools (BladeLogic, etc). So, we're open to suggestions on all fronts, including that! Perhaps your case is much different than we had imagined. As of v1, the only difference between the free and enterprise editions is that the free version provides unrestricted access for all users (i.e. everyone's an admin). For some of our early adopters, it made sense, because they have: dozens of important, regulated production servers hundreds of less-important dev/lab servers So, in that case, they would have a Lab (Free) and a Production (Enterprise) instance.

Hi Mike, Apologies for the delay, but the problem is with the NuGet extension for BuildMaster. There is a new version (4.7.2) available that can be updated from within BuildMaster on the Admin > Extensions page.

Awesome!! Thanks guys!!