U.Seung's Log

1 Event handling generation

Because IronPython is a dynamic language, event handling generation is not implemented like it is in static languages such as C#. The primary problem is that the IronPython compiler does not produce strongly typed assemblies. Therefore, for WPF, static-language-like event handling creation cannot be illustrated at compile time. Instead, custom event handling is implemented by wiring the event handling code to the compiled XAML.

For the WPF designer to instantiate a custom EventBindingProvider, the type (for example, PythonEventBindingProvider) must be on a path in the registered .NET AssemblyFolders. As a post-build step, PythonProject.csproj registers its output folder as an AssemblyFolder to meet this requirement.

2 IronPython/WPF CodeDom registration issue

When you build an IronPython WPF application, you may receive the following error message: Unknown build error, 'Object reference not set to an instance of an object'? For XAML compilation to succeed, a valid CodeDomProvider for the language being compiled must be registered on the computer. Because this is a global machine configuration setting, the IronPython sample does not try to register the IronPython CodeDomProvider automatically. To register the IronPython CodeDomProvider manually and build IronPython/WPF projects by using Visual Studio or MSBuild, do the following things:

Open %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config in a text editor (such as Notepad).
To register the IronPython CodeDomProvider, under the root <configuration> node add the following items:
<system.codedom>
<compilers>
<compiler language="py;IronPython" extension=".py" type="IronPython.CodeDom.PythonProvider, IronPython, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</compilers>
</system.codedom>
Close and save machine.config