New Reply


Sorry to keep asking so many questions...

New scenario: I have an application packaged in ProGet and being deployed to a server. The ProGet package includes a web.config file in. This has various 'static' settings - assembly references etc - along with some settings that will be specific to the environment - connection strings etc.

I have created a server role with a configuration with steps to:

  • Create a directory
  • Deploy the ProGet package
  • Apply the environment-specific settings in the web.config

Pretty much the same thing as the tutorial here:

My problem is - or appears to be - that after the remediation job has run, and the Ensure-AppSetting statements have been applied, the web.config doesn't match what is in the ProGet package, so it's considered to be in drift status.

Is there something I can do so that when Otter is checking for drift in a config file, it will apply Ensure-AppSettings statements to the ProGet source file before it compares it to what is on the server? Or is there some other way around this?

Thanks again!


Product: BuildMaster
Version: 5.8.1

I think the best solution for this in terms of Otter is to add exclude masking for the Ensure-Package operation so that it ignores certain files, e.g. you could specify **.config to ignore any differences in files that end with .config. This could also be extended to ignore logs directories or other non-package items.

I've had one of our devs create an issue for this here:

Thanks Tod!

The workaround of excluding the web.config file doesn't quite meet the requirement here, as we then won't be able to detect drift in the non-variable parts of the web.config.

For example, say our web.config looks like:

		<add key="ConnectionString" value="ConnString" />
		<assembly name="system.web.mvc" version="" />

(This isn't strictly accurate, just an example).

The connection string varies from environment to environment, so is ideally controlled by a variable within Otter. However, the assembly version might change as a result of something done by the development team - or we might add new assembly references etc (or any of a number of other types of change in the web.config).

I do however appreciate the technical challenges with this approach - in fact I'm not sure where you'd begin to implement it, as I assume you'd have to do something like:

  • Extract the ProGet package into a temp directory
  • Run any operations that might modify any of the files in the ProGet package in the temp directory
  • Compare the existing files to the temp directory

Which seems like it could be a messy process!

Would be interested to hear your thoughts on this - I'm always open to being told that I'm doing things wrong, so if there is a better way, that would be great!



Answer Details


Post Reply