Try our conversational search powered by Generative AI!

Mar 29, 2016
(3 votes)

Handling License.config with automated deployment

I am a big fan of automated deployment tools, and our tool of choice is Octopus Deploy. It makes continuous deployment of new code a breeze and has lots of configuration options to support different scenarios. One challenge, though, has been handling of the License.config file in EPiServer. As you know, we want a unique developer license for each developer, and then another license when deploying to common environments such as QA and PRODUCTION.

Previously, we have had awkward solutions such as uploading the external license file to folder on the Octopus server itself and then having a PowerShell script to copy that file into the solution as it was deployed. This has many disadvantages, for example requiring remote access to the Octopus Server, which I do not have in my current project.

Consequently, we had to come up with a better solution, and after some hard thinking we now have a nice setup that others may hopefully find useful. Here are the steps we have taken:

1. Include License.config in your .CSPROJ file – to make sure it is included in the deployment package


2. Set the contents of License.config to reference an Octopus Deploy variable (that we will define later)


3. Check in your .CSPROJ and your License.config to your version control system (GitHub in our case)

4. Exclude License.config from version control – this is the Git way to do it. After this, you install your personal developer license on your machine.


5. Now, move over to Octopus Deploy and add the deployment variable #EPiServerLicense. Copy the contents of the License file provided by EPiServer into the variable value.


NOTE! If you have non-ASCII letters in your license file, you will need to including …encoding=”iso-8859-1”… in the XML header, as you can see we have done in the screenshot!

6. Finally, in the “Deploy packages” process stage in Octopus Deploy, you activate the feature “Substitue variables in files” and enter “License.config” in the text box.

7. You are now ready to deploy. After deployment is done, you can verify that the variable substition worked by checking the Octopus log.


Mar 29, 2016


Hannes Lindroos
Hannes Lindroos Mar 29, 2016 11:21 AM

Is there any reason why you are not using specified license file path?


Lars Smeby
Lars Smeby Mar 29, 2016 03:35 PM

(NOTE: I am posting this on behalf of Thomas Svensen. For some reason, he does not get the comment functionality, no matter which browser he logs on with. He can comment on forum posts, but not on blogs. Is this a known problem? Suggested solutions?)

Hi Hannes, thank you for the feedback!

That is a very good question, and the answer is that we simply weren’t aware of that option. I see now that e.g. describe a good solution using that approach. Had I read that post earlier, I definitely would have gone that route.

That said, I don’t think the above solution is much worse. I think working with variables generally is easier than config transforms. Also, if the license information was considered confidential in some way, it would belong better in Octopus than in source control, but I guess that isn’t really the case for License.config. Really, the main advantages of using license file path is that you have everything in source control, and the setup is arguably a little simpler.

Again, thank you for useful input! Always useful to have multiple options!


Stellan Danald
Stellan Danald Mar 29, 2016 06:06 PM

We're using Octopus Deploy for several projects and are using the same approach Hannes mentioned.

We have all the licenses in a License directory in the project, named by after which environment it belongs to, then using config-transforms to set the path and post deploy powershell scripts in octopus deploy to delete the unnecessary license and config files.

Works like a charm.

hitas Aug 23, 2017 01:50 PM



an absolute path? It would help alot.

We are currently keeping an empty license file in our solution root and copying it via our custom MSBuild task just before we initiate the Package target. That way we transform everything according to environment, but do not need to have empty license in our project folder (prevents people from even building the solution in VS before retrieving a license).

Please login to comment.
Latest blogs
Join the Content Recommendations Work Smarter webinar May 8th 16.00-16.45 CET with expert Aidan Swain

Learn more about Content Recommendations, with Optimizely’s very own Senior Solutions consultant, Aidan Swain . He will discuss best practices and...

Karen McDougall | Apr 12, 2024

Plugin for Identifying and Bulk Deleting Orphaned Missing Properties in Optimizely

I am aware that the Optimizely World community has extensively discussed this topic, with numerous solutions and code snippets available to help...

Adnan Zameer | Apr 11, 2024 | Syndicated blog

Enhancing the Authoring Experience: Extending the LinkItem

The LinkItem field is one of the most demanded properties by the community, allowing editors to effortlessly create and manage links across pages a...

Santiago Morla | Apr 10, 2024 | Syndicated blog

The distinctions between Optimizely Web Experimentation and Optimizely Feature Experimentation

This blog is part of the series - Unlocking the Power of Experimentation: A Marketer's Insight. Let’s dive into Optimizely's powerful experimentati...

Holly Quilter | Apr 9, 2024

Optimizely SaaS CMS: Balancing TCO and ROI in Your CMS Hosting Decision

With Optimizely SaaS CMS coming soon, I’ve been talking with companies about the tricky business of picking the right core system software for thei...

Johnny Mullaney | Apr 8, 2024 | Syndicated blog

What version of Optimizely CMS am I running?

Optimizely continually rolls out new features for CMS customers and these features are normally for the latest major version of Optimizely CMS (CMS...

David Knipe | Apr 8, 2024 | Syndicated blog