You should be able to use a variable server by editing the action's config xml, and replacing it with %VARNAME%; however, this is not supported in the editor, and will break once upgraded to 4.0. But, it will work. The Variable Server in XFer Files will be available in 4.0.

Hello, Would it be possible to ask a follow up question to this... Are you using Visual Studio 2010? I tried to find the setting that you mentioned here, but I can't find it in my Visual Studio 2010 setup, and I am wondering if this is only possible in Visual Studio 2012. Thanks Gary

You could use the ExtensionConfiguration_GetConfiguration method, e.g.: EXEC [dbo].[ExtensionConfiguration_GetConfiguration] 'Inedo.BuildMasterExtensions.Artifactory.ArtifactoryConfigurer,Artifactory', NULL, 'N' and get the Extension_Configuration column, which contains the XML serialized properties of what you need - some simple XPath should be able to retrieve them.

Thanks for the Answer Alex, I was able to get this to work. Maybe there should be a screenshot showing the Test environment's setup?

Great, many thanks for your support!

There's no specific error message, aside from the SQL error that's being thrown. Since you have both on the same server, perhaps it'd be best to have a single SQL Server instance (SQL Express), and have the BuildMaster and ProGet databases hosted in that server.

This is how the "default directory" is implemented (see http://inedo.com/support/documentation/buildmaster/deployment-automation/deployment-plans/actions). It allows for the same directory to be used as input/output. At the start of the action, the "WRK" directory is moved to "SRC" and a new "WRK" directory is created. If there are no files in "WRK" at the end of the action, "WRK" is deleted and "SRC" is renamed to "WRK". Otherwise, SRC is deleted.

Sorry about that - there was a bug with that action in BuildMaster versions pre-v3.6.5 (specifically BM-1137). If you upgrade to the newest version of BuildMaster the "Set File Attributes" action with your masks will function as intended.

Can you try to use the "Build .NET Project" without checking "this is a web application"? Then, capture the artifact from _PublishedWebsites\project.name instead? This is how we solve this problem when we build proget (see http://inedo.com/specifics/proget), and we'll soon be adding another option for this action.

This is likely a subversion/workstation configuration problem. Sometimes two versions of Svn.exe -- the one you installed (like tortoise svn) and the one built-in to the extension -- cause conflicting configuration. Try to change the provider configuration (Admin > Source Control) to point to your own svn.exe instead of the built-in client. Also, try to change the option to use SVN UPDATE instead of EXPORT for this provider.

Short of using the API, I can't think of a way to have the deployables be automatically removed based on variables. You could try a trigger, but that might not hit in time since those are on a few-second delay. The custom predicate sounds like it would work well.

What error message are you seeing?

Maybe... but there's no plans right now for it in 3.x. We plan on having support for that in 4.0

You are correct - I had a typo in the working directory !. This question can be closed.

Nevermind. I see the answer here ( http://inedo.com/support/questions/820 ). I swear it wasn't there on Friday.

Hey Tod, Sorry about the confusion, the error was indeed different. I think we got a bit cross eyed while trying to figure all this out. The setup that we had to use in the end was rather awkward. Buildmaster seems to add quotations around the arguments section. We had the following setup: Command: delete http://<path_to_repo> Argument: -m "ReExecution by Buildmaster" When looking at the logs, it was converting that to: delete http://<path_to_repo> " -m "ReExecution by Buildmaster"" --non-inteactive etc... Notice the double quotations. So we ended up having to jimmy it a bit and it is now working with: Command: delete http://<path_to_repo> -m Argument: ReExecution by Buildmaster So I guess we can scratch this one of the list. Hopefully can present to the boss soon and get some budget for this.

Unlike most BuildMaster custom editors, the VariableSetters do not have a Context object; we'll consider adding this in future SDK versions. In the meantime, you'll have to "hack" it by looking at the HttpContext.Current.Request.Querystring for the release number, or perhaps locating the Release Number control on the page.

Thanks for the report, I've reproduced the behavior and logged it to be fixed in the next maintenance release.

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

At the moment, build and promotion-level variables cannot be modified by an action during an execution. This is mainly because of the way default values are cascaded and inherited. We've talked about adding another variable scope (execution) that then is created and persisted only at execution time, which would then allow for this - but at the moment build/promotion variables are immutable once the build is created. You should still however be able to add variables during execution time - they just won't appear in the build summary. In a quick test I ran setting a variable that wasn't specified as a build variable worked later on in the execution with the code you have written, so I couldn't repro part 2. Make sure both the BuildMaster service and web app are restarted whenever the extension changes, otherwise changes might not actually be loaded by the extension loader.