A common mistake I see (and often still make myself) is publishing the parameterization files with your web application. Visual Studio marks the file’s Build Action property to Content by default when you add a new XML file. This means it will be deployed in your application just like any other HTML file would be.
This causes two potential security risks. First anyone who has admin or read access to the website folder on the web server could read those configuration settings and possible use those details nephariously. Secondly, XML files are served up by an IIS by default so anyone who has access to your website could attempt to read the file if they know or can guess the filename. THIS IS BAD!
Change the Build Action to None for these files and they will not be deployed. This will likely cause an issue however in that you need the SetParameters when you run the deploy command. For this you can add your SetParameters files to an ItemGroup and then copy those files to your package folder.
<ItemGroup>
<SetParameterFiles Include="$(MSBuildProjectDirectory)SetParameters.*.xml" />
</ItemGroup>
<MakeDir Directories="$(PackageFolderPath)" />
<Copy SourceFiles="@(SetParameterFiles)" DestinationFolder="$(PackageFolderPath)" />
I didn’t trust myself to remember to set the build action. As a result, I added a custom build action. I just added a .targets file defining the custom build action to the root of the application.
Then, imported this target file from the project file.
This adds the custom build action option to the Visual Studio drop down called parameterization. Just set each SetParameters.[environment].xml file to this new build action and you’re good to go.
Using this method, if one forgets to change your build action, the SetParameters file will be missing from the package location folder and it will be immediately apparent that the change in build action didn’t happen for the file.
If your custom build action places the files to the “root of the application”, won’t they still be deployed? Did you mean the root of the package folder? I like this approach though, I don’t trust anyone including myself to remember this. You could also have the custom MSBuild script delete any SetParameter.* files from the deployable file list.
We are still keeping our set parameter files on the root of the project. Our Visual Studio Build step in our build definition is run with the MSBuild arguments /p:DeployOnBuild=true /p:PackageLocation=”$(build.StagingDirectory)”. Once this step is completed, along with standard copy files and publish build artifacts build steps, the build artifacts folder is left with the packaged zip along with the standard deployment files ([project].setparameters.xml, [project].deploy.cmd, etc.). However, each custom setparameters.xml file which is set to the custom build action is also added here alongside the deployment package and omitted from the package itself.
Now if we forget to tag a setparameters.xml file, it will not be present next to the package. This will break our deployment process, as our deployment process is expecting setparameters.[environment].xml to be present when deploying to say production. This will make us aware of the issue and we can easily address it. It is just a mechanism we use to ensure that our custom set parameter files don’t make their way out to our production environments.
Hi,
Can you please advise where the code should be placed? I have pasted in .csproj but it throws an error to specifiy destination folder. Meaning $(PackageFolderPath) is empty.
Yes you place it in the project file (csproj). You can set a Property for PackageFolderPath or set the destination explicity to the package folder path.