[Update Jan 04, 2008: Made <system.codedom> instructions more clear. Thanks to Cory Bloyd for the suggestion.]
If you've had the opportunity to work with WPF/.NET 3.0 yet, you've likely run into the x:Class attribute in XAML. If you specify a x:Class on a XAML page, during compilation the XAML compiler creates a class in code using the registered CodeDomProvider for the given language that you're compiling. This presented some challenges for getting the IronPython sample to work with the new designer. There were two major problems:
For the first issue, the most simple and reliable way to do this is simply have the user of the sample manually register the IronPython CodeDomProvider in your machine.config file. Here are the instructions from the ReadMe to get this working:
When building an IronPython WPF Application, you may receive the following error message: Unknown build error, 'Object reference not set to an instance of an object'. In order for XAML compilation to succeed, a valid CodeDomProvider is required to be registered on the machine for the language being compiled. Because this is a global machine configuration setting, the IronPython sample does not attempt to register the IronPython CodeDomProvider automatically. In order to register the IronPython CodeDomProvider manually and build IronPython/WPF projects with Visual Studio or MSBuild, you can do the following:
For the second issue, we had to be a little more creative. By default, the WPF Designer (code-named Cider) will attempt to use a CodeDomProvider to do event handler generation if you have one for your language. In fact, if you have a CodeDomProvider that is good enough to work with Windows Forms and you support static .NET type compilation, you should be able to get the WPF designer working with almost no problems.
Fortunately, Cider also supports an extensibility mechanism in case you don't provide a CodeDom and wish to override the event handler generation. To do this, you need to implement a custom EventBindingProvider. The one that is included in the IronPython sample is called PythonEventBindingProvider. It should be noted that for most languages, you don't need to write your own EventBindingProvider like we did for IronPython. We only did this for Python to work around the static compilation issue.