1. Sometimes I feel that designers are evil. While I understand your choice, and perhaps would have done the same, you break the DRY principle just because the designer support is lacking.

    I’m ready for assembly programming! Who’s with me?


  2. I've experienced just that while working on my project trying to get some cool stuff to work with a workflow that can be designed by the user. Instead of a generics problem, I had a designer that didn't support my custom setstate activity inside a windows workflow foundation statemachine.

    Designers are evil, especially when you are doing some special stuff to the classes that the designer relies upon.

    Lets ditch the designer and go for a rather explosive mix of LINQ, generics and anonymous types. Gotta love new features ๐Ÿ˜€


  3. From what I have seen so far the designers of Workflow foundation add little but the illusion that things are simpler than they actually are, in my opinion this is a bad thing.

    For a GUI however the grapical representation does has the added value in that it shows you how the actual User interface will look like at runtime (more or less), this is a good thing, as long as it works.

    I concur with Willem that powerfull language features will allways beat designers!


  4. The WF-designer is a perfect example of an unfinished product being released, probably because commercial management couldn’t wait any longer.

    Same for the standard activities, which are all marked sealed: “though we would like make our product as extensible as possible, we had to prioritize where we’d focus this extensibility for this version and we decided to focus at the component model level, instead of on the out-of-box activities.”. ๐Ÿ™


  5. Frank ,
    Nice trick, I thought this “bug” had been fixed in vs.net 2008 but i’ve just hit the same limitation.Your trick works great.


    Sebastian Talamoni

  6. I created a generic combo box which greatly simplified my code. But I nearly put my fist through my monitor when the WF designer choked on it. Your trick saved the day. Thanks!


  7. Nice workaround. I can live with it, but still there might be problem again. Localize your base control and you’ll get in your designer file line such:

    System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager( typeof( UserControl1 ) );

    Well, we don’t have UserControl1 class anymore, so we have to change it to UserControl1. Now we can compile and open designer for that View, but … try to open inherited hacked UserControl2. You’ll get something like:

    Could not find any resources appropriate for the specified culture or the neutral culture. Make sure “WindowsFormsTesting.UserControl1`1.resources” was correctly embedded or linked into assembly “WindowsFormsTesting” at compile time, or that all the satellite assemblies required are loadable and fully signed.

    So, any ideas how to solve this new problem?



  8. I've just figured out one mistyping. This is correction with forgotten generics:

    "Well, we don't have UserControl1 class anymore, so we have to change it to UserControl1<T>"


  9. I am afraid I can't give you a direct answer to that one. As discussed before designers are not allways my best friends ๐Ÿ™‚


  10. This is annoying to deal with but I'm surprised that you opted to duplicate code instead of using the workaround you outlined above if it worked for your scenario – I'm guessing the amount of code was smaller than the signature of the dummy class.

    Here is an article that articulates some of the options the VS.NET team considered before coming to the conclusion that it could not be supported.


    Matthew Erwin

Comments are closed.