This post originated from an RSS feed registered with .NET Buzz
by Peter van Ooijen.
Original Post: Working with .NET 3.0
Feed Title: Peter's Gekko
Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx
Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general.
Over the last days I've been working with the .NET 3.0 framework (or whatever you want to call it). Starting from the perspective of a real world application, not a bunch of cool solutions looking for a problem. The idea was to create a WPF tablet PC inking app which stores and retrieves images through a WCF webservice. It worked out pretty well, of course with some beta bumps, and I would like to share some of my findings. These are based on the "official" Vista beta2 and the current CTP of WinFx..
Which platform to use as development platform
The 3.0 framework is the API to build apps for Vista. But using Vista as a development platform is a different ballgame. Building the presentation part works like a charm but building services on Vista is no fun. Vista is far stricter in rights than XP, to circumvent that you can start a program, including Visual Studio, as administrator. But whatever I tried I never managed to create a new service under Vista. The best result was a dialog like this.
Which looks like old horror in a new coat. I gave up and went on using XP as a development platform. After all not a big deal. One of the nice things of .NET 3.0 is that it also runs on XP and server 2003. This separates the development and deployment of Vista applications from the Vista OS and does make the migration path easier.
Hosting services
There are several ways to host a service and the VS additions provide several templates for that. I used the WinFx website template which works pretty well. The template generates a skeleton service including a description of the configuration in the comments. You can also add a service to an existing Windows (WPF) or console application, in this scenario the application itself will host the service. The VS additions contain templates for these which spit out another variation of a skeleton service with another configuration in the comments. The configuration settings for a service have changed over the last releases of WCF, the bad thing is that the configuration settings generated for a self hosted service are those of a previous version. Nevertheless, after some fiddling I managed to get a WPF hosted service up and running. The bad thing is that trying to generate a proxy to consume the service, I encountered a bunch of quite exotic error messages. MSN search was blank on them, Google found them in a couple of very deep digging MS blogs; all of them were security related. My conclusion was to stay from all of this till I have a huge amount of spare time or a new release of the framework. But the IIS hosted service worked well and was a pleasure to work with.
WPF
I can be quite short on WPF: it's a plain delight. The additions give you three views on a wpf-form: a visual designer, a XAML markup view and the code-behind. My advice is to forget about the visual designer. Dropping and dragging components from the toolbox will leave you with fixed layout forms and markup which is complete spoiled with unnecessary attributes. Imho WPF is a way to get rid of hard to design fixed layout winforms and brings the ease of flowing web-layout to Windows apps. Besides that the visual designer will give up on you sooner or later. When the markup needs members from the code-behind, for instance for a custom command, you have to add your assembly to the namespaces of the markup. The problem is that the designer is not able to find this assembly and will quit on you. The error message is nice though:
Resharper has a similar problem with XAML. In the build process out of the XAML an assembly is generated. But in the code editor this assembly is not available yet, as a result Resharper will mark all xaml components in red and fails on code-completing the objects. But it doesn't crash.
Tablet PC
Tablet PC functionality is integrated in .NET 3.0. You no longer need to install the Tablet PC SDK to develop Ink aware applications, it's all in the InkCanvas control. Inking itself is also far better integrated into the runtime. You will notice this when drawing with a mouse. This is far smoother than the former, COM based, tablet runtime. Tablet code is not source code compatible with the old API. The architecture and spirit of the API is the same but a lot of methods have new overloads, encapsulating the old versions. Also the Ink property has disappeared, the collection of strokes itself is a main property of the InkCanvas.
To conclude
The result is an application which could have been built using classic asmx webservices and classic webforms. As a matter of fact I had already done that some time ago. But building the apps this way required less and clearer code. And the possibilities to add cool things to the app are enormous. For instance I would like to add peer to peer picture exchange using a self hosted service. Which would have been quite difficult to implement using the classic tools. Now it seems just a bug-fix away. I'm really looking forward to a next release.
Previous Topic
