The Tridion Event System is used to automatically perform actions for us when an event is ‘triggered’, such as saving a Component or Publishing a page. While programming our Event System solutions we sometimes need to specify the name of a Schema, WebDAV URL path of a Component, or (gasp) a Tridion URI. We don’t want this in our code and it’s better to have it in a config file. However, the Event System is a ‘Class’ project type, and we can’t simply put an app.config file in the folder and expect it to work. In this article I’ll show a small code sample that will allow you to read values from a config file.
This original code comes from the Mihai’s Google Code solution here: https://code.google.com/p/yet-another-tridion-blog/source/browse/trunk/Yet+Another+Event+System/Com.Mitza.YAES/ConfigurationManager.cs
However, in Mihai’s article the code is fairly complex and has lots of functionality I didn’t need, and instead I prefer a more simple approach for getting the config file and getting a key. So, I’ve give the code a haircut and present to you just the bits you need to store the config values outside the Event System.
1. Create a config file and add your appSettings:
2. Name the configuration file the same as the Event System DLL with ‘.config’ at the end. Put the config file in the same place as the DLL. This might be in the Debug folder on your Dev system or in the Bin folder on the Tridion server. For example, TridionEventSystem.dll.config
Use the GetAppSetting(keyName) method to get your app.config variables.
If in your Event System code you use static variables they will be “cached” and stay in Scope as long as the Event System is running. If you restart the TCM Service Host and TCM Publisher services then the static variables will be refreshed.
I also use the .Net ObjectCache in the code to cache the values and this would be helpful in case your variables are not static in the Event System class.
Finally, a small note, but the Tridion Event System likes to have 1 DLL, so if you reference any external libraries, or if you create many .Net projects with the solution (that produce their own DLLs) then you will need to put those DLLs in the GAC or use ILMerge to combine them. So, in that case, when possible, use 1 .Net project for the Event System and minimize the abstraction of the layers into their own .Net projects, as is often done with .Net solutions. For example, I created a ‘Model’ .Net project for the Models to share between the Event System and another project, but in the end this proved to be too much of a headache and instead I moved the Models into the Event System project.
Happy healthy hacking!