Yet Another Tridion Blog

A Bit of Background TcmUploadAssembly.exe is a utility program that allows you to upload a DLL into the SDL Tridion Content Manager. It does the following: Create a TBB (of type .NET Assembly ) that holds the actual .NET DLL; Create a TBB (of type C# Code Fragment ) for each class in the .NET DLL that implements the ITemplate interface; Optionally, creates Parameter Schemas and associates them with the individual template TBBs; Optionally, uploads the PDB corresponding to the .NET DLL; The following command line arguments are accepted: Usage: TcmUploadAssembly [options] [ConfigurationFilePath] [AssemblyPath]   ConfigurationFilePath    The location where the configuration file for this                            tool can be found.   AssemblyPath             The location of the assembly to be uploaded. Basic Options:   /verbose                 Output extra debug information.   /help                    Print this message. Overriding Options (overriding eithe

This topic touches on hot Tridion practices, both of them debatable: Publishing from Template code; Impersonating a user in Template code; I won't go into the debate (maybe I'll write about it at a later stage). I will just say that I don't find it bad practice to impersonate in templates, hence the code and topic below. The use case for "publishing from template code" comes mainly when dealing with Multimedia Components that need to be published also as Dynamic Component Presentations (DCPs). If they weren't publish from template code, you would either have to publish them manually or from some event system. I think both alternatives are clumsy and less suitable than the publish from template code. So, my requirement is to issue a Publish on a given Tridion item from template code. The publish should have the same properties as the original item (the one currently being rendered by templates). So, the same target, user, and priority. First,

This topic has been asked recently on StackOverflow. The question was how to create a Folder (or actually a series of nested Folders) like  /aaa/bbb/ccc/ddd  using the Core Service in Tridion 2011SP1? The answer is you have to create each individual Folder as a sub-folder of an existing parent. This means the approach is very well suited to be handled with a recursive call. I created a method called GetOrCreate(path) that checks if the path exists. If it does, it returns the FolderData object. Otherwise, it splits the path into a parent path and a new folder name and applies recursion on the parent path. On the way out of the recursion, the new folders are created as children of the (by now) existing parents. private FolderData GetOrCreateFolder( string folderPath, SessionAwareCoreServiceClient client) {     ReadOptions readOptions = new ReadOptions ();     if (client.IsExistingObject(folderPath))     {         return client.Read(folderPath, readOptions) as

There are times when you need to create a new Session (i.e. Tridion.ContentManager.Session ) in TOM.NET. This is considered bad practice, for reasons I'm not going to dwelve into here. By default, when attempting to create a new instance (e.g. Session session = new Session() ),  you get a run-time exception:  The type initializer for 'Tridion.Localization.StringResourceManager' threw an exception . This can be fixed by referring to the Tridion.ContentManager.config file from your application's app.config , web.config , or DLL.config . Make sure your config contains at least the following lines: <? xml version = " 1.0 " encoding = " utf-8 " ?> < configuration >     < configSections >         < section name = " tridionConfigSections " type = " Tridion.Configuration.ConfigurationSections, Tridion.Common, Version=3.0.0.211, Culture=neutral, PublicKeyToken=349a39f202fa9b53 " />     </ co

This topic is not new. It comes back regularly, pretty much with every single enterprise client I have implemented. "Why do we need different Deployers for different file systems?". "Why can't just Tridion publish to different file systems?". And so on... Recently, it came up again, so I setup a small PoC to see how feasible it is to write a Storage Extension (in SDL Tridion 2011SP1) that would perform the typical CRUD operations a Deployer would perform, only on multiple file systems. The idea behind the storage extension is to have several file systems defined in the cd_storage_conf.xml that would be grouped under one logical name. Then have an item type mapping (e.g. Page) that would point to the group of file system. The goal is to have that item type created, updated, removed, etc on each of the file systems defined in the group. The cd_storage_conf.xml  Storages node would look something like this:     < Storage Type = "filesystem"

It seems like this use case keeps coming back time and time again. The requirement: when a new Component is in workflow, part of the approval workflow on the Component should be an automatic Page generation (where the Component is placed on the Page) and possibly publishing of the Page for the purpose of previewing the new Component in a Page context. All this while Component is in workflow, so approver can actually see how the Component looks like before approving/rejecting it. The only issue, as described in the previous post, is that it is not possible to add a v0.x Component to a Page, when the Page is in a child Publication. The solution is to do all this programmatically. In the following example, I use the Core Service to create a new Page (with values taken from a Folder metadata, for example) and place the v0.x Component on it. using ( CoreServiceSession coreService = new CoreServiceSession ()) {      if (component.Version < 1)     {          Tcm

I was playing around a while ago with some Components in Workflow, in Blueprinted situation, when I noticed some strange behaviour. I was trying to place a v0.x Component (in Workflow) on a Page in a child Publication -- can't do. I was publishing a Component linking to a Component in Workflow. It works, but it will use the values from the last saved 'link-to' Component -- makes sense. But even when publishing with ActivateBlueprint=true, still the last major version of the 'link-to' Component was used. This all triggered me to summarize these weird cases, as follows: A _ new _ Component (version 0.x) in workflow: is visible in its own and child Publications (GUI & API); can be published in its own and/or child Publication (GUI & API using the “ActivateWorkflow” flag). Publishing follows most of the rules we know (DCPs get published, Page republished if published previously), but some don’t actually work as expected: Components “linking-to” the Co

The following code sample shows how to read the next ActivityInstance in a workflow. Mind you that for this to work, the current Activity has to be finished. Only then a next Activity Instance is created, and can thus be retrieved: /// <summary> /// Get the next ActivityInstance, if there is one. If the current Activity has not finished, there is no next activity. /// </summary> /// <returns></returns> protected ActivityInstance GetNextActivityInstance() {      ActivityInstance activityInstance = CurrentWorkItem.Activity as ActivityInstance ;      ProcessInstance processInstance = activityInstance.Process as ProcessInstance ;      IList < ActivityInstance > activities = new List < ActivityInstance >(processInstance.Activities);      if (activityInstance.Position < activities.Count) { //Position is 1-based          return activities[activityInstance.Position];     } else {          return null ;     }