Spot on! Its working. I feel really sad when I think that I was troubleshooting this issue for the past 1 hour. I know I was doing something wrong! But thanks a lot! :)

Can you send a screenshot to support@inedo.com exhibiting this behavior? In a quick smoke test my debug logs disappear when I remove the task from all the roles.

In general, we recommend going with a "business context friendly" name for your application. There are several reasons for this, but it mostly goes back to the fact that it's a lot easier to share/consume friendly names. There are times, however, when it makes sense to match name/code/scm/etc., and this is usually when there's a "conventions" approach. For example, our extensions (see BuildMaster Implementation Specifics) use the application name to determine a lot. But this usually only makes sense when you have a lot of "cookie cutter" componentized applications (such as in our case). So for your example, I would say name it "Awesome", and then have multiple deployables within that application. I wouldn't use the word "solution" unless it's actually part of the business name. For us, the application name is "BuildMaster" not "BuildMaster Solution"... even though our codebase has a "BuidMasterSolution" folder and a "BuildMasterUbserSolution.sln" file.

The remote repo is not required if the local one should be used.

There shouldn't be. It's probably trying to create a new record for whatever reason and that is triggering the dupe check. There's no other provider with that name.

Ah, thank you so much, don't know how I missed that. :)

Sorry to resurrect my old post, but I'm trying to use LDAP in ProGet and am running into the same issue. Users and groups that are in the domain of the server running ProGet are found, but users in a different domain are not.

We have released BuildMaster 4.1.3, which addresses this issue: BM-1380 - Hide passwords from clients when UseDpApiForPasswords is enabled So as long as that option is enabled, stored passwords will never be accessible from the UI.

I went to the Releases table and fixed it by hand, and the sequence is correct now. Thanks.

In short, if you are relying on exact paths, you should use the ~\ syntax with directories (e.g. ~\Source, ~\BuildOutput, etc.) which represents an application-relative path and doesn't use any SRC or WRK directories. How the SRC and WRK directories work under the hood is as follows: The WRK directory is used as either the source or target directory if they are not both set to use their default paths. If there is a source and target path that are both set to the default, a SRC directory is used as the Source and WRK becomes the target. Before this, the contents of WRK left over from the previous action are moved into SRC in order to work with those files (you'll see "Source and Target directory same; splitting." in the logs when this happens.)

You can pull the artifact out of _PublishedWebsites, or try the "This is a Web Application" checkbox. There is a transform config file action available as well, though you can store your configuration files in buildmaster.

It sounds like the files are being marked read-only from the source checkout; I would try to use the Set File Attributes action, and set read only = off.

As an extra note, if you're upgrading agents from pre-4.0 installations to 4.X installations, it will require reinstallation. Please see the following KB article for more details: Upgrading Agents for BuildMaster 4.0

If you want to delete long directory paths you should use Long Path Tool. It is great tool.

You just need the BuildMaster server IP. BuildMaster agents are push-only, so only the BuildMaster service will initiate connections to agents. You shouldn't need to make any other changes to enable this.

We've added support for extensions to allow HTML issue descriptions as of 4.1.0, but we still need to update the TFS extension to indicate this. We should have it available within a day or two.

We'll be adding some options to control text encoding for the actions which create a text file in 4.1.1, but in the meantime if you want to strip out the byte order marker, it should work to add a Search/Replace File Contents action immediately after the create file action that matches only the created file. Then, enable the Use Regular Expression option and put in a Regex that will match nothing, such as ^$ The Search/Replace action should strip out the characters at the beginning of the file. Alternatively, it would be pretty straightforward to create an alternative Create File action that never writes a BOM using the script repository feature added in BuildMaster 4.1.

This sounds like a good candidate for a Reporting Action, but with the ZippedHtml option. Although the report outputs a binary file, you could write an html file to disk with a hyperlink to the file, and use that as the index. Both would be included in the zip file, and present in the report. If the FPR file is large, it might be better to save these on disk so it's not saved in the database. There are some additional built-in reporting actions that are not on GitHub; you can find those thru Reflector or something or fill out the Source Code Request Form. There are no background actions of course, but one option could be... Trigger that watches Promotion Completed event Runs report in background; adds report to the Build using the BuildOutputs_AddOutput action Add a Promotion Requirement to verify report has completed hope that helps. I'd be curious to see what you come up with.

You may want to check v4.1; there is some improved diagnosis/debugging with agents that might give a better error message as to the issue.

OK they are now triggering. Thanks. Please can you advise on how to manage the release numbers For the regression test I entered a release number one higher than the current release on the standard. In reality my regression release will never go into production. The regression Test workflow is set to a loose Automatic Release Close-Out and disabled Release Cancellation. But the standard workflow is set to strict on all these. When the standard workflow is released into production, will it cancel my regression release. Should I set the regression release to a much high number or will this screw up the standard release numbering?