My latest publishing project, which I haven't talked about much on the blog, is a LiveLesson training DVD on WF. This product has now released and you can find all the details here:

http://www.awprofessional.com/title/0321503139

It contains about 5 hours of video instruction on the breadth of WF, including sequential workflows, state machine workflows, showing how to use each of the base activity library activities, how to communicate with workflows, how to handle exceptions, custom activities, and much more. Because of the length of the instruction, it is more of a shallow dive into each of the topics to get you started, rather than being very deep in any one area. The content is mostly Camtasia screen capture while demonstrating the techniques being discussed.

There is also a sample lesson available through YouTube:

http://www.youtube.com/livelessons

If you are getting started using WF, this would be a good way to get bootstrapped.

Spread the word!

I gave a talk on WPF for ASP.NET developers this evening at the .NET SIG in Cleveland. Good size crowd and great questions. It was a challenging talk because of trying to cover all of WPF and Silverlight for ASP.NET developers and for those in the crowd who were Windows Forms developers.

I covered the various deployment models of WPF including:

- Windows Application

- XAML Browser Application (XBAP)

- Plain Old XAML Page (POXP?)

- Silverlight App

Whenever I present this stuff, the overwhelming reaction is: Stop giving us so many choices!!! We can't figure out what to use when!

There is also often a desire for a conclusion to be drawn that one of these will be the end state and all UI will be written in it. I just don't think that will be the case. I think that maybe 5 years from now, if the tools come along a lot farther than they are now, and if the control suite grows, the list of options could shorten to just WPF Windows App, Silverlight App, and ASP.NET AJAX app. But I don't think it will shrink beyond that. Windows Apps make sense when you control the desktop to take maximum advantage of the client platform and give the best user experience. Silverlight makes sense for broader reach while sticking to the same tools and programming models. ASP.NET AJAX will be broader still and will address the platforms that Silverlight can't reach, and will also (like Windows Forms) be more evolved for data over forms apps for a while to come.

Anyway, here are the slides and demos for those who are interested:

Slides    Demos

I've arrived in Orlando and am looking forward to giving my sessions tomorrow and Wed in the Visual Studio connections track. I'll be presenting the following sessions:

- WPF in Windows Forms and vice versa: This talk will cover the interop story for containing WPF controls in Windows Forms applications and Windows Forms controls in WPF applications. Quite a compelling story for migrating incrementally to WPF, but not without its share of pain points.

- Real World .NET 3.0 Smart Client Deployment: This is a modification of my Real World ClickOnce talk, covering the key aspects of ClickOnce deployment but with a slant towards the special considerations introduced by .NET 3.0 for security and WPF deployment models.

- Encapsulate Business Processes in Custom WF Activities: This talk covers how to create custom simple and composite WF activities and all the many things you need to take into consideration to make a robust, reusable activity.

This year the conferences is at the World Center Marriott, a change from the Hyatt Grand Regency of the last few years. Verdict is still out whether this is an improvement...

I've been doing a lot of WPF work lately and recently read Adam Nathan's WPF Unleashed to brush up on a few of the more advanced topics that I had not yet spent a lot of time on.

I can't say enough about how fantastic this book is. Never mind that it is extremely well written, easy to read, flows nicely, and yet is very dense in content. The organization is excellent and he wastes no time on fluff but gets right to the meat of what is different about WPF from Windows Forms or ASP.NET right up front.

Then the clincher - the ENTIRE BOOK IS IN COLOR! Code snippets, figures, Tips and FAQ callouts, everything. Naturally you would want some color for something that is all about rich graphics like WPF, but it didn't even occur to me how wonderful it would be to have the whole book in color until I experienced it. Now, it is like my first taste of a color monitor after years of green screens and greyscales - wow. It was a whole different experience and I don't want to go back to those black and white paper thingies. Alas, I think it will be quite some time before all programming books are in color, but it will be a happy day when they are.

A plea to all publishers: Please at least offer a color variant. I'll pay more!! It is worth it!

A word to Adam: Thanks for this great book. You have raised the bar for the rest of us authors.

I recorded a dnrTV with Carl a while back on WPF and it was posted last week. I'll be recording a part 2 this week so keep your eyes out for that. This episode gives a good overview of what programming WPF is like (for now until the tools evolve some more) and what the structure of a WPF application is. Part 2 will dive deeper into data binding, styles and resources, as well as a few other things.

