Code 2 Develop

Although the WindowsFormsIntegration dll provides some functionality to provide interop between winforms and WPF, there are some other possibilities. ElementHost allows you to host WPF elements in your winform app and WindowsFormsHost allows you to host winform controls in your WPF application. But what if you would like to add a complete form to your winform app? What I did was to write a WPFRuntime class which helps you to display WPF windows from within a windows application. The class starts a new thread that runs the WPF application runtime with the help of a hidden window. Then you have some methods that ask the WPF application dispatcher to show a window of the type you provided. This allows you to create new windows entirely in WPF and still host them in a legacy winform application. The class might need some extensions to provide parameters to a window for instance but that is for a later time perhaps. You can find the demo code here

When you use blend on a HP computer, it could happen that your designer can't show any XAML files. You always get an error like 'The name "..." does not exist in the namespace
"http://schemas.microsoft.com/winfx/2006/xaml/presentation"'. After searching for quite a while I discovered this was due to an environment variable. Some HP systems set a PLATFORM environment variable to e.g. MCD or HP. This causes MSBuild (and for that matter also blend and Visual Studio) to use that platform as the target platform in stead of 'Any CPU'. Remove the environment variable and the problem should be resolved.

Today I was running a demo on WCF duplex communication with wsDualHttpBinding. My demo was pretty basic so it was created through standard stuff. I created the demo in VS2005 running on Vista. I distributed the sample and when people ran it on Windows XP the client terminated with the error: "HTTP could not register URL
htp://+:80/Temporary_Listen_Addresses/ because TCP port 80 is being used by another application.". At first this seemed odd to me because I was wondering why the client tried to communicate on port 80. I am/was used to programming with sockets and remoting where client picked a random free port to establish communication from server to client. Apparently WCF creates a HTTP socket on port 80 to service client callbacks. Clearly the client was conflicting with IIS on XP while this was not the case on Vista. This behavior is due to the nature of the architecture of IIS 6.X and IIS 7. All HTTP-protocol traffic in IIS6.X/7 gets routed through the http.sys, kernel mode component. Even when you create a selfhosted application or client which uses http, the traffic gets routed through http.sys. http.sys dispatches all requests to a worker process, so all that http.sys had to do is send the request to our client application in stead of the default w3wp.exe IIS worker process. XP still uses IIS 5.X, whom doesn't have this kernel architecture, so trying to open an additional socket on port 80 clearly conflicts with IIS 5.X. To resolve this problem you have to provide a clientBaseAddress in the binding configuration on the client.



Also testing multiple clients on XP this way isn't really feasable. You will have to provide the clientBaseAddress in code and associate a different port with each client.

For more information see the hosting services article and the duplex services article on msdn