Beta 2 is finally here. Got it installed last night and of course one of the first things I wanted to play with is the WPF designer to see how far it had come along since Beta 1 and the Nov CTP tools for VS 2005.

Positives:

• The designer surface itself has come a long way and the snap lines, margin guides, and other adornments to help get elements positioned within the UI and visualize what underlying layout properties have been set looks really nice.
• There is a zoom control that makes it really easy to zoom in and out with smooth scaling to focus on the parts of the UI you are working on as a nice alternative to scrolling.
• They have a great little breadcrumb control at the bottom that lets you see where you are in the element hierarchy and even gives you a pop-up rendering of the other items in the hierarchy as you hover the mouse over them (see below).
• Picks up container locations such as grid cell when you drag and drop a control.
• The properties grid is fixed as far as being able to edit collection properties such as the RowDefinitions and ColumnDefinitions properties of a Grid.
• The XAML editor has improved IntelliSense with icons that help identify different constructs (namespaces, classes, etc when the IntelliSense list is up. The IntelliSense includes listing available namespaces with a clr-namespace construct for types in the project. Once the clr-namespace has been added, custom types show up in the IntelliSense tag list. Nice.
• Common WPF constructs (Window, Page, UserControl) are in the Add > menu from the project.
• Double click to hook up default event! Finally!

There are still a number of annoying aspects that I sure hope will be worked out by release.

Negatives:

• Designer load time: Still takes a really long time to load an empty form in the designer.
• Properties grid: No option to sort the properties alphabetical, so you still need to scroll around looking for what category the property you care about might be lurking in. Unfortunately no property search like Blend has.
• XAML Editor: Still does not add closing element tags when you create an open element tag. Very annoying productivity hit wen forced to bang out XAML by hand. Fills everything that is not inside an element tag with a cyan background. There does not appear to be any way to customize this.

Overall, I'm quite pleased with what I see. I think I can finally ditch using the Nov CTP in VS2005 for WPF development! I'll still be using a mix of this and Blend though.

Saturday, July 28, 2007 2:33:11 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I gave a talk on Connecting Applications with WCF to the Space Coast .NET and Orlando .NET User Groups over the last two nights. Had great attendance and questions, thanks to all who attended.

If you want the key takeaway from the talk (other than the demos and mechanics of how to connect two applications with WCF and use different bindings and capabilities of WCF), here is the elevator pitch.

WCF is a remote communications technology based on SOAP messaging. It is interoperable, powerful, flexible, easy to maintain, and supercedes all the previous remoting technologies in the .NET space:

• .NET Remoting
• ASP.NET Web Services
• Enterprise Services (COM+ for .NET)
• MSMQ

Basically, if you are writing a new application or new portion of an application that needs to make remote calls, use WCF and forget all the above exist. WCF gives you a single API for doing remote communications that rolls up all the capabilities of the technologies listed above, allowing you to write your code with most of the details of the remote communications abstracted away. This allows you to change major aspects of your remote communications approach, such as wire level protocol, encoding, security mechanisms, reliability, etc. without touching your programmatic code - you just modify config file settings. If you need to switch from TCP sockets with binary encoding to HTTP SOAP XML messaging, it literally takes about 30 seconds of editing your config files to do so.

There are a few fringe cases such as interoperating with a legacy .NET Remoting app, or certain advanced features of MSMQ that you will not be able to do with WCF, but for 98% of the remote communications needs out there, WCF is the choice you should make.

If you want the slides and demos I presented, you can grab them here:

Slides     Demos

Friday, July 20, 2007 1:54:28 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

In my ClickOnce book, I talk about David Guyer's excellent tool for creating Bootstrapper manifests for a custom bootstrapper item for your ClickOnce deployed applications. The URL I gave in the book is no longer valid, the BMG has been moved to codeplex at the following address:

http://www.codeplex.com/bmg

Basically, this tool gives you a nice dialog driven interface on the XML manifest files that make it so you can just check a box in Visual Studio (the Publish tab of project properties, Prerequisites button) to select your custom installers to be included in the bootstrapper setup.exe that is generated by ClickOnce. 

Tuesday, July 17, 2007 11:34:41 AM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I've had a number of requests to get an errata out for my Data Binding book. Luckily, the editors at AW did a wonderful job so the number of errors is really low for a first edition book. But there were a few little things here and there that should be noted.

You can download the errata for the book here:

http://www.softinsight.com/databindingbook/Errata%20for%20Data%20Binding%20with%20Windows%20Forms%202.0.doc

Tuesday, June 19, 2007 11:26:03 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

I get a lot of questions about what kinds of windows can be created from where in WPF when I give WPF talks. In a talk in Cleveland the other night, there was an attendee who was concerned because he didn't see a way to set a parent window for another window, and thought that is why they did not include an MDI windowing style in WPF.

If you want to set up a window ownership model in WPF like you did in Windows Forms, you just need to look at the Owner property, instead of Parent. The behavior is not exactly the same, but a lot of the same concepts apply.

If you create a window instance and set its Owner property to a reference to another Window, then when you show the child window it will always be displayed on top of the Owner window. This is typically used when creating an application modal dialog, but it behaves that way even if you show the window with a call to Show vs ShowDialog. The latter just adds the behavior that you cannot select the owner window and interact with it while the dialog is in place. When you call Show on an owned window, the user can still move the window out of the way, click on the owner window and interact with controls in that window. You could do this to create a floating tool palette window for example.

The fact that there is not a built-in implementation of MDI doesn't mean the framework doesn't support it, the WPF team just decided to leave that out of scope for the initial (v 3.0) release because very few applications are built from scratch with the MDI model these days.

If you really want MDI, you have two choices:

• Write it yourself. This would be a little tricky because you would have to detect Window movement and either prevent them from leaving the horizontal or vertical constraints of their owner window's client area, or you would have to deal with how to do clipping of the contained windows, because WPF does not clip by default.
• Adopt Acropolis. This framework is coming out in the Orcas timeframe and provides a modular WPF architecture based on concepts carried over from the Composite UI Application Block and the Smart Client Software Factory. It adds better support for inexperienced programmers to use the framework, adds pre-built components, a great design time interaction, and certain other application level support - such as an MDI application model.

Another window management question that often comes up is to ask whether you can use Windows Forms windows or Windows Forms message boxes within your WPF application. The short answer is - yes you can. You can simply construct a Windows Forms Form class and call show and it will just be another top level window presented by your application. Since Windows Forms message boxes really just make an interop call into the OS to display an OS message box, that is of course supported too. However, WPF has its own MessageBox class, so using Windows Forms MessageBoxes is really only interesting while migrating an existing Windows Forms application to WPF.

Tuesday, June 19, 2007 11:21:45 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

More security is a good thing. At least until it starts to cause you pain and suffering, and then it is easy to either decide that more security is bad or that the software that is providing you better security is bad. But the fact is, more security is a good thing, and you will be better off if you learn how to exist in that more constrained world rather than live free and unprotected. Gosh, that started to sound like a pro-Bush  restriction of freedoms post... lets get back to the tech quick.

The biggest pain points in adopting Windows Vista are usually due to non-existent, incompatible, or poorly written drivers. This is not Microsoft's fault, but the hardware vendor's fault. The next one that hits you in the face after you get past your driver pain is the fact that Microsoft is getting smarter and smarter (and more protective of you and your machine) with each new software product they put out. IE7 and Windows Vista definitely fall into this realm.

If your machine is set up as a standalone machine, or as part of a workgroup network (i.e. most home users), there is a subtle little security setting in IE7 that may cause you pain and suffering as a developer as you migrate to IE7 or Windows Vista.

Specifically, you may get prompted for credentials when accessing a local machine virtual directory when you think you have integrated authentication enabled and you shouldn't be prompted.

To explain why this occurs and how to fix it, lets first quickly recap life as we knew it in Windows XP and Server 2003 prior to IE7.

If you are working with web projects from your local machine, you will likely be creating virtual directories or IIS applications on your local install of IIS.

Turning On Integrated Windows Authentication in IIS

On XP, if you set the security settings for the site with Integrated Windows Security enabled and Anonymous Access disabled (see figure below), then when you browse to that local site from IE on the local machine, Windows automatically negotiates authentication between the browser and IIS and passes your logged in user credentials to the server (which is on the same machine), and you are let into the site or page (assuming your user account has ACL access to the underlying folders/files). In other words - integrated security does its job behind the scenes and you don't get prompted for credentials, but you are accessing the site with your logged in user credentials.

On Windows Vista, the security settings on the site are a little different, but basically mean the same thing. The corresponding authentication settings for Vista/IIS7 are shown in the figure below. Specifically, set Anonymous Authentication to Disabled, and Windows Authentication to Enabled.

IE7 Intranet Security Settings

If you are configured as a workgroup from a network perspective, when you first try to access a localhost web site, you might (or more importantly might not) notice an information bar at the top of IE telling you that Internet security settings are being applied to the Intranet zone by default. It gives you an opportunity to click on the info bar and revert to Intranet settings if you like. If you don't, after a certain number of prompts (which I don't know how many there are, it may just be once), it will stop telling you that.

The issue is that IE will set the Intranet zone security to automatically detect the network. However, depending on your connectivity, network setup, and possibly the celestial alignment of Jupiter and Venus, it will not detect that localhost is in fact in the Intranet zone. In a Windows domain this should not be a problem, but standalone it definitely is.

Because it can't tell that localhost is in fact local intranet, it plays it safe and applies internet zone security to the site. And with the default security settings, automatic authentication through Windows is disabled in the internet zone. Thus the prompt for credentials when you hit your localhost site through the browser.

The Fix

The fix is quite simple... just hard to find unless you are a psychic or know super brilliant people like Chris Kinsman or Kate Gregory.

To get back to behavior like you are used to on your retro XP box, go into IE Internet Options, Security tab. Select the Local Intranet zone, and press the Sites button (see below).

In the popup (see below), uncheck the "Automatically detect intranet network" box and make sure the three child check boxes are checked. Click OK and you should be back to integrated security as you know and love it.

Friday, June 15, 2007 10:07:04 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

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!

.NET | .NET 3.0 | Publishing

Thursday, June 14, 2007 4:17:17 PM (GMT Standard Time, UTC+00:00)
Comments [1]  | 

My second TechEd breakout session was in the Developer tools track (DEV340). This talk covered the interop story between Windows Forms and WPF and showed how to put WPF controls in a Windows Forms application, and Windows Forms controls in  a WPF application.

