Accessing the App_Code folder

Since all the classes under the App_Code folder are compiled to an assembly with random name placed under the Temporary ASP.NET Files folder, you are not able to use these classes from an assembly compiled to the bin folder. Let’s assume that we need to create a workflow action class that will communicate with the classes from the App_Code folder. The solution here is to create a workflow action code that will iterate through all the assemblies loaded to the current application domain and find the instance of the necessary class from the App_Code folder and call the Process method. public class CustomAction { static Hashtable table = new Hashtable(); static Type LookupType(string name) { Type result = null; lock (table) { result = table[name] as Type; } if (result == null) { foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies()) { result = assembly.GetType(name); if (result != null) { lock (table) { table[name] = result; } break; } } } return result; } public void Process(WorkflowPipelineArgs args) { ProcessorItem processor = args.ProcessorItem; object instance = ReflectionUtil.CreateObject(LookupType(processor.InnerItem.Fields["dynamictype"].Value), new object[0]); ReflectionUtil.CallMethod(instance, "Process", new object[] { args }); } } As can be seen from the code above, the name of the type that we search for is retrieved from the Action item (dynamictype field): The Type string field contains the reference to the action class compiled to the bin folder. In order to add the DynamicType field to the Action template, you should create a new template e.g. named Dynamic Type by inheriting from the existing Action template and add this new field. You may also want to create a master from this template.

---

Update: Thanks to Ole, starting with 5.3 BETA 060825 we have made reflection work with App_Code. Therefore, custom processors in App_Code simply work out of the box. In the processor definition, simply leave out the assembly part of the type string: