none
Locking down code-behind? RRS feed

  • Question

  • Is it possible to lock down code-behind in a xaml.cs file, so that a designer can't change it or insert malicious code?

    I am building a WPF app whose UI is isolated in a separate DLL (essentially, a WPF control project). This approach limits what the designer sees of the application. The UI and the application back-end are connected by an API, which the UI code-behind implements. The XAML is data-bound to the code-behind, which simply passes data on to the back-end, and vice versa.

    Operating under the theory that only the paranoid survive, I want to further limit what the designer can do. I want to completely prevent them from making any changes to the code-behind. I want to completely lock down the code-behind so that all a designer can do is create XAML and resources, and data-bind to the existing code-behind.

    Is there any way to do this, or am I forced to diff-check every code-behind file after the designer is done?

    BTW, I am aware that development of a UI should be a collaborative effort between a developer, a designer, and a user, but designers are going to have access to this app after the development is done. I'm trying to prevent after-the-fact designer changes that I end up getting blamed for. So, when the collaboration is done, I want to lock down the code-behind. Is that possible? Thanks

    David Veeneman
    Foresight Systems

    Sunday, February 22, 2009 2:25 PM

Answers

  • Rather than databinding to the code-behind, use the MVVM pattern to pull the UI Logic into a separate assembly. Josh Smith wrote an excellent article on MVVM in February's MSDN Magazine, and Shawn Wildermuth followed up this month with an article on MVVM in Silverlight. If you package the ViewModel in a separate assembly all that the designer can do is bind to it. Well they can do other stuff...but it would be evident where the issue lies, which is what you want.
    Keep your head in the Clouds as you're coding .NET http://azurecoding.net
    • Marked as answer by David Veeneman Sunday, February 22, 2009 3:59 PM
    Sunday, February 22, 2009 3:58 PM
    Moderator

All replies