For WPF in a Windows Forms app, it boils down to 4 lines of code:

• Create an ElementHost control
• Create the hosted WPF control
• Add the ElementHost control to a container in the Windows Forms app
• Set the Child property of the ElementHost to point to the hosted control instance

This looks like the following:

ElementHost host = new ElementHost();
MediaElement mediaEl = new MediaElement();
panel1.Controls.Add(host);
host.Child = mediaEl;

You will also need to add a reference to WindowsFormsIntegration.dll and add a using statement for the System.Windows.Forms.Integration namespace, as well as a reference and using statement for the namespace of the WPF control that you are hosting (System.Windows.Controls in this case for the MediaElement control). You will also likely want to set the Dock property of the host control to Fill its container, and may want to keep the references for the host and the hosted control around in member variables on the form so that you can access them from event handlers and such.

To go the other way, it is the same basic process, but the host control is a WindowsFormsHost instead of ElementHost.

There are also a number of interop challenges you will face, which I covered in the talk, and showed how to overcome some of those challenges through property maps.

Finally, I demonstrated that in VS 2008, you can drag and drop WPF controls onto a Windows Form, and the ElementHost will be added and configured for you (basically it writes those four lines of code for you.

You can download the slides and demos for this session here:   Slides   Demos

Wednesday, June 13, 2007 4:27:53 PM (GMT Standard Time, UTC+00:00)
Comments [2]  | 

One of my breakout sessions at TechEd last week was ARC304: Deploying Smart Client Architectures.

The talk covered what the options are for deploying both the client and server side artifacts in a smart client architecture, and spent most of the time discussing these things with respect to ClickOnce as a smart client technology. I covered how ClickOnce works at a high level, then dove into what is going on behind the scenes, how the manifests drive the show, what you need to put where in your server side architecture for publishing a smart client, and then what ends up where after deployment on the client side.

One the options side, it really boils down to the following:

• ClickOnce - best choice for most .NET 2.0 and later smart client apps (or even prior using some tricks outlined in my book), but only affects deploying client side application and components that are not system wide.
• Updater Application Block - still a good option for automatic or on-demand update of client side (or even server side) components, allows a lot more flexibility in performing custom install steps during the update process, but requires more work to integrate with your application. Also does not address initial deployment in any way.
• Windows Installer (MSI) - not going anywhere. Still appropriate for heavyweight client side installs that affect system-wide settings or directories, and the primary choice for deploying server side components.

I won't try to summarize all the ClickOnce stuff I covered, that has all been addressed in various previous blog posts on my blog as well as in my book.

Slides and demos here:   Slides   Demos

Wednesday, June 13, 2007 4:25:05 PM (GMT Standard Time, UTC+00:00)
Comments [2]  | 

At the recommendation of some really smart people (Scott Hanselman and Richard Campbell specifically), I've decided to start using Microsoft Windows Live Writer to author my blog posts. This nice little tool lets you author your posts offline in a smart client WYSIWYG editor.

Its available at http://writer.live.com

Wednesday, June 13, 2007 2:38:35 PM (GMT Standard Time, UTC+00:00)
Comments [0]  | 

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

.NET | .NET 3.0 | Speaking

Wednesday, June 13, 2007 1:05:36 AM (GMT Standard Time, UTC+00:00)
Comments [2]  | 

Watching Scott Guthrie's keynote at Mix07 right now. The word is finally out - and wow. Silverlight is not just a Flash alternative - it is a cross platform, cross browser .NET runtime and framework. C#, VB, any .NET language driving display in the browser, running on the client side, on other platforms.

Beta for 1.0 is out today, available on www.silverlight.net.

You can even debug cross platform with the .NET code running in a Mac browser. I think we are not far from stepping through the time space continuum now...

.NET | Languages and Tools

Monday, April 30, 2007 6:10:48 PM (GMT Standard Time, UTC+00:00)
Comments [1]  |