VSTS Build with multiple config transforms

I’m working at a client who has been using VSTS Build/Deploy where they are duplicating each build per environment to go to Octopus where we obviously want a single build in VSTS and then binary promotion in Octopus.

They already have web.config transforms per environment (web.dev01.config, web.qa01.config, web.stg01.config, web.prod.config etc) - so going to Octopus variables would be a large effort (they have 02 and 03 environments from dev/qa as well as many applications) - as these files already exist - etc - so this is not an option.

For ASP.NET 4 applications - I can’t find a clean way to get the files copied as part of the publish.I want to use the “/p:FilesToIncludeForPublish=OnlyFilesToRunTheApp” option so I don’t get .cs files etc - but this cause only the single “web.config” copied - even though I have “BuildAction=Content” for the other config files.

The only work around I can think of is a manual copy step after the build to copy all the config files to the “/p:publishUrl=” folder - so they will be included in my NuGet Package from Package step and then I can specify the transform in Octopus.

I would prefer not to have to do this if there’s a cleaner way.

Thanks!

Hi,

Thanks for reaching out! In Octopus we always try to recommend customers to include in the package all the files needed to deploy to all environments. This way you can promote the same package to the next phase everytime.

So the recommended approach would be to always include all the config files in the package by setting their config as Content and as copy always. Did you try with those 2 settings and it did not work? If that’s the case, could you send us your build log, along with a copy of your project’s .csproj file so we can check it?

I have set this conversation as Private so only you and our staff can see the attached files.

Thanks!
Dalmiro

That’s it. Documentation on MSFT, SO etc seemed to imply Build Action of “Content” is sufficient, but the Copy Always is needed as well.

Glad to hear that worked :slight_smile:

I’m setting the conversation back to public as no sensitive information was shared on it, and it’s content might be beneficial for other users running into this issue.

Agreed - I did try searching and didn’t find what I need. Hopefully this can help another customer!

Thanks again!

Actually - it didn’t work - I forgot I put a work-around and forgot to take it out. I added a step to the VSTS build - simple “copy files” step - to copy from the application directory to folder I publish to with web.*.config

The publish puts the content for copy always into the BIN folder -which obviously isn’t where we want it

What happens if you only keep the below MSBuild parameters:

/t:Build /p:RunOctoPack=true /p:OctoPackPublishPackageToHttp=[YourURL] /p:OctoPackPublishApiKey=API-123

I don’t get any output that’s usable to deploy with, it pretty much does a clean and nothing else… There’s no reference in the build log about running any Octo Code

Note that I’m using VSTS on a hosted sever with the Octopus extensions - so I don’t previously have anything even closely resembling that. I’m doing a publish in my Build Tasks, then the Package Extension, the the Push Package Extension, then the create Octopus Release Extension

Here is the MSBuild parameters I’m using

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:ExcludeGeneratedDebugSymbol=False /p:FilesToIncludeForPublish=OnlyFilesToRunTheApp /p:publishUrl=$(build.artifactstagingdirectory)\publish

Totally my bad. For a second I thought you were using Octopack, reason why I asked you to pass those Octopack-related MSBuild parameters. Apologies for that mistake.

The Package Application step from the Octopus extension is pretty straightforward in the way it works: It’ll simply pack whatever is in the folder you point it to. So it does require a good knowledge of the compiling tool to figure out how to get exactly what you need on the target folder. This is hardly ever an easy task with MSBuild unfortunately :(.

I believe that using the helper script after MSBuild runs is going to be your best bet in this case to make sure everything lands in the folder you are about to package.