Using the Core Service we can easily get a list of all the Publish Targets in the system. We might want to do this if we are creating an app to publish items to a target (like the publish window) or if we want to Decommission a Publication Target in an environment, such as when we restore a database from one environment to the next.

The following code will get a list of all PublishTargets available within the context of a Publication. If you want to get all targets in the system then using the Admin user is the best. However, if you want to use the logged on user, then see my previous article to use the Core Service as the authenticated user (for a web app).

The data returned from the GetSystemWideList call changed between 2011 and 2013, and with the code below you will get all the info from the 2013 method. Special thanks to Likhan for the tip on the Tridion StackExchange.

The Tridion Core Service is a powerful API that gives us access to everything in the Tridion system. Sometimes we want to use an account with Admin permissions to get lists of items or delete items, for example. However, when creating or publishing items, we often want to do this in the context of the user logged into our Web Application built with the Core Service. This article is going to explain how to use the logged in user to perform Core Service actions and also give you a small debugging tip for Visual Studio.

Creating the Core Service Connection

I use a SessionAwareCoreService client which allows me to impersonate the user only with the username and not requiring a password. However, we do need port 2660 open between my local Visual Studio instance and the server if I debug against the server. Otherwise, if I work on my own local Virtual Machine with Tridion installed, I do not need to worry about this limitation. Then, after deploying to the server, it will work as expected.


Making it work in Visual Studio

This user is normally empty when debugging in Visual Studio and this caused a small issue for me. Luckily, I found this great StackOverflow post explaining the solution. The one that worked for me is this:

“look at the properties of the web project, hit F4 to get the project properties when you have the top level of the project selected. Do not right click on the project and select properties, this is something entirely different.

Change Anonymous Authentication to be Disabled and Windows Authentication to be Enabled.”

Happy Core Service hacking!

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:

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.

External Libraries

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!