Introduction
Windows Workflow Foundation (WF) comes with a very cool UITypeEditor
that allows selection of a type in the current project or any of its references:
Its type is System.Workflow.ComponentModel.Design.TypeBrowserEditor
defined in the System.Workflow.ComponentModel.dll assembly. However, if you try to "attach" it directly to one of your component's properties, you will get an error saying "The service 'System.Workflow.ComponentModel.Compiler.ITypeProvider' must be installed for this operation to suceed. Ensure that this service is available.":
Being a general fan of the Component Model, I knew what this was about, and started working on providing the WF type browser editor with the services it needs. Here are the implementation steps I used to get it to work:
- It was obvious that I could not use the editor as-is, so the first step was to create a custom
UITypeEditor
that would call the TypeBrowserEditor
in WF:
public class TypeBrowser : UITypeEditor
{
TypeBrowserEditor editor = new TypeBrowserEditor();
ContextProxy flyweight;
public override object EditValue(ITypeDescriptorContext context,
IServiceProvider provider, object value)
{
if (flyweight == null)
{
flyweight = new ContextProxy(context);
}
else
{
flyweight.SetContext(context);
}
return editor.EditValue(flyweight, flyweight, value);
}
public override UITypeEditorEditStyle
GetEditStyle(ITypeDescriptorContext typeDescriptorContext)
{
return editor.GetEditStyle(typeDescriptorContext);
}
}
- The code highlighted above shows that I'm passing a custom
ITypeDescriptorContext
to the WF editor. This custom context acts as a proxy to the real one received by the editor, and allows me to provide the additional services required by it. It provides the only service required for the editor to work, ITypeProvider
:
private class ContextProxy : ITypeDescriptorContext
{
ITypeProvider typeProvider;
ITypeDescriptorContext realContext;
public ContextProxy(ITypeDescriptorContext realContext)
{
this.realContext = realContext;
}
internal void SetContext(ITypeDescriptorContext realContext)
{
this.realContext = realContext;
}
#region ITypeDescriptorContext Members
...
#endregion
#region IServiceProvider Members
public object GetService(Type serviceType)
{
if (serviceType == typeof(ITypeProvider))
{
if (typeProvider == null)
typeProvider = new CustomTypeProvider(this);
return typeProvider;
}
return realContext.GetService(serviceType);
}
#endregion
}
- The custom
ITypeProvider
instantiated and returned from the GetService
call must give the browser the list of types available in the current project. For that, I took advantage of the VS-provided DynamicTypeService
and ITypeDiscoveryService
, as explained in my previous post:
private class CustomTypeProvider : ITypeProvider
{
Dictionary<string, Type> availableTypes;
public CustomTypeProvider(IServiceProvider provider)
{
DynamicTypeService typeService =
(DynamicTypeService)provider.GetService(
typeof(DynamicTypeService));
Debug.Assert(typeService != null,
"No dynamic type service registered.");
IVsHierarchy hier = VsHelper.GetCurrentHierarchy(provider);
Debug.Assert(hier != null,
"No active hierarchy is selected.");
ITypeDiscoveryService discovery =
typeService.GetTypeDiscoveryService(hier);
Project dteProject = VsHelper.ToDteProject(hier);
availableTypes = new Dictionary<string, Type>();
foreach (Type type in discovery.GetTypes(typeof(object), false))
{
if (!availableTypes.ContainsKey(type.FullName))
{
if (type.Assembly.GetName().Name !=
(string)dteProject.Properties.Item("AssemblyName").Value)
{
availableTypes.Add(type.FullName, type);
}
else
{
availableTypes.Add(type.FullName,
new ProjectType(type));
}
}
}
}
}
From that point on, all the ITypeProvider
members use the availableTypes
field for their implementation. The only caveat was that apparently the WF type browser determines that a type belongs to the current project by the presence of a null value in its Assembly
property. However, the VS built-in ITypeDiscoveryService
gives you fully loaded types, complete with the Assembly
property and everything, even for the ones in the current project. Hence, the code above detects if the assembly of a type matches the current, and adds to the list a System.Reflection.TypeDelegator
-derived class (ProjectType
above) instead of the real type:
if (type.Assembly.GetName().Name !=
(string)dteProject.Properties.Item("AssemblyName").Value)
{
availableTypes.Add(type.FullName, type);
}
else
{
availableTypes.Add(type.FullName, new ProjectType(type));
}
The TypeDelegator
class is a not-so-known type that allows a very elegant way to proxy calls to the Type
it's delegating to, effectively allowing a kind of reflection interception. This interception is almost transparent, save for the creation of the type delegator with the real Type
, as the delegator inherits from Type
itself. My delegator is simple, and provides what the WF browser expects: a null value for the Assembly
property:
private class ProjectType : TypeDelegator
{
public ProjectType(Type delegatingType) : base(delegatingType) { }
public override Assembly Assembly
{
get { return null; }
}
}
So the relevant members of the ITypeProvider
interface take into account this trick as follows:
#region ITypeProvider Members
public Type GetType(string name, bool throwOnError)
{
if (String.IsNullOrEmpty(name))
{
return null;
}
if (availableTypes.ContainsKey(name))
{
Type type = availableTypes[name];
if (type is TypeDelegator)
{
return ((TypeDelegator)type).UnderlyingSystemType;
}
else
{
return type;
}
}
else
{
if (throwOnError)
{
throw new TypeLoadException();
}
else
{
return null;
}
}
}
public Type GetType(string name)
{
return GetType(name, false);
}
public Type[] GetTypes()
{
Type[] result = new Type[availableTypes.Count];
availableTypes.Values.CopyTo(result, 0);
return result;
}
The GetType
method is called by the WF browser when you select a type in the listview, and for setting the final return value. So, I achieve the browser requirements for display, but get a fully qualified type name (or the type itself, depending on the type of the property/value being edited) as an output.
With that code in-place, you can simply annotate your component members as follows:
public partial class MyComponent : Component
{
public MyComponent()
{
InitializeComponent();
}
public MyComponent(IContainer container)
{
container.Add(this);
InitializeComponent();
}
private Type someType;
[Editor(typeof(TypeBrowser), typeof(UITypeEditor))]
public Type DataContractType
{
get { return someType; }
set { someType = value; }
}
}
This could also be a property on a user control, of course. With this simple attribute, you can now get the cool WF type editor for your property too:
In the above screenshot, you see:
- A simple Class Library project containing a component that launches the WF type browser (no need for a WF project!!!).
- The component we showed previously in source form, being dropped on a WinForm, and its
DataContractType
property having the "..." for launching the editor. - The editor with the proper value selected (the one that was already set on the property) as well as the property in the property grid reflecting this value (serialization to code works flawlessly).
What you also see above that I have not explained yet is how to filter the dialog. In the screenshot, you see a custom label with the text "Showing types that have DataContractAttribute.", and also from all the types defined in the project or its references, only a few are shown in the treeview/listview. You can achieve this by providing custom filters that implement the ITypeFilterProvider
interface. For example, the filter in action above is coded as follows:
public class DataContractFilter : ITypeFilterProvider
{
public DataContractFilter()
{
}
public DataContractFilter(IServiceProvider provider)
{
}
#region ITypeFilterProvider Members
public bool CanFilterType(Type type, bool throwOnError)
{
bool isDataContract = type.IsPublic &&
Attribute.IsDefined(type, typeof(DataContractAttribute));
if (throwOnError && !isDataContract)
{
throw new ArgumentException("Type is not a data contract.");
}
return isDataContract;
}
public string FilterDescription
{
get { return "types that have DataContractAttribute"; }
}
#endregion
}
Finally, you apply the filter to your property with another attribute:
[TypeFilterProvider(typeof(DataContractFilter))]
[Editor(typeof(TypeBrowser), typeof(UITypeEditor))]
public Type DataContractType
It took quite some time and reflecting, but I'm very satisfied with the result :D
Enjoy!
Related readings
History
- 2007-02-12: Updated source code
- 2007-01-31: Updated for .NET 3.0 RTM.
- 2006-10-01: Initial version complete with support for filters.