Workaround for Known Issue with TypeConverters in DSL Tools for Visual Studio
Tags: dotnet, dsl, orcas, visual studio, vsxAdd comments
When I tried to add a Domain Property with a custom TypeConverter to my Domain Class I ran into serious problems. Sometimes it worked and this property was shown correctly in the properties window using the custom TypeConverter, but sometimes not. I was desperately searching for a bug in my code for hours but then I figured out: Each first build after a solution cleanup was working and all other builds not. Even when I start the working build a second time without rebuilding it, the custom TypeConverter was not used.
This looks very much like the number 1.10 (the second 1.10 😉 ) in the known issues list posted on the VSX Team blog:
1.10 TypeConverters and TypeDescriptors are not picked up during the build process or during toolbox initialization.
When adding a custom TypeConverter or TypeDescriptor and then building the DSL, the TypeConvertor or TypeDescriptor is not picked up. The workaround is to rebuild the solution with a clean build.
And as you see: I discovered this workaround for myself, too. But I also found another workaround. I’m not sure if it is working for all situations with the described known issue but if you have the same problem you might want to try it. If it works or not, please comment some feedback here.
I simply used another constructor of the TypeConverterAttribute. Instead of providing the type information I used the constructor with a string:
// this one does not work:
[TypeConverter(typeof(DynamicPropertiesTypeConverter))]
// this one is not nice, but works:
[TypeConverter(“BenjaminSchroeter.DynamicPropertiesTypeConverter”)]
public class DynamicProperties : ICustomTypeDescriptor
February 17th, 2008 at 3:21 pm
[…] is a known issue and a workaround I described here with the TypeConverterAttribute and the DSL […]
March 24th, 2008 at 4:14 pm
Great page.., man
May 12th, 2008 at 6:50 am
[…] 1. Workaround for Known Issue with TypeConverters in DSL Tools for Visual Studio […]
July 19th, 2008 at 7:33 pm
[…] time ago I posted a workaround for this problem with the TypeConverter, but today a realized that this workaround does not work […]
January 19th, 2009 at 11:54 am
Hi
Good Article on Dynamic Property
I have some query about how to provide external Type as Type in AddProperty() method
DynamicPropertyCollection dpc=new DynamicPropertyCollection ();
dpc.Addproperty(“test”,typeof(TestClass), new TestClass())
when I close visual studio and open next time It never persist its value
but It work with string,Int,bool, Datetime object
Is there any solution for this scenario.
Thank You
January 27th, 2009 at 4:35 pm
Hi Atul
That scenario is in fact not supported at this time. I reproduced it and found a solution but I’m not sure how to build that solution into JaDAL. At the moment I will not do that, but I can tell you a way to use your own Classes with DynamicProperties.
First of all you have to implement a TypeConverter for your TestClass and use the TypeConverter-Attribute on the TestClass as well (please use the string overload instead of the typeof() version of that attribute). When persisting the TestClass, the TypeConverter will be used to create a string representation of its value. To create a new TestClass from that representation when loading it is used too. For an example take a look at the DynamicProperty-CollectionTypeConverter.cs file from the JaDAL source code.
Now the values will be stored in the file when saving the DSL model but there is still a problem when loading the file: the class TestClass is not known by the DynamicProperty system and cannot be created. One solution is, to add your TestClass to the JaDAL assembly (or take the DynamicProperty code into your DSL assembly).
Another solution is to change the code saving the TestClass to use the AssemblyQualifiedName instead of the namespace + class name. Now the TestClass can be created but if you change the version or public key of your assembly, old files cannot longer be loaded (since the public key and the version are part of the AssemblyQualifiedName). If you prefer that solution, you have to change the source code of JaDAL a little bit: In the DynamicPropertyCollectionTypeConverter class there is a line
> attr = new XAttribute(“type_” + i, property.Type.ToString());
change it to
> attr = new XAttribute(“type_” + i, property.Type.AssemblyQualifiedName);
Maybe you should add an if statement to use the first way for classes from mscorelib and from the JaDAL assembly and use the second way only for your own classes.
If you have some more questions, do not hesitate to write me an email or a comment on the blog.