George, thank you so much for pointing me in the right direction, that's exactly what I was looking for!

This was introduced into 5.8; so please update to the latest v5. https://inedo.com/buildmaster/5.8

OK ; in this case, can you provide a simple reproduction case that we can try? Like, a new application that reproduces this? And please send this as a ticket -- Q&A are generally the lowest priority when it comes to support, so we want to handle it through better channels :) The $ApplicatinName and $ReleaseNumber are standard test cases for us, so they do work in our config file replacement tests (which, are quite complex due to so many legacy cosniderations...)

This appears to be a bug - it should work exactly as you have stated. Our internal issue ID for this is BM-2281 and should be released in the next maintenance (or minor) version (whichever comes first).

That is just a "regular" COM+ that happens every now and then when doing anything with LDAP, so you an usually restart IIS, restart the server to fix it. Will send the code ASAP!

Yes, definitely; BuildMaster supports any type of file, such as Java .properties as well. You could set up with a simple replacement syntax, or just have a separate .ini instance file for each environment.

You are not going wrong :) Support for XSL as the template and data as the instance will be added in v5.3.4 as a separate template type so it doesn't break existing deployments. We'll release this within the next day or so.

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.

ProGet on IIS is only supported as a root level web site of IIS - it cannot be a virtual directory of another application. If this is not an option, you'll have to go with the built-in web server option.

The "load from" options were removed in v4.5, I'll add a note to remove that from the tutorial. Updating the screenshots is already on the list to update as well.

It's fairly rare to have 2 config files with the same name assigned to the same deployable, and when they are under 2 different deployables, an action within an action group in the context of a deployable will only show the single config file in the dropdown.

The story continuous :) Because I set TeamCity to create source packages as well (it's a checkbox called: Include sources and symbols) it was overwriting the packages in ProGet (I have all the PDB and sources in my nuspec files as well). This was causing the issue with the config file being gone, because TeamCity strips those files out for the symbols packages. So... I was doing things twice... Must be user error ;)

Thank you for your help!

In .net, it's usually best to split out your web.config files into multiple files using the configSource option. So, <appSettings configSource="web_appSEttings.config" /> This way, you only need to edit web_appSettings.config when a key changes.

Additionally, if you have publish profiles saved in your solution, you can add the following additional argument that will exhibit the same behavior as AutoParameterizationWebConfigConnectionStrings=false for the chosen ProfileName: /p:PublishProfile=ProfileName

Thanks for your reply, advice and for pointing us in the right direction. I think we need to rethink our web.config procedures.

Hi Tim, You may want to create a role with the task, Builds_PromoteBuild, and then only deny that role to Production. Alex

Hi, Please ignore this question. The issue was ultimately down to the config file having unescaped percentage symbols within it and hence variable substitution not working. Regards, Jay

Are you trying to create a new instance ("tab") on the config file? If so, and if you're getting that error message, then you'll need to go to "Manage Instances" and click "Show Deleted" in the top of the window. From there, you can undelete the instance.

Okay, thanks for letting me know. I did change the name through the database, and that worked just fine. The history of the rename is not as critical to me as the deployment history, so I think we're good for now. Thanks for the reply, Matthew