Wow, is this really my first blog post this year? The year has started off busy busy busy.

But enough about me... this is about you! YOU need to come to the NOVA Code Camp on 14 April! YOU need to volunteer to speak if you have some knowledge you are willing to share with your fellow developers.

I hope to see you there.

Details: http://novacodecamp.org/

 

Another great conference complete. Around 5000 showed up and we had great feedback from the crowd that it was a good show. If you haven't been to connections before, you really should check it out.

I gave three talks this week. You can get the slides and demos for each below.

Real World ClickOnce:  Slides   Demos
Workflow Driven Windows Applications:  Slides   Demos
Implement a Data Layer with the VS 2005 DataSet Designer:  Slides   Demos

We (at IDesign (http://www.idesign.net)) are currently in the middle of a .NET 3.0 Roadshow (http://www.net3roadshow.com) across six cities in the U.S.

In the show, we cover a full day + 1 session of WCF, 2 sessions of WF, 1 session of CardSpace, and 1 session of WPF. I am doing the WF and WPF sessions.

A common question that is coming up is why this weighted mix instead of a more even spread of coverage?

It has nothing to do with the complexity of the topics. WF is equally as complex and capable for what it is designed to address as WCF is for its purposes. WPF is also very complex and capable. CardSpace has a much narrower focus than the others, but has a fair amount of complexity surrounding it as well.

The mix we came up with has a number of reasons behind it, but one of the most important factors was considering how many development organizations should be considering adoption of each technology at this point in time.

WCF is a remote communications platform that is rock solid, easy to use for simple scenarios, yet has a million knobs and dials that you can twiddle to address almost any remote communications needs. My perspective on WCF is that if you are writing any application from this day forward (even though WCF won't release until next month) that needs to make remote calls, you should be using WCF and forget that .NET Remoting, ASP.NET Web Services, and Enterprise Services exist. Obviously that has to be tempered with your ability to get .NET 3.0 deployed to the target platforms. But unless there is an unmovable roadblock to you doing that, it is worth your while to make the switch to WCF as soon as possible. Every application of any significant scale has at least a cross process hop to deal with somewhere in its architecture, and WCF works great for addressing those simple scenarios as well as full enterprise scale SOA apps. So I feel WCF should be adopted by most development organizations as soon as possible.

WF is an extremely capable platform for developing workflow driven processing in your enterprise applications. It is very stable and ready for adoption by those who need it. The only downside to WF is that because of some the capabilities that are built in to WF to address enterprise requirements (persistence, tracking, and scheduling to name a few), I don't think you can really say that simple scenarios are easy to implement with WF. So it takes fairly complex enterprise application requirements to justify the adoption of WF in your application. Additionally, not every application out there really has workflows of any significance (there are a lot of pure CRUD apps still out there). As a result, I think the number of development organizations that should be adopting WF at this time is smaller by at least 1/2 than those who should be looking at WCF.

WPF is a harder one to nail down, and my opinions are likely to incite some flames. I think that there are a lot fewer development organizations that should be bothering with WPF for the near future. The reason mainly has to do with productivity. Even though the runtime bits for WPF will be part of the .NET 3.0 release, the development tools for designing WPF UIs will not. Microsoft is hard at work on a WPF designer for Visual Studio that will hopefully release sometime next year. Alongside that effort is the Expression Suite that includes the Interactive Designer product for allowing designers to put together WPF UIs that they can hand over to developers to complete the hook up of the dynamic behaviors of the application from code. At this point in time and for at least the next 6 months, those products will only be available in a Beta form.

Even with the Visual Studio WPF designer, there is an awful lot missing at this point when compared to the Windows Forms or ASP.NET designers for rapidly designing and implementing UI applications. Even once they release next year, I suspect they will still feel like a v 1.0 designer. Think about how the Windows Forms designer in VS 2002 compares with the VS 2005 designer. Night and day in terms of productivity and producing good maintainable code. Hopefully the gap will not be that large. At the current time, if you want to write WPF apps, you will mostly be banging out XAML markup by hand (thankfully at least with some great intellisense assistance). The current CTP of the Visual Studio Orcas WPF designer does at least work pretty well for visualizing the result of your markup, but it is not really useful for doing a graphical drag/drop layout of your form nor for getting things like data bindings, styles, and resources hooked up.

You also have to consider how bad do you need/want what WPF offers. One of the biggest draws of WPF is that it allows you to write UI applications that are more visually compelling. In short, you could say WPF allows you to create eye-candy that you either couldn't do before or that was orders of magnitude harder to do. What you have to ask yourself is how bad you really need eye candy? If you are building consumer applications, then definitely eye candy is important. The difference between someone buying/using your app instead of your competitors is often a simple matter of whether they look at it, get a glazed look in their eye, and say "Keewwlll....." But if you are building internal enterprise business applications that show and manipulate data, do you really need pulsating 3D bar charts? Maybe, but it is a lot harder to sell that as a "requirement" than "I need my web server to be separated from my application server for security/scalability reasons" (i.e. I need WCF).

Don't get me wrong - I would love to incorporate many WPF features into every Windows app I build from today forward. Using things like styling and subtle opacity animations can make any application look better and more intuitive. Once you have adopted WPF, some of the other features of WPF such as the ability to use Style, Data, and Control Templates is very powerful and will be a welcome new model compared to Windows Forms. But the relative number of apps out there that really need embedded 3D modeling or video I think you can say is considerably less than the number of applications that need to do a cross process, machine, or network hop.

Compounding the problem is the fact that adopting WPF implies that you think you can get .NET 3.0 deployed to all of your client desktop machines to support your application. For an enterprise, that may be true if your organization is savvy about the benefits of adopting new technology and not overly paranoid about the risks of deploying a new version of the .NET Framework. For the open consumer market (yes, the primary ones who would drive you to want to incorporate eye-candy), that is going to be a much tougher nut to crack. For a back end server that you want to run WCF or WF on, having the control to deploy .NET 3.0 to that machine should be a lot easier to satisfy.

So as a result of the current maturity of the tools (equating directly to productivity), the relative importance of the completely new capabilities WPF provides compared to Windows Forms or ASP.NET, and the ability to guarantee that .NET 3.0 is installed on the client machine, I would say that a lot less people should be jumping on WPF for the near term. Once we have a good, near production designer for WPF apps in Visual Studio, my tune will change. Also, for those that really need some aspects of WPF now, by all means go for it. But my primary strategy for most smart client apps at this point would be to build it as a Windows Forms application to address the bulk of your requirements (and complete them in a reasonable timeframe), and then incorporate things like 3D, video, animations, etc. as needed using WPF controls embedded in the Windows application through interop (WPF controls can be hosted in a Windows Forms application and vice versa).

CardSpace's role in the mix is easier to address because it only really addresses one set of requirements: authentication and identity management. It does it well and provides a great new model for identity management that you should definitely be getting familiar with and thinking about how to incorporate it into your applications. CardSpace too faces some adoption challenges since it requires both a service or site that supports CardSpace and a client that has IE 7 or a smart client app designed to work with CardSpace. It definitely warranted coverage in the roadshow and Michele does an awesome session on it. But it definitely did not warrant more than one session compared to overall complexity and capabilities of the technology compared to WCF, WF, and WPF.

These were some of the considerations that drive the mix of sessions we are offering in the roadshow.

I'd be very interested in some comments on other perspectives on WCF, WPF, or WF adoption.

This week and next my colleagues Juval Lowy and Michele Leroux Bustamante (http://dasblonde.com) and I are conducting a two day seminar on .NET 3.0 development as a roadshow in 6 cities across the country (LA, San Jose, Chicago, DC, New York, and Boston). We have completed LA and San Jose with great feedback from the crowd and are in the middle of the Chicago show.

You can grab the slides and demos for my WF and WPF sessions here:   Slides    Demos
http://www.softinsight.com/downloads/NET30RoadShow/Slides.zip
http://www.softinsight.com/downloads/NET30RoadShow/democode.zip

In the WPF talk, I demonstrated several apps others have written that do a good job of displaying some of the awesome graphics capabilities of WPF. Those apps can be found through the links below. I also mentioned a great document for getting up to speed on WPF when you know Windows Forms 2.0 capabilities well. That link is below as well.

Enjoy!

Cine.View: A WPF viewing application that exposes the NetFlix catalog and ordering capabilities created by the thirteen23 company. They also have a great viewer for Flickr.
http://www.thirteen23.com/

New York Times Reader: A WPF content application that provides a rich browsing and reading experience for the paper's news content online in a Windows application.
http://firstlook.nytimes.com
 
Karen Corby's Woodgrove Finance application: This is a WPF XAML Browser application that provides rich visualization of stock market data in a multi-paned WPF app that runs in the browser.
http://scorbs.com/

Keep an eye on http://wpf.netfx3.com for some more upcoming samples that will wow your eyes.

The WPF for Windows Developers document from Mark Boulter and Jessica Fosler can be found on Jessica Fosler's blog:
http://blogs.msdn.com/jfoscoding/articles/765135.aspx

.NET 3.0 Release Candidate is out!! http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/

I gave a talk at the Greensville Spartanburg Developers Guild last night on Windows Workflow Foundation. The talk covers the basics of WF, including the fact that WF is not basic at all, it has a lot of complexities that have to be mastered to build real applications. There is a lot of power there and it makes sense to use it for workflow oriented enterprise applications, but this is not something you decide to adopt for a couple of conditionals and a loop in your business processing layer.

 

You can get the slides and demos here:  Slides    Demos

 

The more I work with WF, the more comfortable I get with it, but also the more I become convinced that they need a WF-Lite version. There are several key things I highlight in this talk that seem much more complex than they need to be. I understand the reasoning of some of these things, mostly tied to the fact that:

-          WF manages workflow scheduling and execution using threads from the thread pool

-          WF supports dehydrating your workflow when it is idle, persisting it to a persistence provider (SQL Server supported out of the box), and unloading it from memory

-          WF supports logging tracking information to a persistent store to know what workflows/activities are running when and what their state is.

 

The thing is that not all systems that could benefit from the abstracted design model of WF need these things. But by having these things, it means that certain aspects, particularly communicating with the executing workflow, are much harder than calling from one chunk of code to another in a standard .NET application. If we had a WF-Lite that provided the design time experience (with improvements… see below), but let the app control workflow instantiation and synchronous execution, this technology could apply to even more applications than it will in its current incarnation.

 

Some of the things that I find people have the hardest time groking are:

 

1. Presentation of workflow constructs as "Properties". A property is a first class construct of a type in .NET. It has a very precise meaning, as compared to events and methods. In WF, there are a lot of things that are exposed in the designer through the Properties window that are not really properties. They are events or event handler methods that are in your workflow or activities that you are hooking up. Event handlers should show up in the events view to be consistent with other design experiences in VS, and because that is where they belong. Instead, they show up in both the properties view and sometimes in the events view and it makes it confusing as a coder what the heck the designer is creating for you. WF is for developers, so speak the developers lingo dammit.

 

2. Code Conditions - a bool is just a bool. If you need to hook up an activity that depends on a condition (i.e. IfElse, While, ConditionalActivityGroup, etc.), you should be able to define either a method that returns a bool and point to it, or you should be able to define a bool property and point to it. The model of having to have an event defined that takes a ConditionalEventArgs, hooking up an event handler to that event, and then setting the event argument Result property to true/false just leaves people going "Whahuhhhh????"

 

3. HandleExternalEvent/CallExternalMethod - The number of things you have to do to conceptually just make a simple method call from the host to the workflow or vice versa is just way too high. I like the fact that the communications are based on interfaces. That part I like from a design perspective – the workflow is sort of a layer unto itself and communicating through an interface is a good way to enforce that separation. However, the number of steps you have to go through to hook up host communication scenarios is just way too high. The calls from the workflow into the host are not too bad, because those just get defined as methods. But the extra steps for the events that provide calls into the workflow just pushes it over the edge.

 

If you are not familiar with this model, the steps include:

- Define an event argument type to carry parameters (only needed because of the chosen event model - this should change in my opinion) that derives from ExternalDataEventArgs

- Define an interface marked with the ExternalDataExchange attribute

- Define an event on that interface of the type EventHandler<T>, where T is your event argument type

- Hook up the interface and the event to the HandleExternalEvent activity in your workflow that you want to be the call point for the call from the host into the workflow

- Define a class in the host application that implements the interface

- Have a way to fire the event in that class when you want to call into the workflow (a trigger/fire method)

- Register the ExternalDataExchangeService with the runtime when you start it up

- Register an instance of the class that implements the interface with the ExternalDataExchangeService instance that you registered with the runtime

- Finally, trigger the event from the host application at the point where you want to call into the workflow

 

All of this amounts to what? A simple method call with parameters into the workflow. This is where the attendees jaws usually hit the floor.

 

Am I wrong here? Isn't this a little more complex than it needs to be for most apps?