By default, Xamarin.Forms handles orientation changes for you automatically, e.g.

Xamarin.Forms handles orientation changes automatically

In this example, the labels are above the text entries in both the portrait and the landscape orientation, which Xamarin.Forms can do without any help from me. However, what if I want to put the labels to the left of the text entries in landscape mode to take better advantage of the space? Further, in the general case, you may want to have different layouts for each orientation. To be able to do that, you need to be able to detect the device’s current orientation and get a notification when it changes. Unfortunately, Xamarin.Forms provides neither, but luckily it’s not hard for you to do it yourself.

Finding the Current Orientation

To determine whether you’re in portrait or landscape mode is pretty easy:

static bool IsPortrait(Page p) { return p.Width < p.Height; }

This function makes the assumption that portrait mode has a smaller width. This doesn’t work for all future imaginable devices, of course, but in the case of a square device, you’ll just have to take your changes I guess.

Orientation Change Notifications

Likewise, Xamarin.Forms doesn’t have any kind of a OrientationChanged event, but I find that handling SizeChanged does the trick just as well:

SizeChanged += (sender, e) => Content = IsPortrait(this) ? portraitView : landscapeView;

The SizeChanged event seems to get called exactly once as the user goes from portrait to landscape mode (at least in my debugging, that was true). The different layouts can be whatever you want them to be. I was able to use this technique and get myself a little extra vertical space in my landscape layout:

Using a custom layout to put the labels on the left of the text entries instead of on top 

Of course, I could use this technique to do something completely differently in each orientation, but I was hoping that the two layouts made sense to the user and didn’t even register as special, which Xamarin.Forms allowed me to do.

My goal was to take the name and address of a place and show it on the native map app regardless of what mobile platform on which my app was running. While Xamarin.Forms provides a cross-platform API to launch the URL that starts the map app, the URL format is different depending on whether you’re using the Windows Phone 8 URI scheme for Bing maps, the Android Data URI scheme for the map intent or the Apple URL scheme for maps.

This is what I came up with:

public class Place {
  public string Name { get; set; }
  public string Vicinity { get; set; }
  public Geocode Location { get; set; }
  public Uri Icon { get; set; }
}
public void LaunchMapApp(Place place) {
  // Windows Phone doesn't like ampersands in the names and the normal URI escaping doesn't help
  var name = place.Name.Replace("&", "and"); // var name = Uri.EscapeUriString(place.Name);
  var loc = string.Format("{0},{1}", place.Location.Latitude, place.Location.Longitude);
  var addr = Uri.EscapeUriString(place.Vicinity);

  var request = Device.OnPlatform(
    // iOS doesn't like %s or spaces in their URLs, so manually replace spaces with +s
    string.Format("http://maps.apple.com/maps?q={0}&sll={1}", name.Replace(' ', '+'), loc),

    // pass the address to Android if we have it
    string.Format("geo:0,0?q={0}({1})", string.IsNullOrWhiteSpace(addr) ? loc : addr, name),

    // WinPhone
    string.Format("bingmaps:?cp={0}&q={1}", loc, name)
  );

  Device.OpenUri(new Uri(request));
}

This code was testing on several phone and tablet emulators and on 5 actual devices: an iPad running iOS 8, an iPad Touch running iOS 8, a Nokia Lumia 920 running Windows Phone 8.1, an LG G3 running Android 4.4 and an XO tablet running Android 4.1. As you can tell, each platform has not only it’s own URI format for launching the map app, but quirks as well. However, this code works well across platforms. Enjoy.

Settings allow you to separate the parameters that configure the behavior of your app separate from the code, which allows you to change that behavior without rebuilding the app. This is handle at the app level for things like server addresses and API keys and at the user level for things like restoring the last user input and theme preferences. Xamarin.Forms provides direct support for neither, but that doesn’t mean you can’t easily add it yourself.

App Settings

Xamarin.Forms doesn’t have any concept of the .NET standard app.config. However, it’s easy enough to add the equivalent using embedded resources and the XML parser. For example, I built a Xamarin.Forms app for finding spots for coffee, food and drinks between where I am and where my friend is (MiddleMeeter, on GitHub). I’m using the Google APIs to do a bunch of geolocation-related stuff, so I need a Google API key, which I don’t want to publish on GitHub. The easy way to make that happen is to drop the API key into a separate file that’s loaded at run-time but to not check that file into GitHub by adding it to .gitignore. To make it easy to read, I added this file as an Embedded Resource in XML format:

Adding an XML file as an embedded resource makes it easy to read at run-time for app settings

I could’ve gone all the way and re-implemented the entire .NET configuration API, but that seemed like overkill, so I kept the file format simple:

<?xml version="1.0" encoding="utf-8" ?>
<config>
  <google-api-key>YourGoogleApiKeyHere</google-api-key>
</config>

Loading the file at run-time uses the normal .NET resources API:

string GetGoogleApiKey() {
  var type = this.GetType();
  var resource = type.Namespace + "." +
    Device.OnPlatform("iOS", "Droid", "WinPhone") + ".config.xml";
  using (var stream = type.Assembly.GetManifestResourceStream(resource))
  using (var reader = new StreamReader(stream)) {
    var doc = XDocument.Parse(reader.ReadToEnd());
    return doc.Element("config").Element("google-api-key").Value;
  }
}

I used XML as the file format not because I’m in love with XML (although it does the job well enough for things like this), but because LINQ to XML is baked right into Xamarin. I could’ve used JSON, too, of course, but that requires an extra NuGet package. Also, I could’ve abstracting things a bit to make an easy API for more than one config entry, but I’ll leave that for enterprising readers.

User Settings

While app settings are read-only, user settings are read-write and each of the supported Xamarin platforms has their own place to store settings, e.g. .NET developers will likely have heard of Isolated Storage. Unfortunately, Xamarin provides no built-in support for abstracting away the platform specifics of user settings. Luckily, James Montemagno has. In his Settings Plugin NuGet package, he makes it super easy to read and write user settings. For example, in my app, I pull in the previously stored user settings when I’m creating the data model for the view on my app’s first page:

class SearchModel : INotifyPropertyChanged {
  string yourLocation;
  // reading values saved during the last session (or setting defaults)
  string theirLocation = CrossSettings.Current.GetValueOrDefault("theirLocation", "");
  SearchMode mode = CrossSettings.Current.GetValueOrDefault("mode", SearchMode.food);
  ...
}

The beauty of James’s API is that it’s concise (only one function to call to get a value or set a default if the value is missing) and type-safe, e.g. notice the use of a string and an enum here. He handles the specifics of reading from the correct underlying storage mechanism based on the platform, translating it into my native type system and I just get to write my code w/o worrying about it. Writing is just as easy:

async void button1_Clicked(object sender, EventArgs e) {
  ...

  // writing settings values at an appropriate time
  CrossSettings.Current.AddOrUpdateValue("theirLocation", model.TheirLocation);
  CrossSettings.Current.AddOrUpdateValue("mode", model.Mode);

  ...
}

My one quibble is that I wish the functions were called Read/Write or Get/Set instead of GetValueOrDefault/AddOrUpdateValue, but James’s function names make it very clear what’s actually happening under the covers. Certainly the functionality makes it more than worth the extra characters.

User Settings UI

Of course, when it comes to building a UI for editing user settings at run-time, Xamarin.Forms has all kinds of wonderful facilities, including a TableView intent specifically for settings (TableIntent.Settings). However, when it comes to extending the platform-specific Settings app, you’re on your own. That’s not such a big deal, however, since only iOS actually supports extending the Settings app (using iOS Settings Bundles). Android doesn’t support it at all (they only let the user configure things like whether an app has permission to send notifications) and while Windows Phone 8 has an extensible Settings Hub for their apps, it’s a hack if you do it with your own apps (and unlikely to make it past the Windows Store police).

Where Are We?

So, while Xamarin.Forms doesn’t provide any built in support for app or user settings, the underlying platform provides enough to make implementing the former trivial and the Xamarin ecosystem provides nicely for the latter (thanks, James!).

Even more interesting is what Xamarin has enabled with this ecosystem. They’ve mixed their very impressive core .NET and C# compiler implementation (Mono) with a set of mobile libraries providing direct access to the native platforms (MonoTouch and MonoDroid), added a core implementation of UI abstraction (Xamarin.Forms) and integration into the .NET developer’s IDE of choice (Visual Studio) together with an extensible, discoverable set of libraries (NuGet) that make it easy for 3rd party developers to contribute. That’s a platform, my friends, and it’s separate from the one that Microsoft is building. What makes it impressive is that it takes the army of .NET developers and points them at the current hotness, i.e. building iOS and Android apps, in a way that Microsoft never could. Moreover, because they’ve managed to also support Windows Phone pretty seamlessly, they’ve managed to get Microsoft to back them.

We’ll see how successful Xamarin is over time, but they certainly have a very good story to tell .NET developers.

I don’t know what it is, but I’ve long been fascinated with using the C# syntax as a command line execution environment. It could be that PowerShell doesn’t do it for me (I’ve seriously tried half a dozen times or more). It could be that while LINQPad comes really close, I still don’t have enough control over the parsing to really make it work for my day-to-day command line activities. Or it may be that my friend Tim Ewald has always challenged csells to sell C shells by the sea shore.

Roslyn REPL

Whatever it is, I decided to spend my holiday time futzing with the Roslyn 2011 CTP, which is a set of technologies from Microsoft that gives you an API over your C# and VB.NET code.

Why do I care? Well, there are all kinds of cool code analysis and refactoring tools I could build with it and I know some folks are doing just that. In fact, at the BUILD conference, Anders showed off a “Paste as VB” command built with Roslyn that would translate C# to VB slick as you please.

For me, however, the first thing I wanted was a C# REPL environment (Read-Evaluate-Print-Loop). Of course, Roslyn ships out of the box with a REPL tool that you can get to with the View | Other Windows | C# Interactive Window inside Visual Studio 2010. In that code, you can evaluate code like the following:

> 1+1
2

> void SayHi() { Console.WriteLine("hi"); }

> SayHi();

hi

Just like modern dynamic languages, as you type your C# and press Enter, it’s executed immediately, even allowing you to drop things like semi-colons or even calls to WriteLine to get output (notice the first “1+1” expression). This is a wonderful environment in which to experiment with C# interactively, but just like LINQPad, it was a closed environment; the source was not provided!

The Roslyn team does provide a great number of wonderful samples (check the “Microsoft Codename Roslyn CTP - October 2011” folder in your Documents folder after installation). One in particular, called BadPainting, provides a text box for inputting C# that’s executed to add elements to a painting.

But that wasn’t enough for me; I wanted at least a Console-based command line REPL like the cool Python, JavaScript and Ruby kids have. And so, with the help of the Roslyn team (it pays to have friends in low places), I built one:

RoslynRepl Sample Download

Building it (after installing Visual Studio 2010, Visual Studio 2010 SP1, the Visual Studio 2010 SDK and the Roslyn CTP) and running it lets you do the same things that the VS REPL gives you:

In implementing my little RoslynRepl tool, I tried to stay as faithful to the VS REPL as possible, including the help implementation:

If you’re familiar with the VS REPL commands, you’ll notice that I’ve trimmed the Console version a little as appropriate, most notably the #prompt command, which only has “inline” mode (there is no “margin” in a Console window). Other than that, I’ve built the Console version of REPL for Roslyn such that it works just exactly like the one documented in the Roslyn Walkthrough: Executing Code in the Interactive Window.

Building a REPL for any language is, at you might imagine, a 4-step process:

1. Read input from the user
2. Evaluate the input
3. Print the results
4. Loop around to do it again until told otherwise

Read

Step 1 is a simple Console.ReadLine. Further, the wonder and beauty of a Windows Console application is that you get complete Up/Down Arrow history, line editing and even obscure commands like F7, which brings up a list of commands in the history:

The reading part of our REPL is easy and has nothing to do with Roslyn. It’s evaluation where things get interesting.

Eval

Before we can start evaluating commands, we have to initialize the scripting engine and set up a session so that as we build up context over time, e.g. defining variables and functions, that context is available to future lines of script:

using Roslyn.Compilers;
using Roslyn.Compilers.CSharp;
using Roslyn.Compilers.Common;
using Roslyn.Scripting;
using Roslyn.Scripting.CSharp;

...

// Initialize the engine
string[] defaultReferences = new string[] { "System", ... };
string[] defaultNamespaces = new string[] { "System", ... };
CommonScriptEngine engine = new ScriptEngine(defaultReferences, defaultNamespaces);

// HACK: work around a known issue where namespaces aren't visible inside functions
foreach (string nm in defaultNamespaces) {
  engine.Execute("using " + nm + ";", session);
}

Session session = Session.Create();

Here we’re creating a ScriptEngine object from the Roslyn.Scripting.CSharp namespace, although I’m assigning it to the base CommonScriptEngine class which can hold a script engine of any language. As part of construction, I pass in the same set of assembly references and namespaces that a default Console application has out of the box and that the VS REPL uses as well. There’s also a small hack to fix a known issue where namespaces aren’t visible during function definitions, but I expect that will be unnecessary in future drops of Roslyn.

Once I’ve got the engine to do the parsing and executing, I creating a Session object to keep context. Now we’re all set to read a line of input and evaluate it:

ParseOptions interactiveOptions =
  new ParseOptions(kind: SourceCodeKind.Interactive,
                   languageVersion: LanguageVersion.CSharp6);
...
while (true) {
  Console.Write("> ");
  var input = new StringBuilder();

  while (true) {
    string line = Console.ReadLine();
    if (string.IsNullOrWhiteSpace(line)) { continue; }

    // Handle #commands
    ...

    // Handle C# (include #define and other directives)
    input.AppendLine(line);

    // Check for complete submission
    if (Syntax.IsCompleteSubmission(
          SyntaxTree.ParseCompilationUnit(
            input.ToString(), options: interactiveOptions))) {
      break;
    }
    Console.Write(". ");
  }

  Execute(input.ToString());
}

The only thing we’re doing that’s at all fancy here is collecting input over multiple lines. This allows you to enter commands over multiple lines:

The IsCompleteSubmission function is the thing that checks whether the script engine will have enough to figure out what the user meant or whether you need to collect more. We do this with a ParseOptions object optimized for “interactive” mode, as opposed to “script” mode (reading scripts from files) or “regular” mode (reading fully formed source code from files). The “interactive” mode lets us do things like “1+1” or “x” where “x” is some known identifier without requiring a call to Console.WriteLine or even a trailing semi-colon, which seems like the right thing to do in a REPL program.

Once we have a complete command, single or multi-line, we can execute it:

public void Execute(string s) {
  try {
    Submission<object> submission = engine.CompileSubmission<object>(s, session);
    object result = submission.Execute();
    bool hasValue;
    ITypeSymbol resultType = submission.Compilation.GetSubmissionResultType(out hasValue);

    // Print the results
    ...
  }
  catch (CompilationErrorException e) {
    Error(e.Diagnostics.Select(d => d.ToString()).ToArray());
  }
  catch (Exception e) {
    Error(e.ToString());
  }
}

Execution is a matter of creating a “submission,” which is a unit of work done by the engine against the session. There are helper methods that make this easier, but we care about the output details so that we can implement our REPL session.

Print

Printing the output depends on the type of a result we get back:

ObjectFormatter formatter =
  new ObjectFormatter(maxLineLength: Console.BufferWidth, memberIndentation: "  ");
...
Submission<object> submission = engine.CompileSubmission<object>(s, session);
object result = submission.Execute();
bool hasValue;
ITypeSymbol resultType =
  submission.Compilation.GetSubmissionResultType(out hasValue);

// Print the results
if (hasValue) {
  if (resultType != null && resultType.SpecialType == SpecialType.System_Void) {
    Console.WriteLine(formatter.VoidDisplayString);
  }
  else {
    Console.WriteLine(formatter.FormatObject(result));
  }
}

As part of the result output, we’re leaning on an instance of an “object formatter” which can trim things for us to the appropriate length and, if necessary, indent multi-line object output.

In the case that there’s an error, we grab the exception information and turn it red:

void Error(params string[] errors) {
  var oldColor = Console.ForegroundColor;
  Console.ForegroundColor = ConsoleColor.Red;
  WriteLine(errors);
  Console.ForegroundColor = oldColor;
}

public void Write(params object[] objects) {
  foreach (var o in objects) { Console.Write(o.ToString()); }
}

void WriteLine(params object[] objects) {
  Write(objects);
  Write("\r\n");
}

Loop

And then we do it all over again until the program is stopped with the #exit command (Ctrl+Z, Enter works, too).

Where Are We?

Executing lines of C# code, the hardest part of building a C# REPL, has become incredibly easy with Roslyn. The engine does the parsing, the session keeps the context and the submission gives you extra information about the results. To learn more about scripting in Roslyn, I recommend the following resources:

• Roslyn on MSDN
• The REPL forum for Roslyn
• C# as a Scripting Language in Your .NET Applications Using Roslyn, Anoop Madhusudanan, codeproject.com, 10/24/2011

Now I’m off to add Intellisense support. Wish me luck!

Often when I’m building my MVC 2 application using Visual Studio 2010, I get the following error:

It is an error to use a section registered as allowDefinition=‘MachineToApplication’ beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

On the internet, this error seems to be related to having a nested web.config in your application. I do have such a thing, but it’s just the one that came out of the MVC 2 project item template and I haven’t touched it.

In my case, this error in my case doesn’t seem to have anything to do with a nested web.config. This error only started to happen when I began using the web site deployment features in VS2010 which by itself, rocks (see Scott Hanselman’s “Web Deployment Made Awesome: If You’re Using XCopy, You’re Doing It Wrong” for details).

 If it happens to you and it doesn’t seem to make any sense, you can try to fix it with a Build Clean command. If you’re using to previous versions of Visual Studio, you’ll be surprised, like I was, not to find a Clean option in sparse the Build menu. Instead, you can only get to it by right-clicking on your project in the Solution Explorer and choosing Clean.

Doing that, however, seems to make the error go away. I don’t think that’s a problem with my app; I think that’s a problem with VS2010.

It all started innocently enough. I was implementing a “Older Posts/Newer Posts” feature for my new web site and was writing code like this:

IEnumerable<Post> FilterByCategory(IEnumerable<Post> posts, string category) {
  if( !string.IsNullOrEmpty(category) ) {
    return posts.Where(p => p.Category.Contains(category));
  }
}
...
  var posts = FilterByCategory(db.Posts, category);
  int count = posts.Count();
...

The “db” was an EF object context object, but it could just as easily been a LINQ to SQL context. Once I ran this code, it failed at run-time with a null reference exception on Category. “That’s strange,” I thought. “Some of my categories are null, but I expect the ‘like’ operation in SQL to which Contains maps to skip the null values.” That should’ve been my first clue.

Clue #2 was when I added the null check into my Where expression and found that their were far fewer results than I expected. Some experimentation revealed that the case of the category string mattered. “Hm. That’s really strange,” I thought. “By default, the ‘like’ operation doesn’t care about case.” Second clue unnoticed.

My 3rd and final clue was that even though my site was only showing a fraction of the values I knew where in the database, it had slowed to a crawl. By now, those of you experienced with LINQ to Entities/SQL are hollering from the audience: “Don’t go into the woods alone! IEnumerable kills all the benefits of IQueryable!”

See, what I’d done was unwittingly switched from LINQ to Entities, which takes my C# expressions and translates them into SQL, and was now running LINQ to Objects, which executes my expressions directly.

“But that can’t be,” I thought, getting hot under the collar (I was wearing a dress shirt that day — the girlfriend likes me to look dapper!). “To move from LINQ to Entities/SQL to LINQ to Objects, I thought I had to be explicit and use a method like ToList() or ToArray().” Au contraire mon fraire (the girlfriend also really likes France).

Here’s what I expected to be happening. If I have an expression like “db.Posts” and I execute that expression by doing a foreach, I expect the SQL produced by LINQ to Entities/SQL to look like this:

select * from Posts

If I add a Where clause, I expect the SQL to be modified:

select * from Posts where Category like '%whatever%'

Further, if I do a Count on the whole thing, e.g.

db.Posts.Where(p => p.Contains(category)).Count()

I expect that to turn into the following SQL:

select count(*) from Posts where Category like '%whatever%'

And that’s all true if I keep things to just “var” but I wasn’t — I was being clever and building functions to build up my queries. And because I couldn’t use “var” as a function parameter, I had to pick a type. I picked the wrong one: IEnumerable.

The problem with IEnumerable is that it doesn’t have enough information to support the building up of queries. Let’s take a look at the extension method of Count over an IEnumerable:

public static int Count<TSource>(this IEnumerable<TSource> source) {
  ...
  int num = 0;
  using (IEnumerator<TSource> enumerator = source.GetEnumerator()) {
    while (enumerator.MoveNext()) { num++; }
  }
  return num;
}

See? It’s not composing the source IEnumerable over which it’s operating — it’s executing the enumerator and counting the results. Further, since our example IEnumerator was a Where statement, which was in turn a accessing the list of Posts from the database, the effect was filtering in the Where over objects constituted from the following SQL:

select * from Posts

How did I see that? Well, I tried hooking up the supremely useful SQL Profiler to my ISP’s database that was holding the data, but I didn’t have permission. Luckily, the SQL tab in LinqPad will show me what SQL is being executed and it showed me just that (or rather, the slightly more verbose and more correct SQL that LINQ to Entities generates in these circumstances).

Now, I had a problem. I didn’t want to pass around IEnumerable, because clearly that’s slowing things down. A lot. On the other hand, I don’t want to use ObjectSet because it doesn’t compose, i.e. Where doesn’t return that. What is the right interface to use to compose separate expressions into a single SQL statement? As you’ve probably guessed by now from the title of this post, the answer is: IQueryable.

Unlike IEnumerable, IQueryable exposes the underlying expression so that it can be composed by the caller. In fact, if you look at the IQueryable implementation of the Count extension method, you’ll see something very different:

public static int Count<TSource>(this IQueryable<TSource> source) {
  ...
  return source.Provider.Execute<int>(
    Expression.Call(null,
      ((MethodInfo) MethodBase.GetCurrentMethod()).
      MakeGenericMethod(
        new Type[] { typeof(TSource) }),
        new Expression[] { source.Expression }));
}

This code isn’t exactly intuitive, but what’s happening is that we’re forming an expression which is composed of whatever expression is exposed by the IQueryable we’re operating over and the Count method, which we’re then implementing. To get this code path to execute for our example, we simply have to replace the use of IEnumerable with IQueryable:

IQueryable<Post> FilterByCategory(IQueryable<Post> posts, string category) {
  if( !string.IsNullOrEmpty(category) ) {
    return posts.Where(p => p.Category.Contains(category));
  }
}
...
  var posts = FilterByCategory(db.Posts, category);
  int count = posts.Count();
...

Notice that none of the actual code changes. However, this new code runs much faster and with the case- and null-insensitivity built into the ‘like’ operator in SQL instead of semantics of the Contains method in LINQ to Objects.

The way it works is that we stack one IQueryable implementation onto another, in our case Count works on the Where which works on the ObjectSet returned from the Posts property on the object context (ObjectSet itself is an IQueryable). Because each outer IQueryable is reaching into the expression exposed by the inner IQueryable, it’s only the outermost one — Count in our example — that causes the execution (foreach would also do it, as would ToList() or ToArray()).

Using IEnumerable, I was pulling back the ~3000 posts from my blog, then filtering them on the client-side and then doing a count of that.With IQueryable, I execute the complete query on the server-side:

select count(*) from Posts where Category like '%whatever%'

And, as our felon friend Ms. Stewart would say: “that’s a good thing.”

I was building a little WPF app to explore a hierarchical space (OData, if you must know), so of course, I was using the TreeView. And since I’m a big fan of data binding, of course I’ve got a hierarchical data source (basically):

abstract class Node {
  public abstract string Name { get; }
  public abstract IEnumerable<Node> { get; }
  public XDocument Document { get { ... } }
  public Uri Uri { get { ... } }
}

I then bind to the data source (of course, you can do this in XAML, too):

// set the data context of the grid containing the treeview and text boxes
grid.DataContext = new Node[] { Node.GetNode(new Uri(uri)) };

// bind the treeview to the entire collection of nodes
leftTreeView.SetBinding(TreeView.ItemsSourceProperty, ".");

// bind each text box to a property on the current node
queryTextBox.SetBinding(TextBox.TextProperty,
  new Binding("Uri") { Mode = BindingMode.OneWay });
documentTextBox.SetBinding(TextBox.TextProperty,
  new Binding("Document") { Mode = BindingMode.OneWay });

What we’re trying to do here is leverage the idea of “currency” in WPF where if you share the same data context, then item controls like textboxes will bind to the “current” item as it’s changed by the list control. If this was a listview instead of a treeview, that would work great (so long as you set the IsSynchronizedWithCurrentItem property to true).

The problem, as my co-author and the-keeper-of-all-WPF-knowledge Ian Griffiths reminded me this morning, is that currency is based on a single collection, whereas a TreeView control is based on multiple collections, i.e. the one at the root and each one at sub-node, etc. So, as I change the selection on the top node, the treeview has no single collection’s current item to update (stored in an associated “view” of the data), so it doesn’t update anything. As the user navigates from row to row, the “current” item never changes and our textboxes are not updated.

So, Ian informed me of a common “hack” to solve this problem. The basic idea is to forget about the magic “current node” and explicitly bind each control to the treeview’s SelectedItem property. As it changes, regardless of which collection from whence the item came, each item control is updated, as data binding is supposed to work.

First, instead of setting the grid’s DataContext to the actual data, shared with the treeview and the textboxes, we bind it to the currently selected treeview item:

// bind the grid containing the treeview and text boxes
// to point at the treeview's currently selected item
grid.DataContext = new Binding("SelectedItem") { ElementName = "leftTreeView" };

Now, because we want the treeview to in fact show our hierarchical collection of nodes, we set it’s DataContext explicitly:

// set the treeview's DataContext to be the data we want it to show
leftTreeView.DataContext = new Node[] { Node.GetNode(new Uri(uri)) };

Now, the treeview will show the data we wanted it to show, as before, but as the user changes the selection, the treeview’s SelectedItem property changes, which updates the grid’s DataContext, which signals the textboxes, bound to properties on grid’s DataContext (because the DataContext property is inherited and we haven’t overridden it on the textboxes), and the textboxes are updated.

Or, in other words, the textboxes effectively have a new idea of the “current” item that meshes with how the treeview works. Thanks, Ian!

On 1/16/08, Microsoft announced the ability to download some of the .NET Framework source code for debugging. This download process was only supported inside of a properly configured Visual Studio 2008.

21 Days Later: Kerem Kusmezer and John Robbins released a tool to download the source code en mass. Frankly, I’m surprised it took so long. : )

If you haven’t already heard about Microsoft’s new high fidelity, cross-platform application development platform, you just haven’t been paying attention. Silverlight is the new name for WPF/E (although it’s still XAML-based) and does some *amazing* things.

And, if you can wait just a little while longer, you can read about Silverlight in Programming WPF (available now in Rough Cut format and for pre-order from Amazon) in an appendix by my friend and yours, Shawn Wildermuth. Shawn’s been doing a ton of Silverlight work lately, including doing a bunch of Silverlight presentations for Microsoft, so he knows of what he speaks.

Savas turned me onto an amazing WPF/E application. I don’t speak the language of the web site, but the screenshot on Savas’s site is worth a look…

P.S. I don’t smoke (except for the occasional cigar) and I definitely don’t want to smell smoke while I eat or in my clothes, but the fact that smokers are no longer allowed to smoke most places strikes me as a violation of an important liberty. Have those studies about the effects of 3rd party smoke been verified?

“The British Library is one of the world’s leading libraries and the national library of the United Kingdom. By charter, it holds a copy of every book ever published in the UK, along with 58 million newspapers, 4.5 million maps, and 3.5 million sound recordings. They hold some of the most priceless literary treasures in existence, including the Codex Sinaiticus (one of the oldest New Testaments in existence), the Lindisfarne Gospels, one of Leonardo Da Vinci’s notebooks, the first atlas of Europe by Mercator, the original illustrated manuscript Lewis Carroll’s Alice’s Adventures in Wonderland, Jane Austen’s History of England and Mozart’s musical diary. …

“Enter a fantastic new application, developed in partnership between the British Library and Armadillo Systems. The British Library have digitized the pages of fifteen of their most valuable works and created Turning the Pages, a browser-based WPF application that allows you to interact with these books in a virtual environment from the comfort of your home.”

Wow. This is literally the only way to interact with some of this material and it’s enabled with WPF. Nice.

Don has a piece up about something that I’ve always called “API Usability.” The idea when building libraries is to write client code first against some pretend API that you wish existed and then to implement that API. Another good name for this approach would be “RAD API Design,” simply because it’s the same way I prefer to design UI — layout the UI the way you’d like it to look and then implement it that way. Of course, I have to admit to preferring Don’s name for this style of programming (I like what he calls my conferences, too : ).

BTW, the comments to Don’s piece mention to startling similarity between this approach and Test-Driven Development (TDD). I’m a huge fan of TDD (NUnit is a wonderful tool I use all day every day). I’d say that TDD is a generalization of my little “API usability” technique in that you can use it for all kinds of things, e.g. code coverage, perf testing, stress testing, etc, including API usability.

P.S. If we fix the atmosphere, clean up the water, stop polluting the soil and learn to live in harmony with our environment, what’s to motivate us to move off this rock before we lose our aggressive drive and then, when we’re sipping Mai Thais, the sun explodes? Consuming this planet until nothing’s left but an empty husk and we’re forced, like locusts to move on to the next one, may well be the only thing that keeps our species alive (assuming we survive the coming ice age, of course).

If you’re a designer looking for XAML design tools, and you’re a designer type (you know — beret, turtle neck, a wardrobe that extends beyond jeans and t-shirts), you’ve got two choices from Microsoft. You can use Expression Design [1] for static XAML graphics or Expression Blend (aka Sparkle) for dynamic XAML interfaces. Both are available in pre-release form (CTP for Design and Beta 1 for Blend), so give them a try.

[1] “Expression Design” is not to be confused with “Expression Designer”, which is the old name for Sparkle (Blend).

P.S. Can someone give Scoble a hug? He’s obviously a little worked up if he’s recommending physical violence for disagreements about web site design. : )

I expected eventually to get a WPF/E (Windows Presentation Foundation Everywhere) download or two, but these guys went crazy; they just released an entire WPF/E DevCenter this morning. Here’re just a few highlights:

• WPF/E CTP for Windows and the Mac
• WPF/E online reference, samples and downloadable SDK
• Microsoft Expression Design CTP
• SWF to XAML Converter
• Adobe Illustrator to WPF/XAML Export Plug-In

Enjoy!

P.S. Regardless of whether humans caused global warming or whether it’s part of a natural cycle, it’s happening and we’re going to have to deal with it.

After a monumental amount of work, the .NET Framework 3.0 has been completed! It ships out of the box in Vista, but for down level clients (Windows XP and Windows Server 2003) and developer tools, see the links below:

• Microsoft .NET 3.0 Framework Release Notes
• Microsoft .NET Framework 3.0 Redistributable Package (for XP and 2003)
• Microsoft Windows SDK for Windows Vista and .NET Framework 3.0 Runtime Components in ISO Install and Web Install formats (with it’s own set of Release Notes)
• Visual Studio 2005 extensions for .NET Framework 3.0, both for WF and for WCF/WPF (WCF/WPF extensions are the November 2006 CTP — there are more to come)
• WCF/WPF/WF Cross-Technology Integration Samples (I admit I’m biased here to point out the parts of .NET 3.0 that I worked on : )

Wahoo!

My friend Jeff asked me to do a terrible thing yesterday: “How do I show a form in the popup window that a menu shows?” I said, “Dude! Don’t do that — write a dialog!” And that’s what he did, but then, like a train wreck, I couldn’t look away. It took me all of 10 minutes of very straight forward coding and here we are:

If you’re familiar with WPF, data binding and data templates, this is all standard stuff. Here’s the data structure:

class Person : INotifyPropertyChanged
{
    string name;
    public string Name
    {
        get { return name; }
        set { name = value; Notify("Name"); }
    }

    int age;
    public int Age
    {
        get { return age; }
        set { age = value; Notify("Age"); }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    void Notify(string prop) {
    if( PropertyChanged != null ) {
        PropertyChanged(this, new PropertyChangedEventArgs(prop));
    }
}
}

The data template is also bog standard:

<DataTemplate DataType="{x:Type local:Person}">
  <Grid>
    <Grid.RowDefinitions>
      <RowDefinition Height="auto" />
      <RowDefinition Height="auto" />
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
      <ColumnDefinition Width="auto" />
      <ColumnDefinition Width="auto" />
    </Grid.ColumnDefinitions>

    <Label Grid.Row="0" Grid.Column="0">_Name</Label>
    <TextBox Grid.Row="0" Grid.Column="1" Text="{Binding Name}" />

    <Label Grid.Row="1" Grid.Column="0">_Age</Label>
    <TextBox Grid.Row="1" Grid.Column="1" Text="{Binding Age}" />
  </Grid>
</DataTemplate>

Setting up the app itself is nothing special:

<Window ...>
  <Window.Resources>
    <DataTemplate DataType="{x:Type local:Person}">
      ...
    </DataTemplate>
  </Window.Resources>
  <Grid>
    <Menu>
      <MenuItem Header="File">
        <MenuItem Header="Exit" x:Name="fileExitMenuItem" />
      </MenuItem>
      <MenuItem Header="Form" ItemsSource="{Binding}" />
    </Menu>
  </Grid>
</Window>

Notice that the items that make up the menu come from a binding to the ambient data source, which we set in the code-behind:

protected override void OnInitialized(EventArgs e)
{
    ...

    Person tom = new Person();
    tom.Name = "Tom";
    tom.Age = 11;

    DataContext = new Person[] { tom };
}

The only thing at all tricky is that, even though we’re only editing a single object in the “popdown window,” it has to be in an implementation of IEnumerable so that the menu can display it (it expects items to come in a list).

That’s it. You can download the RC1 WPF project here.

You might wonder why I would post such a sample, when clearly that’s not a UI we want to foster on folks. The answer is simple: because WPF allows it.

The power of any platform should be judged by how well it lets you write bad code. Early versions of Visual Basic let you write really bad code — but it worked. Likewise, WPF lets me build the worst UIs ever — but they work. This is necessary so that UI visionaries can experiment and get to a place where they’re doing something completely different from UIs of today and we like it.

Do you think the Office folks, who, for all practical purposes, have been setting UI guidelines on Windows for a decade, could use MFC or Windows Forms? No, because they’re not flexible enough. Could they use WPF? Absolutely they could. And so can you.

The crayon box has lots of colors that I don’t like, but in the hands of an artist, they can create beauty.

The CTPs are coming so fast and so furious now that I nearly missed the September 2006 .NET Framework 3.0 CTP:

• Release Notes
• .NET Framework
• SDK
• VS05 Integration for WCF and WPF
• VS05 Integration for WF
• Cider Release Notes

Enjoy!

This one should be about done:

• .NET 3.0 RC1 Release Notes
• .NET 3.0 RC1 Framework Components
• .NET 3.0 RC1 SDK
• .NET 3.0 RC1 VS05 Tools (including Cider)
• .NET 3.0 RC1 SDK online

Enjoy!

As you may or may not recall, Doug Purdy and I had some trouble at the last PDC getting Avalon (WPF) and Indigo (WCF) to work together. To save myself from having that trouble again, I came back from the PDC and starting the “WinFX Cross-Pillar SDK Samples Working Group,” which is just a fancy name for the PMs in charge of Avalon, Indigo and Workflow samples getting together to make sure that we have a list of simple technology samples showing the three W*F technologies working together.

You can see the results of that work in the .NET 3.0 SDK under the Integration Samples for WinFX Features topic. Right now, there are 9 integration samples and I’m hoping to almost double that by .NET 3.0 RTM. I’d love feedback. Thanks!

Beta 2 signals the beginning of the final drive towards RTM for WinFX:

• Readme
• Runtime Components
• SDK
• VS05 Extensions for Avalon and Indigo
• VS05 Extensions for Workflow

Enjoy.

The February ’06 WinFX CTP cometh:

• WinFX RC February CTP Readme
• WinFX Runtime Components
• Windows SDK
• Visual Studio Community Technology Preview - Development Tools for WinFX® (aka Fidalgo)
• VS Extensions for WorkFlow
• Ed’s Big List of WCF Breaking Changes
• Karsten’s Big List of WPF Breaking Changes

Enjoy!

Suddenly, I think Larry O’Brien is smart:

“The book, in this case, is Chris Sells and Ian Griffiths’ ‘Programming Windows Presentation Foundation.’ Sells and Griffiths are two top-notch authors, who separately wrote two of the better books on Windows Forms. This book, published by O’Reilly and adorned with a Kudu engraving, probably does about as good a job as possible in introducing a new display framework that is intended to replace, well, everything from User to GDI to GDI+. And, it seems clear, to replace Flash as well.”

You go, Larry!

It goes without saying that MSDN Magazine doesn’t let the authors pick the titles (who can forget Don’s The Active Template Library Makes Building Compact COM Objects a Joy? : ), but what Ian and I had in mind here was 10 things that would surprise you when learning WPF and getting them in your face right up front. Enjoy.

You’ve probably seen this by now, but I thought I’d post the WinFX Nov05 CTP-related links together in a spot where I could find them later. In addition to being closer to what we plan on shipping, this CTP also works with VS05 RTM:

• WinFX Readme
• What’s New in WPF
• WinFX Runtime Components (WCF, WPF and WF)
• WinFX SDK
• VS05 Extensions for WCF and WPF
• VS05 Extensions for WF

Enjoy!

If I’ve got an Avalon Button, e.g.

Should I give the button a name so I can handle the event (I would never put the event handler directly in the XAML) like this:

Or, should I define a custom command and invoke it like this:

Defining a command seems like overkill (you do some stuff in the static ctor and some other stuff in the instance ctor), but I like consistency, e.g. my main window’s menu will use commands.

Thoughts on the best practice here?

The one where I finally figure out how to get wca integrated with my WF VS projects in a sane way.

John Gossman, architect on the Sparkle team, has just made a post about how Sparkle uses data binding to hook up the view of the data to the data itself.

Interestingly, his post isn’t about whether they used data binding — that’s a foregone conclusion. Data binding is so powerful that pretty much every non-trivial Avalon app will use it, and Sparkle (a large app with a very rich UI) uses the hell out of it.

The main thrust of the Model/View/ViewModel architecture seems to be that on top of the data (“the Model”), there’s another layer of non-visual components (“the ViewModel”) that map the concepts of the data more closely to the concepts of the view of the data (“the View”). It’s the ViewModel that the View binds to, not the Model directly.

I’ve been a fan of value converters (implementations of IValueConverter) for this kind of work, but John’s technique has its charms, not least that it allows for much more radical slicing and dicing than value converters allow easily.

To further drive home the point that I am not a graphic artist, Adam Nathan has posted his Avalon port of network Hearts. Wow.

Today Microsoft has published the release candidate of Avalon and Indigo Beta 1. The most interesting features of this release over the CTP releases of the past is that these bits work on Visual Studio 2005 beta 2, both full and express. Enjoy!

Sean Gerety has updated his Avalon sparklines implementation, producing good news, bad news and more good news:

• good news: the sparklines implementation fits nicely in with the other Avalon elements
• bad news: MSFT stock is dead, dead, dead
• good news: sparklines shows how dead MSFT is very nicely!

Sweet!

Wow. This looks really cool.

[from Mike Swanson]

Gene Webb, Microsoft developer evangelist, has posted the recorded LiveMeeting Indigo SDR (Software Design Review) dry-run videos and slides. And as if that weren’t enough, you can see Steve Swartz, Indigo Architect, give an intro to Indigo on MSDN TV.

I remember a day when SDRs were deep, secret mojo that even folks that knew about them were special, let along actually attending them. Now, we’re posting them on the internet. I love my company.

[from Aaron Skonnard]

It took a coupla days more than we wanted ’cuz I was fighting with some internal tools, but the March 2005 Avalon/Indigo CTP is available for public download.

Make sure you follow the instructions on the download page and only use it with the February CTP release of Visual Studio 2005, i.e. don’t use it against the Whidbey beta 2 that’ll “coming soon*” to a theater near you.

* for some definition of “coming soon…”

If you’re not getting enough Chris Anderson in your diet (and who is?!?), check out these two new interviews:

• ServerSide.NET TechTalk: Chris Anderson on Avalon video
• .NET Rocks: Chris Anderson and the Longhorn Evangelism Team

Enjoy!

Did you miss the Microsoft’s Day of Indigo at VSLive? Have no fear — you can trade your personal details for free access to the entire day of videos from the FTP web site, including:

• Keynote: Introducing Indigo, Eric Rudder, Senior VP of Servers and Tools
• Programming Indigo, Don Box and Steve Swartz
• Building Secure Services, Doug Purdy
• Building Reliable, Asynchronous Services, Shy Cohen
• Orchestrating Service-Oriented Apps With Indigo and BizTalk, Michael Woods (Microsoft) and Curt Peterson (Neudesic)
• Indigo Upgrade and Interoperability, Steve Swartz and Anand Rajagopalan
• Building Service-Oriented Applications Today, Rich Turner

Enjoy!

Clemens Vasters, international man of mystery, has given up his normal weekend activities of partying and espionage to give us three pieces exploring Indigo:

• A Weekend With Indigo. Part 1: Simple Messaging
• A Weekend With Indigo. Part 2: Fun with Messaging and Explicit Addressing
• A Weekend With Indigo. Part 3: Hard-Core Messaging. Duplex Conversations.

Thanks for helping to make the world safe for messaging, Clemens! : )

Assuming you don’t have the luxury of dipping the machines your .NET 1.x applications run on in Lucite, you are going to have to make sure that your apps run under .NET 2.0. Normally, that means testing your applications under .NET 2.0 and making changes. However, right now, Jay Roxe at Microsoft is beefing up the .NET 2.0 compatibility test suite, so if there are compatibility problems in your apps, there’s a good chance* that MS will actually apply fixes to the .NET 2.0 framework itself instead of requiring you to make changes to your app.

Jay’s especially interested in “corporate-scale” applications, but I’m sure he’ll consider whatever you’ve got. Don’t be shy! Get your apps into consideration for the .NET 2.0 compatibility test suite today!

* “good chance” == chance > 0, no guarantees, some restrictions apply, void where prohibited, use at your own risk, blah, blah, blah…

Ron DeSerranno, founder and CEO of Mobiform, a company that’s been busy building Avalon and XAML tools since the October 2003 PDC, is giving a talk on how “Avalon in conjunction with XAML will revolutionize the user experience on the web and in desktop applications. XAML and Avalon provide a powerful framework that can provide 2D and 3D graphics, fixed document format, animation and multimedia in a single markup language.”

The talk is at the TechVibes MASSIVE 2005 (clearly named by marketing folks : ), March 30th in Vancouver, BC. Drink a pint for me, eh? : )

Another hot topic among Windows Forms programmers is extensibility:

• Add run-time functionality to your application by providing a plug-in mechanism
• Add Plugins to Your App 2: Search dynamically for plugins without Config Files
• The SharpDevelop add-in tree architecture
• Writing Plugin-Based Applications in .NET
• The MS-INC Plug-In Library
• The Razor Framework :: Part 1 :: Plugins/Extensibility
• Several nifty pieces on Lutz’s Reflector add-in model
• “Customizing the Microsoft .NET Framework Common Language Runtime,” by Steven Pratscher
• On Plug-ins and Extensible Architectures: Avoiding “plug-in hell” is from the Eclipse world, but I’m guessing it applies…

I know there are more pieces than just these, so send them along!

It seems that there are any number of ways to do multi-threading in Windows Forms. Here are some of the interesting techniques:

• Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads, Ian Griffiths
• A number of Ted Pattison’s Basic Instincts column pieces cover threading
• Safe, Simple Multithreading in Windows Forms 1.x (part 1, part 2 and part 3), Chris Sells
• Safe, Even Simpler Multithreading in Windows Forms 2.0, Mike Weinhardt
• Asynchronous Windows Forms Programming, Juval Lwy (provides a BackgroundWorker component for Windows Forms 1.x)
• Making windows forms thread safe, Rüdiger Klaehn (generates a proxy class to do synchronization)
• The Daemon Inside and When to go async?, Matthew Adams

Cristian Civera, a Microsoft .NET MVP, has posted a preview of a tool to convert Windows Enhanced Metafiles, an existing vector graphics file format, to XAML, Avalon’s new format for describing vector graphics (among other things). Thanks, Cristian!

Robert Scoble has some stuff to say about Avalon, Indigo, Longhorn and packaging. Enjoy.

The Las Vegas edition of VSLive (May 8-11, 2005) will include smart client coverage: “SmartClient Live! - Pragmatic and practical advice on smart client development with VB, C#, and .NET Framework.” There’s no real description of what that really means, but it’s got potential. : )

[via 3Leaf]

Mujtaba Syed has some pretty extensive notes from his VSLive Day of Indigo:

• Introducing Indigo: Eric Rudder and Ari Bixhorn
• Programming Indigo: Don Box and Steve Swartz
• WinFX CTP in March ’05
• Indigo upgrade and interop: Steve Swartz and Anand Rajagopalan
• Building Secure Services with Indigo: Doug Purdy
• Building service-oriented applications today: Richard Turner

Thanks, Mujtaba!

″David Chappell provides an architectural overview of ‘Indigo,’ Microsoft’s unified programming model for building service-oriented applications. The paper covers Indigo’s relationship to existing distributed application technologies in the .NET Framework, the basics of creating and consuming Indigo services, and an overview of Indigo’s capabilities, including security, reliable messaging, and transaction support.”

The first article of a new Indigo programming model since PDC03 (and hopefully the one that’ll stick : ).

By far my favorite part of this presentation (except for watching Ari’s heart beat at 155bpm) was watching Eric show the small transitions needed to move existing code to Indigo from ASMX, Enterprise Services, WSE2, MSMQ and Remoting and how well Indigo will integrate with BizTalk and SQL Server in the future. I’m sure it won’t all be changing attributes and removing extraneous code, but if the majority of the porting work fits that model, I’ll be impressed indeed. Of course, as Eric says, there’s no requirement to move your code to Indigo if you don’t want to; the goal of the Indigo team is to make it smooth if you want to.

And finally, Eric says that we’ll be releasing a new WinFX CTP in March, which will include both Avalon and Indigo (although it may be March 38th or March 43rd : ).

If you’re not familiar with the AllowPartiallyTrustedCallersAttribute (pronounced “apt-ka” by those in the know…) or worse, if you just apply it ’til stuff works, you need to read this blog post from Shawn Farkas, SDE/T on the .NET CLR team.

[via Keith Brown]

Mike Marshall over at the 19th hole has been digging into Avalon to experiment with scalable graphics, golf, ClickOnce and 3rd party drawing tools. Check out these installments:

• My foray into the Avalon CTP
• The first hurdle: Creating Complex XAML Paths the Quick and Painless Way
• Step 2: Adding custom XAML attributes
• more to come…

I love that folks have started to document their learning processes on their blogs. There’s no better way for the WinFX folks to get a look at how folks are approaching their technology. Keep it up!

Shawn Burke, Dev. Manager on the Windows Forms team, thinks that MS has finally figured out the problem with controls disappearing from the Designer and points to a fix, mentions an SP for VS03 and promises these fixes applied to VS05.

Shawn, on behalf of the Windows Forms developer community, I’d like to just say: Wahoo!

I didn’t know that I’d been nominated, but apparently I was canonized yesterday as the Patron Saint of Smart Client Applications. I promise to be a firm but fair Deity. : )

Rod Paddock sat down to use Avalon in a real way and then kept notes.

Some of those notes said good things about Avalon

Some of them said not so good things.

While we appreciate the good things, we need to hear about the bad things. And we appreciate it. Thanks, Rod!

Keep it coming!

Ford McKinstry, PM on the Microsoft Indigo team, gives us a hint as to when the next preview release of the Indigo bits will be available:

“We are planning a CTP release with Indigo soon after the VSLive event. But  it will not be available simultaneously with VSLive. We’re moving on it as quickly as we can and we appreciate your interest and patience. –Ford McKinstry, Indigo Program Manager”

[via Stuart Celarier]

I just noticed these two posts from Steve Makofsky formatting web content for compact devices:

• Pocket IE
• dasBlog and .Text on Pocket IE

Mostly, I’d listing these links for myself, as I’ve a hankering for some Smart Phone programming…

If you’re not sure what the heck a Smart Client is, Tim Huckaby explains it like no other:

″This webcast defines the ‘smart client’ and explores the implications and opportunities for smart client application development. The session will focus heavily on high level demos of technologies like Windows Forms, Compact Framework, and Office System 2003 technologies. It will delve into the tips and tricks, positives and negatives when designing, developing and deploying .NET Smart Client applications. .NET Smart Client Applications can run on many different types of devices and in many different scenarios. Join this webcast to learn when it’s smartest to create rich or thin client applications and about how each type handles data and connectivity.”

I just noticed this on the MSDN Webcast list. I’m hoping to attend myself!

“The upcoming 2.0 release of .NET offers many new features and enhancements for the Microsoft .NET Compact Framework and also for the standard Microsoft .NET Framework and Microsoft Visual Studio IDE. In this presentation, Derek Ferguson, Editor-in-Chief of the .NET Developer’s Journal, will provide a complete introduction to writing device-based applications using Compact Framework 2.0. Full coding demonstrations will be presented, so you are ready to catch the next wave in mobile .NET technology! Previous experience writing managed applications is assumed, but no specific experience with the Compact Framework is required.”

Do you have a series of simple yet compelling ClickOnce applications in you that you can build and deliver to show off the benefits of Windows Forms 2.0 smart clients? Do you have a track record of delivering top-quality code on time and on budget?

If so, send me a proposal, listing a series of ClickOnce applications, your schedule and your price. You don’t have to be a 3Leaf, a PluralSight, a Relevance LLC, a Wintellect or a DevelopMentor (although I’d be happy to hear from those guys, too!). You just have to have a song in your heart, a snap in your step and a story to tell.

By popular demand, the Avalon team has provided the November 2004 Avalon Community Technology Preview for the general public. In addition, the team has provided a batch file to enable the Avalon project item templates for use in the beta of Visual Studio 2005 Express Edition, which is also freely available to the general public.

This combination enables folks without an MSDN Subscription to try out Avalon with Visual Studio 2005 without an MSDN Subscription.

Don’t be shy about giving feedback on these bits now that you’ve got ’em. The Avalon team is standing by in the Avalon newsgroup to answer your questions and take your suggestions.

If you’ve got .NET 2.0 and the Nov. ’04 Avalon CTP, click here to play my scaling, vector-based, WinFX version of Solitaire. Features include lovely scaling of the cards as the window resizes, real-time drag ‘n’ drop of the cards, sol-like card stacking, ClickOnce deployment and the source. The performance isn’t yet what I’d like it to be because I’m loading the card back resource 52 times, but it’ll get there. Enjoy!

And while we’re on the topic of real-world .NET Smart Client applications, you can’t not take a look at the Washington State University course work resulting in Paint.NET, an all-.NET implementation of a painting program that was initially aimed at merely replacing MS Paint Brush, but has long ago far surpassed it with painting features found only in commercial painting applications.

And, like SharpDevelop, if you like what you see and want to know how a feature was implemented, you have only to download the Paint.NET source code.

Also, don’t forget to check back in mid to late January for Paint.NET 2.1!

APress has made Dissecting a C# Application: Inside SharpDevelop, the book that describes the history and design of SharpDevelop, freely available for download and I’m enjoying it immensely.

I’ve only read the 1st 2 chapters, but the authors have already provided me a nice overview of the major features in SharpDevelop and how they came to be over the history of the project. I’m also very much looking forward to the implementation details later in the book, particularly the add-in model, internationalization, implementing the Windows Forms Designer and, of course, code generation.

For anyone building a real client-side .NET application, this book is bound to give you clues on how to do it better. Recommended.

And as if that weren’t enough, because SharpDevelop is an open source project, if any of the features tickle your fancy, you can download the SourceDevelop code to see how they were implemented.

I liked the new “How Do I…?” section of the references pages in the WinFX SDK before, but when I ran into the “How do I make an element spin in place?” section of the System.Windows.Shapes.Rectangle (I mean, I need to make elements spin in place all the time!), I fell in love. : )

Rob has posted a description and a couple of work-arounds to a problem some folks are having w/ 100% CPU utilization after an Avalon project is compiled in Visual Studio 2005 beta 1 + the Nov. ’04 Avalon CTP + C#.

If his solution doesn’t work for you (it didn’t for me, but I think I have a weird build), under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor, try setting the UpdateRegisterDesignViewOnIdle value to 0 instead of 1. I don’t know what this turns off, but it makes the problem go away. If you trust me, I’ve put together a reg file that sets this value for you here.

BTW, if you’re wondering what happens when you turn the UpdateRegisterDesignViewOnIdle option off, it’s the feature that notices if you take a random code file and add a System.Windows.Forms.Form as a base class so that when you open the file, it’s opened in the Windows Forms Designer by default. Without this flag, VS will never notice a new Form in a code file and they’ll be no way to edit the Form in the Windows Forms Designer (not even Open With [even though every other editor is in the list…]). If you add a new Form by choosing to Add->Windows Form to the project (as most folks do), all works as expected.

However, if you absolutely need to turn a code file into a file that will open in the Windows Forms Designer, you can close the project in VS, open it in notepad and change the following:



or the following:


    Code


to the following:


    Form


Thanks to Cyrus Najmabadi and Izzy Gryko — hard-working MS employees answering my emails on New Year’s Eve even when they’re officially Out Of Office — for this tips!

“Aurora is a graphical designer developed to create and edit Avalon Windows, elements, and controls. Aurora is built on top of Avalon and renders using the Avalon API. Aurora is designed for use with the November 2004 Avalon Technology Preview Community for Windows XP (CTP).”

Cool!

“The Adobe® Illustrator® SVG Edition of XAMLConverter is now available for free evaluation. The process is as simple is running XAMLConverter, dragging an SVG exported from Adobe® Illustrator® onto the application and the file is automatically converted to XAML. In addition, XAMLConverter runs the XAML file so you may view the results.

“This edition can convert SVG created by tools other than Adobe® Illustrator®. But SVG exported from Adobe® Illustrator® is the only fully supported subset of SVG.”

I said that animation in Avalon is simple. Ian said that it’s hard. We’re both right (I was talking about the programming model and Ian is talking about the nuts and bolts of the implementation), but Ian seems more right because of those fabulous example pictures that explain why wagon wheels look like they’re going backward. Now if he could only explain why computer screens in movies always look like they’ve been engineered to invoke seizures, we’d have something!

John Montgomery wants to know:

“[W]hen it comes to Avalon and Windows Forms interop, I’m curious: how many people will use it and what will they use it for? What are the scenarios that we’ll see? I have my own opinions, of course, but I’m curious about what you think. I’d like to be able to have a conversation with both teams about what scenarios we should optimize for.”

Don’t be shy! Let him know what it is you’re looking for from Avalon and Windows Form integration!

The Avalon experiments keep on happening. This time, check out Avalon Chess!

I’ve long held the belief that the big deal about Avalon is that it provided a platform for a whole new class of data visualization and manipulation software, stuff that most of us can’t even dream of right now. But Edward Tufte can dream of it and in one of his dreams, he invented Sparklines, a very nice way to integrate graphics directly into a sentence instead of relegating it to a whole other paragraph.

As evidence of the power of Avalon to enable the next-gen UI, Sean Gerety has provided an Avalon implementation of Sparklines. Excellent work, Sean.

Read Rod Paddock’s Adventures in Avalon as he installs and binds to a DataSet:

• Avalon Adventures Part 0 : The Setup
• Avalon Adventures Part 1 : Data Access
• Avalon Adventures Part 2 : Basic Data Binding
• Avalon Adventures Part 3: Lists With Style
• Avalon Adventures Part 4: An Event to Remember
• Avalon Adventures Part 5: The Conversion
• Avalon Adventures Summary: The Good, the Bad and the Ugly

Because Ian doesn’t have blog comments and because the Avalon Animation team doesn’t yet have a blog, Elizabeth Nelson (PM) and Matt Calkins (SDE) have asked that I post the following response to Ian’s recent Animating Custom Types in Avalon post:

“I’m happy to report that building custom animations to animate font size is not necessary. (Nevertheless, Ian Griffiths’s sample is a spiffy example of how to build custom animations!) For the time being, TextEffects provides just the font size animation tools he seeks. There’s even a TextEffects sample in the Avalon CTP Announcement that Arik, Karsten and Tim put together. The properties of interest for font size animations are ScaleX and ScaleY.

“This isn’t the end of the story on Font animations — we’re still working on hooking a few things up internally to make it easier to use animations. Regardless of what else we cook up for built-in Font animations, TextEffects will come in handy for animating individual characters in a string in a coordinated manner.

“As for the concern about rendering artifacts when enlarging text, the issue is definitely on our radar!

“Thanks for your enthusiasm for custom animations.”

but it wasn’t until Woodward and Bernstein shared it with the world that he did anything about it. Now that we’ve got an Avalon that works with Windows XP and Visual Studio, if there’s something about it that you don’t like, blog about it or post to the Avalon newsgroup. Cry out loud! Don’t keep it inside. Don’t learn how to hide your feelings…

P.S. I *know* that there are some folks that want the Avalon CTP bits that don’t have MSDN subscriptions. You have my most sincere apologies.

P.P.S. I don’t mean to call the Avalon guys crooks. Those guys work super hard to build the right thing and they’re dying for the feedback. That makes them *very* different than Nixon, who really didn’t want the feedback he got. : )

John Montgomery, Microsoft Marketing Maven in charge of .NET and WinFX messaging, has posted the road map agreed on by the Windows Forms and Avalon teams about which UI stack to use and when (an excerpt is presented here):

“Microsoft’s roadmap for client UI development has three main phases:

1. “Today, use Windows Forms v1.1 and observe the Microsoft Patterns and Practices guidance for maintaining clean separation between UI and other application logic.
2. “When Avalon v1.0 releases (scheduled for mid-2006), we recommend that applications looking to differentiate their user interface such as Web sites and graphically intensive applications such as complex data visualization look closely at Avalon. Other applications should continue using Windows Forms.
3. “Following the release of Avalon 1.0, the next version of Visual Studio following Visual Studio 2005 will contain tools and designers to support Avalon. At this point, customers should start to move their new development efforts to Avalon and use the Windows Forms/Avalon interoperability features.”

Ian gives into peer pressure (I love the Internet : ) and posts an update to his DirectX mesh (.x) files to XAML conversion tool that works with the Avalon CTP.

Now that we have an Avalon that works with WinXP and VS05, what’s holding you back?

Richard Childress has posted on his experiences with the Smart Client Offline Application Block as valuable for not only solving his domain-specific problem, but also in getting .NET to be used at all:

“Working in IT, where we try to only write code that helps run our business, it’s a Great Thing when you don’t have to write plumbing code. Writing a class here and another class there, while leveraging a big chunk of code that we didn’t write to solve a problem, is golden. This block, itself, is actually helping drive the case for starting to incorporate the framework into our app(s). The value is unquestionable.”

As cool as XamlPad and Bouncing Boing Ball are, I’ve had at least one blog comment from someone looking for a useful Avalon CTP application (something not targeted at developers, I’m guessing). Well look no more, because we have Pong! What more use can we expect from our computers than that?!? : )

So, I’ve never done anything with Python, so I’ve never really figured out what the big deal was. However, if the interactive Python development environment is anything like the experience of XamlPad, I’m glad I haven’t tried it, otherwise I’d never be able to go back.

Oh my god, that interactive model is wonderful! I sat down this afternoon to port my Longhorn Solitaire code to the Avalon CTP and had to completely re-write my GridPanel layout code to use the new Grid because the GridPanel is deprecated. However, I didn’t know a thing about the Grid, so found a great little Grid sample from the WinFX SDK and started the latest version of XamlPad and taught myself how to use the Grid interactively.

Every time I added an element or attribute, I saw the results in real-time. If I screwed up the syntax, I got a red error message in the status bar. I can’t tell you how much pleasure I got adding and elements and setting the Grid.Row and Grid.Column attributes on my cell elements, watching things move around the screen and figuring out Grid the content model. It was fabulous! All development should be like this…

As cool as Chris Anderson’s XamlPad sample is, I think Gaston “I’m a VS man” Milano has done him one better with a XAML viewer integrated directly into Visual Studio 2005 beta 1. Wahoo!

Robi Khan and Mark Levison from Databeacon will be doing a MSDN DevChat on their recent commercial application using No-Touch Deployment. It’s on Wednesday, November 24, 2004 at 10am PST. I’ll be watching and you can sign up here.

This just in: Chris has posted a version of his XamlPad Clone on a server via ClickOnce so you can just run it directly (and it works, too! Wahoo!).

Plus, Ian’s posted a hack to the sample that Chris’s XamlPad Clone comes with. Fun. : )

Just in case you haven’t noticed, MSDN Subscribers should download the Avalon Community Technology Preview, which enables Avalon to run under Windows XP and Windows Server 2003 and to integrate with Visual Studio 2005. Also, you can access the WinFX SDK that reference Avalon online. And as if that weren’t enough, the Avalon evangelist and product teams have teamed up to give you an overview of what’s new in this pre-release of Avalon. Of course, we’re still on the way to beta, let alone an RTM of Avalon, so there’s still plenty of time to give the Avalon team feedback about what you love and don’t love in the Avalon newsgroup.

And as if that we’re enough, here’s some views and news about the Avalon CTP:

• 3rd public release of Avalon…a few details on the development experience
• Avalon CTP released!!!
• And So It Starts Again… Avalon Community Technical Preview Released
• Avalon is Back
• Microsoft gives developers a glimpse of Avalon
• Microsoft Previews Avalon for Developers
• Microsoft Releases Avalon Tech Preview for XP, 2003
• Early Avalon Build Is Out, But Not for Longhorn
• Avalon CTP Release - bring on the 3D!
• XAML Tidbits Previewed in Microsoft’s Avalon
• Microsoft’s Avalon Will Make Networked Applications Smarter

In the words of Chris Anderson, Architect on the Avalon team, “This is not the final API set, XAML spec, or anything else - this is a ‘Technology Preview’”. And still, I’ve spent all day installing in on my machine. Wahoo!

For me, things boil down this way: if it’s something I’ve got to spend significant time in, I really want it to be a smart client, otherwise I’m going to get frustrated. For example, Outlook Web Access is great for occasional use from any PC under the sun, but if I’m using it for more than 5 minutes, I’m guaranteed to press a hotkey like Ctrl+A and get nothing like I expect, forcing me to find my laptop so I can get some real work done in Outlook.

Jonathan Wells, Matt Lusher and I have re-launched the MSDN Smart Client Developer Center web site, kicking off the new site with four headlines of interest:

• Smart Clients Defined: just so we’re all clear what the heck a smart client is
• Windows Forms Bug Reporting Challenge: the Windows Forms team is giving away branded backpacks and t-shirts to top Windows Forms 2.0 bug reporters
• Business Desktop Deployment Framework: all you’d ever want to know about deploying Windows in an enterprise so that you’ve got a suitable platform on which to deploy smart client applications
• Welcome to the MSDN Smart Client Developer Center: Rebooted: a message from Jonathan Wells and me (Wells & Sells) about the goals of the Smart Client DevCenter and how to make the most of it

Since the Smart Client DevCenter now has a Content Strategist (me), expect to see regular releases of articles and samples exploring smart client-related technologies, including but not limited to Windows Forms, the Compact Framework and Visual Studio Tools for Office.

And don’t hesitate to send Jonathan or me your complaints and suggestions. We don’t put this site up for our health, you know; we do it for you!

“Bill Wagner takes us through using the more extensible Updater Application Block to automatically install and maintain applications. He also discusses the importance of validation and how to use post processing commands.”

[via theserverside.net]

Mark Levison of Databeacon talks about the first commercial-grade .NET No-Touch Deployment application to be deployed over the internet (at least, as far as he and I know). I asked Mark what his motivations were for using a smart client instead of a web app. These were his reasons:

1. “Integration with Desktop – export to excel, word, send to mail recipient, etc.
2. “The user never has to wait for a round trip to the server. Once the application is up and running everything is done locally, the user is never left waiting by a suddenly slow internet connection.
3. “Our application gets a full blown window with its menu and toolbar, we’re not stuck inside of IE.
4. “Uses the clients CPU do all of work. Our application is graphically and sometimes computationally intensive, if we did all of this work server side, we would eventually run into scaling problems.”

Congrats Mark and Databeacon. This is but the beginning of much greater things to come.

NOTE: I don’t know if this was exuberance at making the instructions for running the sample easy or not, but you should absolutely not “[u]se the Microsoft .NET Framework wizard to grant full trust to trusted sites.” Trusted or not, you should not award any code any more permission than it needs. For instructions on how to build an MSI setup for configuring a NTD client for just the right amount of permissions until you can use ClickOnce (which handles permission elevation much better than NTD), you can read this article on the topic.

My Windows Forms partner in crime, Mike Weinhardt, pointed out to me this morning that the Windows Forms team has posted their way cool Windows Forms 2.0 samples, including:

• Design Mode Dialog - Mike Harsh
  This is a sample dialog component that allows any form to go into “design mode” at runtime. This component highlights the new, easy to consume, designer infrastructure APIs in Whidbey and has the same usage pattern as other common dialogs.
• Stock Quote Chart Generator - Joe Stegman
  This app uses the sample asynchronously polls a web service for stock quotes and charts the results over a customizable time period.
• MSN Messenger Clone - Scott Morrison
  This is a Windows Forms app that emulates the functionality of MSN Messenger.
• Internet Explorer Clone - Joe Stegman
  This is a Windows Forms app that looks like Internet Explorer 6 and uses the new WebBrowser control.
• Windows Forms RSS Portal - Joe Stegman
  This is portal type application that aggregates RSS feeds asynchronously.
• Outlook 2003 Clone - Joe Stegman
  This is a UI front end that has the look and feel of Microsoft Outlook 2003.

I’m downloading this now, but anytime I get a chance to see Don Box or Doug Purdy speak, I want to do it. To see them both together?!? Oh la la!

And after watching them together on the latest .NET Show, I get to see them again next week at the Applied XML Developer’s Conference. How lucky am I? : )

Rob’s been talking about fixing various parts of XAML lately, which is exactly the kind of result you want when a bunch of folks work with your technology and give you feedback on it. So, things will change and get better.

However, Rob isn’t telling us just want the changes are likely to be because, as he puts it, “I’m not going into great detail in the description of our fix because I’d prefer to be the first company to ship our design.  :-)”

Like Rob, I find this amusing. I grew up in a period of Microsoft’s life where they were much derided for “leveraging” ideas from the rest of the world and repurposing them for use in Windows (or *as* Windows in some cases). Now that MS has caught up and passed most of the rest of the world in many crucial areas of technology, it’s nice to see us grow into the role of thought leader instead of follower.

The one where I get to try out the interaction between VS05, Windows Forms 2.0, application and user settings (wahoo!), generics and versioning, discovering that, while this combo still in beta, it’s still pretty darn wonderful.

If I’m doing the calculations correctly, Ryan Dawson is not yet old enough to drink, but he still manages to give the best, most direct, most thorough feedback of anyone in the WinFX/Longhorn developer community (Ian Griffiths is a close second, but he’s got that English polite thing going for him, so it’s hard to know just how much he’s really complaining : ). Ryan’s built apps to test the various pillars and makes his complaints very clear, as in this post about Avalon 3D.

That’s not to say that I agree with everything he says or that the product team agrees, but I wish I had 100 more Ryan Dawson’s banging on the pillars and complaining loudly and clearly so that the product teams can get some crystal clear feedback on what works, what doesn’t and what developers want. If you don’t have a blog, get one or post your complaints on the newsgroups. Come on! Tell us why we suck and what to do to stop sucking! You know you want to. : )

I’ve recently added another castle to my empire by taking on the Content Strategist duties for the MSDN Smart Client Developer Center.

When I step into a new project, my typical mode of operations is to gather goals and issues from as many people as care that I can find, stir it all up with what I think is important, run it up the flag pole, repair the bullet holes a few times and then execute. I’m in the “gather” mode on the SCDC right now and I’m curious what your goals and issues are for the SCDC as it stands today and for what you’d hope it to become tomorrow. Feel free to respond to this post (even anonymously if it makes you feel more comfortable) or email me. The idea is that the SCDC becomes a valuable place for Microsoft developers building Smart Clients of all kinds, but particularly using Windows Forms, the Compact Framework, Visual Studio Tools for Office (did you know that they have a ClickOnce equivalent?) and WinFX.

BTW, I’m still the Content Strategist for the Longhorn DevCenter, so don’t go getting your hopes up that I’ll stop beating that particular drum. : )

Well, to be fair, Don leaves some details out, but he wanted to see if he could explain Indigo in 5 minutes or less. Worth the read.

Brian Pepin, Development Lead on the Windows Forms team, has some interesting observations about Avalon and what it means to developers. I particularly like his take on Avalon vs. Windows Forms for control developers and users:

“[Avalon is] needed by control developers everywhere so they can create controls with great usability without hiring an army of Win32 experts. It’s needed by end users because they deserve to have great usability in all their applications, not just the ones that Microsoft threw a bazillion dollars at.”

I also like what he has to say about Avalon vs. Windows Forms for application developers:

“It’s also important to realize that from an application developer’s perspective, there is little difference between Avalon and Windows Forms. For years there will be interesting controls built from both technologies.”

In other words, Avalon is the necessary next step to build more powerful controls so that users get the most out of their applications without requiring a giant change in development methodology for application developers.

[via Chris Anderson]

Mike Harsh, a PM on the Windows Forms team, gives his opinion on several important Windows Forms and Avalon-related questions:

• Is [Windows Forms 2.0 as the last version of Windows Forms] a bad thing from a developer perspective?
• So UI library innovation for Windows Forms is finished.  Does that make it dead? (no)
• Is it worth investing in Windows Forms? (yes)
• Will Windows Forms apps be able to integrate Longhorn controls in under 5 lines of code? (absolutely)
• If I invest in a large Windows Forms app today will I have to rewrite it in 3 years for Avalon?

These are Mike’s opinions and not official Microsoft messaging, but I’ll leave you to decide whether that’s worse or better. : )

That was interesting. I spent all week getting ready for the big announcement, we launched it on a Friday and then I took off for a week of fun in the sun. And now, it’s taken me a week to catch up with what everyone is thinking. People I’ve found particular interesting are:

• Chris Anderson, Architect on the Avalon team (1, 2, 3, 4, 5)
• Joe Beda, recently formerly on the Avalon team (1)
• Jeremy Mazner, Longhorn Evangelist (1, 2)
• Robert Scoble, MS RSS Filler (1, 2)
• Miguel de Icaza, Architect on the Mono project, a .NET clone (1, 2)
• Robert McLaws, a 3rd party developer (1, 2)
• Jason Olson, a 3rd party developer (1, 2)
• Jim Allchin, Group VP for Platforms (1)

In the meantime, I’m re-aligning the Longhorn DevCenter content with our new goals, making sure to keep on my toes as things suss out (we’re far from completely sussed on the details or implementations of this announcement, which is why watching internal and external commentary is so interesting right now).

Channel9 has the latest Windows/WinFX/Longhorn/WinFS/Avalon/Indigo skinny right from the horse’s mouth: Jim Allchin the Group VP in charge of Windows.

Lots of interesting news about the plan to make WinFX available on Windows XP and Windows 2003:

• Press release:  Microsoft Announces 2006 Target Date for Broad Availability Of Windows “Longhorn” Client Operating System
• Note from David Treadwell, the Grand Poobah of WinFX
• Longhorn Developer Center Editor’s Note from yours truly
• New Longhorn Developer FAQ section: WinFX on Down-Level Windows
• New WinFS page on the MSDN Data Developer Center

Enjoy.

Joe Marini is working with Longhorn, Avalon and XAML on a Microsoft product team and finds that he really loves XAML. This, in and off itself, is not surprising (I mean, that’s what we’re paying him for : ), but it’s interesting to hear the specifics.

One thing that Joe seems to love (and I can hardly blame him) is that data binding in Avalon is used to build the UI, not just show external data. He expounds on this in his wonderful Data Bound User Interfaces in XAML article.

Another thing that Joe loves is that a Avalon designer’s work is in the same format as what the designer needs and can be dropped right into an app w/o converting from bitmap mock-ups (Peter Stern and I are doing this).

You can read about the work that Joe has done with XAML and download his code samples on his web site’s tutorial section. Joe is definitely one to watch in the Longhorn/Avalon space.

Arun Bhatnagar found Longhorn on Mars today:

“I am a software developer who is currently working on C#/.net in Canada. Like so many other developers I am really excited about the features in Longhorn. I am waiting for it and so it is really good to know that Longhorn already exists on Mars. Yes, that’s what USA Today reported today. Read the caption beside the image in this story.”

Apparently NASA’s in the early adopter program… : )

It’s easy to forget the real people behind any given project, especially one the size of Indigo with Don as the pretty figure head. In this video, Don (via Robert and Channel9) shows you a fraction of the people that work on the team and they reveal their deepest past implementation shames and triumphs. Put a face on CoInitializeSecurity and enjoy.

Mike Weinhardt lists his favorite new features in Windows Forms 2.0, not only bringing my “butt” into it, but making it sound like a good thing. : )

I find these strangely compelling, especially this one:

Languages Zen Koan:
“One day Fred was working with .NET. He overheard a programmer say to his superior, “Give me the best programming language you have.” “Every language in .NET is the best,” replied the butcher. “You can not find any language in .NET that is not the best.” At these words, Fred was enlightened.”

DonXML has ported his SVG to XAML conversion tool to the WinHEC build of Longhorn and provides the source as well as the binary on his GotDotNet workspace.

Eventually, we’ll be awash in real tools that output XAML, but until then conversion tools are important so that real artists can use the tools with which they’re already familiar, output them into a vector format supported by that tool and then convert them to XAML for use in Longhorn apps.

Looking for the a job in Longhorn? CareerBuilder.com has 5 Longhorn jobs listed:

• Software Development Lead, Microsoft
• Program Manager, Microsoft
• Application Developer, Microsoft
• Bussers, Longhorn Steakhouse
• Trailer Technicians, Lancaster, TX

Those last two look tasty. : )

Peter Stern, one of MSDN’s most excellent user experience and graphic designers, has started up a web site, with a special section just for fun Longhorn-related stuff, including a complete deck of card faces in XAML and his drawings of yours truly from the Longhorn Developer Center in XAML format.

I’ve been corrupting Peter’s thinking toward Longhorn for a few months now and I’ve fabulously happy to have him as the other half of that magical ying/yang designer/developer relationship that Avalon fosters.

There’s a smart client app that I’ve found myself using more and more and loving it: robocopy. The UI for robocopy sucks, of course. It’s a command line app with a myriad of options that take experimentation to really figure out, but once it’s started, it works like a champ, providing progress on each file and, most importantly, retrying once it loses it’s network connection.

What this allows me to do is set up long copy operations bringing down the latest internal Longhorn builds (which are huge) over my uncertain VPN connection. When I hibernate my box, I don’t worry about Robocopy dropping bits or getting confused and when I lose my internet or VPN connection, it retires 1 *million* times before giving up, which gives me plenty of time to notice and reestablish the connection.

Slap a friendlier UI on Robocopy and you’ve got a wonderful smart client citizen that should be emulated.

According to Computerworld, Don Norman, the design engineer famous for such works as “The Design of Everyday Things,” is consulting on Longhorn UI design. Cool! I especially love this statement:

“This is not the ‘computer age’ any more; this is the age of very smart chips hooked into a huge worldwide network. Infrastructure is about sharing.” This means two or more incompatible ways of doing things is counterproductive.

I love his characterization of client computers as “smart chips,” i.e. storing services and data production on the server, although the “smarts” of the client is important, too, i.e. data visualization and manipulation (which is death with a round-trip per click).

In Ian Griffith’s latest post, he shows 3 identical (to my eye) upper case Os next to each other and says, “[t]his clearly shows the shortcomings of that implementation” like a normal human can tell the difference!

The funny thing is, I’ve actually noticed that ClearType on Longhorn was generally better, although I never knew if that was my imagination or not. The thing I love about Ian is that he takes that vague sense of “this seems better” to “let me show you why it’s better and I’ll show you my own implementation of ClearType as a comparison just for fun.” What’s not to love? : )

After weeks of trying research, floating his thoughts on his blog and taking feedback from the blogging community (including several Microsoft folks), Jon Udell has posted an Infoworld article digging into the pillars of Longhorn (Avalon, Indigo and WinFS) and grading them on their implications. He summarizes nicely, I think:

“Indigo, by virtue of its developer-friendly simplification of Web services protocols, could propel Microsoft into the forefront of enterprise middleware. Although Longhorn’s use of Indigo will focus on networks of Windows peers, the technology isn’t bound to Longhorn. Expect to see Indigo-powered ‘enterprise service bus’ offerings from Microsoft and partners.”

“If WinFS succeeds in delivering improvements in users’ ability to organize and manage local information, enterprises looking to drive productivity up — and support costs down — will want it. The wild card will be the level of support for legacy document formats and emerging XML formats. Benefits that accrue only to new WinFS-aware applications won’t tip the scale.”

“Avalon’s TV-like ‘presentation experiences’ clearly favor the home entertainment center over the business desktop. An accelerated convergence of voice, video, and data could alter that equation, and Avalon is designed to help drive that convergence. But enterprises concerned about reach and lock-in will need to carefully evaluate the trade-offs.”

I think that Jon’s nails the tensions involved in Indigo and WinFS, but misses the boat on Avalon, which represents a much-needed overhaul of our aging presentation sub-system and enables a host of applications that we need to visualize and manipulate the ever increasing amount of data with which we deal. Of course, the existing presentation stack will continue to work just fine, but for those applications that need it, Avalon will be a god send. As we progress over the next decade, more and more apps are going to need what Avalon provides.

However, while I don’t agree with every that Jon says, but I do appreciate the thoroughness that went into his opinions. Folks involved in Longhorn, both inside and outside of Microsoft, should take a look.

According to legend, half the Windows XP BSODs are 3rd party driver crashes, reducing our “trustworthiness” to the user (trust is more than security and privacy). Yesterday, DevSource reported on a new driver model in Longhorn that will isolate the OS from driver crashes and simplify the development platform to reduce crashes in the first place. Amen, brother.

[via Dactylmatrix]

Daniel Lehenbauer, an SDE on the Avalon team, has a nice explanation of the 3D coordinate space in Avalon with some very illustrative pictures. I’ve got absolutely no experience with 3D and I can follow what he’s talking about. Looks like Daniel should be writing a book…

Facetop has been all over the web for a couple of days and I’d like to point out two things about it:

1. This is exactly the kind of thing we’re enabling with the advanced client capabilities in Longhorn that you just couldn’t do in a web app. Until you see something like this, you don’t think of it, but when you’ve got advanced capability in the platform, all kinds of cool stuff happens that the creator of the platform (Apple’s Mac OS X, in this case) never considered. I fully expect the coolest Longhorn apps to come from someone outside of Microsoft.
2. I want it!

Richard Turner, a PM on the Indigo team, answers some of the Indigo questions that came up as a result of his recent Channel9 interview, including:

• Will .NET Remoting go away any time soon? (no)
• Will Indigo Services require IIS? (no)
• We need to support Windows 2000 and XP. Can Indigo Services be hosted on these OSs? (it’s not supported) Will applications running on these OSs be able to act as clients to Indigo Services? (absolutely)
• We expose some of our remoting assemblies via HTTP and host at least one in IIS.  Will Indigo Services offer interoperability with these configurations? (yes) Will we be able to write an Indigo wrapper around a remoting DLL? (yes)

I’ve just realized that Richard has turned into my most favorite Indigo blogger. He straddles the fence nicely between what is available today and what’s going to be available tomorrow. Thanks, Richard. We need you. : )

“The Longhorn speech API offers baked-in functionality for voice commands inside the operating system (OS). This is a giant leap forward in the functionality provided by an OS. With the addition of an alternate user interface, products in the future may have a much different mode of interaction than currently used. Through the course of this article, the basics of voice input and output will be shown, as well as the construction of grammar, and how to act on recognition.”

[via Paul Lamere]

I’m a big cmd.exe user and was a big Korn Shell user before that, so command shells are an important part of my life and thus, I’m skeptical of new ones. However, I’ve been drooling over MSH (the Microsoft Shell — codename Monad) ever since I first saw it. In fact, when I saw Karsten’s post on getting the Monad bits for Windows XP and 2003, I was much excited. Then, I saw the Fundamentals Pillar topic on The .NET Show, which featured Jeffrey Snover (The Father of Monad) in the back half of the show and I was hooked. The way he told the Monad story motivated me to register for the public beta of Monad via Karsten’s instructions and wait impatiently over the weekend to be awarded permissions to download the bits.

Which I promptly installed on the WinHEC build of Longhorn (build 4074), even though it’s only supported for Windows XP and Windows 2003.

As it turns out, Longhorn comes with an earlier preview of Monad, but it’s much older than the latest Monad drop. So, I installed the latest Monad on the latest Longhorn, hoping that it would work and that I could follow along with my new hero Jeffrey.

And follow along I did, because not only did the latest Monad bits install and run just peachy under Longhorn, but the included Getting Started docs gave me hours of fun! With the functionality that Monad provides, I’m going to have a hard time going back to anything else.

If you’re a command-line person, I recommend getting on the Monad beta, taking it for a spin and letting those guys if there’s anything you don’t like (for example, I miss the “start” command, but I think I’ll go build it…).

The benefit of 3D support in Avalon is not the 3D support itself (we’ve had various ways to do 3D stuff in Windows apps for a while now, including both OpenGL and DirectX). The benefit is the tight integration we get between 3D and 2D elements in Avalon (and we’ll get even closer integration as we move closer to the Longhorn release).

For example, in his Avalon 3D Hit Testing Demo, Daniel Lehenbauer shows how hit testing can move into a ViewPort3D element (the representation of a 3D scene in an Avalon display) into the specific element being clicked. In other words, you can have a Button right next to a ViewPort3D showing a teapot and your app can easily tell which one was clicked. Handling a teapot click is slightly harder than handling a Button click simple because the Button does it’s own hit testing, but the Avalon 3D hit testing supports advanced features like clicking through the handle of the teapot w/o that being classified as a “hit,” all of which Daniel explains nicely in his sample.

I know this is almost a year old, but the permutations algorithm was my favorite from STL and I’ve had occassion to miss it since moving to .NET, so it was nice to find Dr. James McCaffrey’s Using Permutations in .NET for Improved Systems Security on msdn.com. The security implications are interesting, I suppose, but permutations are useful than that (like if you’re trying to crush librarians…).

Over the last few weeks, I’ve fallen in love with the power and simplicity of Avalon data binding. In this month’s column, I start a 2 article series by focusing on the basics of data binding in Avalon and tease you with a screen shot of my Longhorn Solitaire application rebuilt using data binding and styles, the details of which I’ll cover in the 2nd part of the series.

Choose an existing technology Foo and imagine a newer, better way of doing the same thing called Bar that’s coming in some number of days/weeks/years. Sean and Scott say that you have the following choices:

A. Blissfully continue to use Foo.
B. Continue to use Foo, but research Bar, and architect for its use once it’s available.
C. Don’t touch Foo with a 10 foot pole. It’s dead after all. Touching it is probably illegal in 46 states.

Some folks hold onto option A too long, while some jump into option C too soon. The answer is almost always B within some delta of “it’s available” that’s appropriate for your business.

Sean and Scott call Foo and Bar “Windows Forms” and “Avalon,” but as they point out, these are the decisions we’re always making on new technologies. What’s the best judge of the delta around “it’s available” for adoption? That’s all about your specific business needs and don’t let peer pressure sway you either way.

Robert McLaws makes an interesting observation about the possibility of consuming XAML from a web server:

“So, if Microsoft wants to blur the lines between a web site and an client-side application, what makes you think that the next version of IIS will not support serving up XAML to the client. Instead of getting a limited browser experience at http://www.longhornblogs.com/default.aspx, what if you could get a super-interactive experience with the full power of the client at http://www.longhornblogs.com/default.xaml? What if, on a mobile device, you could use web services to allow location-aware applications ultra-dynamic, serving up XAML UI code along with data? A thick thin-client? Talk about a contradiction in terms. The possibilities become greatly expanded if you beging looking at what’s in front of you instead of looking behind your shoulder at what’s behind you.”

The future is unwritten.

Chris Anderson just did a fabulous job describing what makes Avalon more extensible than existing popular UI frameworks. What Avalon allows is the ability to have a Button instance like so:

<Window>
  <Button>Hello</Button>
<Window>

And then, somewhere else, using Styles, setting the VisualTree of what a Button looks like to be whatever you like, e.g.

<Style>
  <Button />
  <Style.VisualTree>
    <FlowPanel>
      <!-- anything you like in here,
e.g. <Text>, <Video>, <Rectangle>, whatever -->
      <ContentPresenter />
    </FlowPanel>
  </Style.VisualTree>
</Style>

Two interesting things about this button style. The first is that you can make a Button look however you want it to look, without worrying whether the Avalon team had that in mind up front. Two, when you want to drop in the content inside the Button tag, e.g. “Hello”, you drop in the ContentPresentor and it knows how to display what was placed in the Button (again, which could be anything). Simple and flexible: two things that I’m finding to be true more and more about Avalon the further I dig.

If you’re using Longhorn 4074 and MSBuild is telling you this, ‘The target “GetOutputAssembly” does not exist in the project.’, then try these steps to solve the problem:

• Backup %windows%\microsoft.net\windows\v6.0.4030\WindowsCommon.Target because you’re about to modify it

• In WindowsCommon.Target, replace all GetOutputAssembly with BuildOutputGroup

• Save and Close WindowsCommon.Target

• Re-run MSBuild and enjoy

“If you’re familiar with data binding in Windows Forms or ASP.NET, you ain’t seen nothin’ yet. In this presentation, Chris Sells, Content Strategist for the MSDN Longhorn Developer Center Web site, will cover data binding in Avalon, the new UI stack in Longhorn, Microsoft’s next OS. Chris will cover the basics of data binding and then move into transformers, filters and styling. If you’re going to build UIs in Avalon, you’d be crazy not to use data binding to do it.”

Data Binding in Avalon
6/24/2004, 6:30pm
Portland Community College Auditorium, Room 104
1626 SE Water Avenue
Portland, OR

Some quotes from Anders on Channel9:

“On of the things that we are trying to think about deeply in C# 3.0 is this big gap that I still see between general purpose languages and databases… Anyone who’s building an enterprise app is using both worlds… There’s certainly a lot of progress we can make by truly marrying these worlds… It’s nothing but mismatch. We gotta do away with that.”

Now that we’ve removed memory management from my code and between InitializeComponent and XAML, we’ve removed the need to write UI layout code, the next big chunk that gums up the works is data integration code. To have Anders thinking about how to extend C# 3.0 to mitigate this problem has me all a tingle!

Wesner Moise reports on a talk that Jeff Richter did on the .NET versioning story in the Longhorn time frame. Some interesting quotes:

• “a library could not easily be updated since the CLR looked for an exact version match. There was a complex way to solve this problem through policy files; however, even engineers at Microsoft found this approach too difficult.”
• “Microsoft has a new approach for Longhorn and Orcas (.NET v3.0), which divides assemblies into two categories, Platforms and Libraries.”
• “Most assemblies will or should be libraries. Microsoft discourages the use of platform assemblies.”
• “There are actually three types of platform assemblies: System-wide, process-wide, and app domain-wide.”
• “Longhorn will no longer support multiple CLRs. Every managed application will be forced to use the latest version of the CLR on the system.”
• “Whidbey is expected to include an Assembly attribute, AssemblyFlagsAttribute, which allows to developer to specify Library, AppDomainPlatform, ProcessPlatform, SystemPlatform, or Legacy to identify the versioning scheme the CLR uses to load a reference assembly.”

I know that the existing versioning story doesn’t cut it for a lot of folks. Will this new model solve the problems? Is there a complexity danger?

Also, Ian has some thoughts on the new model.

Rich Turned, an Indigo PM, has some useful things to say about Indigo in his recent Channel9 videos:

• What is the biggest misperception of Indigo?
• What is your advice to developers who are thinking about Indigo and interoperability?
• What would be the first thing about Indigo that you’d show a Visual Basic programmer?

Plus, Rich has a blog to which I subscribe (but I wish he were more prolific).

I’m really loving Jon’s approach to exploring and questioning the goals and implications of Longhorn:

1. Questions about Longhorn, part 1: WinFS
2. Questions about Longhorn, part 2: WinFS and semantics
3. Questions about Longhorn, part 3: Avalon’s enterprise mission

I don’t have any pithy summaries of his basic points; his posts deserve a read and a think.

VisitorVille maps your real-time web site data to a SimCity-like environment that you can use to see where folks are going on your site and how they’re navigating from one place to another. It does the other web traffic kinds of analysis, too, but the ability to watch your visitors in real-time looks pretty darn cool. This is the kind of thing that Longhorn should be good at enabling.

[via Jason Whittingon]

Richard Turner, a PM on the Indigo team, addresses the biggest misperception about Indigo in this Channel9 video.

Bottom line: Microsoft is not taking MSMQ, COM+ or Remoting out of the platform; it’s just that Indigo, which subsumes the features of these other technologies, will do it all better.

Just to be clear, Marc Clifton’s MyXaml framework for adding a declarative UI mark-up language to today’s .NET framework is not a clone/sub-set of Microsoft’s XAML or Avalon targeted at Longhorn. In other words, while MyXaml provides a number of the benefits of declarative UI mark-up for building smart/rich clients today, MyXaml is not a way to write WinForms code today that will seamlessly turn into Avalon code tomorrow.

The reason I mention this is because I’ve seen some folks get a bit confused by the use of “Xaml” in the name (Marc is using XAML as the generic Extensible Application Mark-up Language and not as related to Microsoft’s XAML).

On the other hand, there are two other projects that are aiming to clone/sub-set XAML/Avalon on .NET today: Xamlon and Mobiform’s XAML products. I can’t claim that either of these will actually help you transition to Longhorn when it comes along, but I know that Xamlon’s XAML samples work with minor tweaks on their parser and on the WinHEC build of Longhorn.

Jason Zander, a Microsoft Product Unit Manager, not only points out the implementation problems we have with being able to unload .NET assemblies, he recommends AppDomains as the solution you really want anyway. And then, when his commentors dissent, he’s right back in there asking for more information.

Have you got opinions on this topic? Make hay while the sun shines!

Ian posted a fun little snippet of XAML showing off the new support for image effects on anything that Avalon renders, not just images:

  xmlns:def=“Definition” Text.FontSize=“24″>
  This seems clear enough.
 
   
     
   
    This is considerably less clear.
 

I’ve rewritten it using a more compact syntax:

This is considerably less clear.

1. For 1 free UUID, is this legal XAML? Why or why not?
2. For 2 free UUIDs, what other popular XAML construct uses the exact same syntax?
3. For 3 free UUIDs, what popular C# construct has a similar syntax? How is it subtly different? (Hint: I’m not showing the difference in this example.)

As Wesner notes, the Longhorn SDK lists 3 distinct Avalon applications types: Windows/Forms apps, multi-page apps and documents. The beauty of Avalon is that it brings so many together, apps/documents, multi-window apps/multi-page apps, text/images/video/audio, 2D/3D, etc. And to answer Wesner, Microsoft will provide editing tools for Avalon beyond Notepad (someday…).

Greg Schecter, one of the designers of the new support for 3D in Avalon available in the Longhorn WinHEC build, provides a nice overview and some other links to Avalon 3D resources:

• Greg Schechter’s Introducing 3D in Avalon and 2D/3D Integration
• Basic 3D in the Longhorn SDK
• Joe Beda’s WinHEC report, including a screenshot of an Avalon 3D sample

3D support in Avalon is not meant to build Doom 3, but it does shine especially brightly in two places: 1) you can do 3D in a declarative way in XAML, just like the rest of Avalon and 2) as Greg describes, the integration of 2D and 3D in Avalon is nice and clean the way it isn’t in most current 3D APIs. I’m looking forward to taking advantage of the 3D support in my own apps, which isn’t something I ever considered before with DirectX. Thanks, guys!

The Avalon team has posted their WinHEC slides:

[via Adam Kinney]

Today Jonathan Hodgson has posted a very cool article ostensibly about implementing Squarified Treemaps in Avalon, but he goes much further than that. First, he shows us what his Avalon implementation of Treemaps look like, including providing the source and a Maslan-ese video showing off his creation for those folks that don’t have the Longhorn PDC bits.

Then, Jonathan goes compare standard grid and graph visualizations to Treemaps and to describe the intimate details of the Treemap algorithm.

Later he provides the code-by-code description of his Avalon implementation, showing off the flexibility of XAML and Avalon, but before he does that, he gives us his opinion of why Avalon, the new Longhorn User Experience (UX) and XAML are all important and how Windows Forms fits into this new world.

And as if that weren’t enough, Jonathan than goes on to describe other visualization ideas that he thinks (and I agree) should be considered in this new, more flexible world that Longhorn is going to provide. And at the end, he provides an extensive set of references for further reading on these subjects.

All in all, Jonathan provides a 9500+ word tour de force, spanning prose, pictures, opinion, working code and even video! If he’d have done the voice over, he’d have gotten the whole thing. I put my feet up and worked my way through two cups of Chai tea, three biscuits and several pieces of teriyaki turkey jerky on and off during the day while reading his piece and enjoyed the experience very much. Jonathan covers a great deal of the reasons that we’re going to have to see passed our old barriers in Longhorn and he does it well, mixing his own thoughts with references from around the web on these topics. If you only read one piece on Longhorn this month, read this one.

Sam Druker, Development Team Lead on the WinFS team, has a series of videos on Channel9 talking about a variety of WinFS topics:

• Where do the attributes/metadata come from that WinFS exposes to the shell and to custom applications?
• How pictures could be tagged based on calendar appointments and picture timestamps.
• What kind of search experience will WinFS enable in Longhorn?
• How an existing application, like Outlook Express, could be updated to take advantage of WinFS.
• And most importantly: how developers should prepare today for WinFS tomorrow.

After Business Week reported the death of WinFS, some folks have been justifiably worried that such a cool feature would, in fact, be missing when their copy of Longhorn showed up at their door. Today Toby Whitney, the Group Program Manager of the WinFS team, stepped in to report that WinFS was alive and well:

“WinFS is in good shape and hasn’t been cut from Longhorn.  We’re going to ship it :-).  What we need is your feedback on whether we’re building the right thing.  It’d be great if you went to MSDN and downloaded the newest bits.  They’re much more stable and represent a big evolution of what we’re doing.”

To provide the feedback that Toby is looking for, download Longhorn and the Longhorn SDK from the MSDN Subscriber Downloads section and post your feedback on the WinFS newsgroup, where Toby posted his response and the WinFS team is hangs out waiting for you.

BillG’s keynote @ WinHEC this year was entitled “Seamless Computing: Hardware Advances for a New Generation of Software,” and is available in transcript form for your enjoyment.

In case you’ve heard the rumors about a new drop of Longhorn coming to WinHEC attendees, you’ve heard right. The Milestone 7.2 (M7.2) drop of Longhorn will be given to WinHEC attendees this week and will be available to MSDN Subscribers for download RSN*. The plan is to provide regular LH Milestone drops to the community as we have them, regardless of whether they really provide more functionality/stability or not. That way, we keep you guys in synch with what we’re doing and you can give us more relevant feedback.

In M7.2, the big deal is the addition of 3D support in Avalon, including declarative support in XAML. There are better things coming in 3D (as there are in the whole of Longhorn), but this is the initial set of functionality and we’d love to know what you think.

To set your expectations properly, WinHEC attendees and MSDN Subscribers will have access to the M7.2 OS and SDK bits, but will not have access to any matching Visual Studio bits. Neither the PDC Visual Studio installation nor the latest Visual Studio 2005 community drop nor even the upcoming Visual Studio 2005 beta will install or run properly on M7.2 Longhorn. We’re hoping for future LH Milestone drops to include the matching Visual Studio bits, but this one doesn’t. Luckily, MSBuild is included along with the compilers, so you can still build LH code under M7.2 like the pioneers did when they were blazing the Oregon Trail. It’ll put hair on your chest and build strong bones and teeth.

* RSN == Real Soon Now

The Windows Forms team has posted some sweet screenshots and overviews of the major new features in Windows Forms 2.0, including two I hadn’t heard about before:

• Client Configuration using type-safe per-user serialization of application settings
• Document Outline to show how controls are nested in a container

This is in additional to all of the other cool stuff, like a .NET WebBrowser wrapper, the new DataGridView, the strip controls, even more flexible layout, ClickOnce deployment (my personal favorite) and more.

[via Mike Weinhardt]

It has been hell keeping this to myself as Lutz has been sending me beta drops for the last coupla months for the completely reworked Reflector 4.0. Two very cool things about this release of Reflector:

1. It supports any version of the .NET Framework, so it works great on Longhorn and Whidbey
2. It has a replacement for the Class Viewer tools in the .NET SDK (wincv.exe) that I came to depend on in my writing and that hasn’t been updated for WinFX, so Reflector 4.0 is even more important to me than it would normally be

If you’re a .NET developer, you must use Reflector and if you use Reflector, you must use Reflector 4.0. Thanks, Lutz! We love you, man!

BTW, Lutz has set up a workspace for the Reflector 4.0 add-ins.

UPDATE: Denis Bauer has provided his own Reflector 4.0 Add-In to disassemble an entire assembly to a set of files. This is handy if, like me, you like to curl up with a good chuck of source code, put your feet up and enjoy a good cigar.

If you don’t know him, Miguel is the architect of the Mono open source project whose aim is to implement the .NET CLR and the Framework Class Libraries on Linux (and other places) so that .NET apps can run on OSes other than Windows.

In this essay, Miguel comments on the importance of Longhorn:

″…the combination of Microsoft deployment power, XAML, Avalon and .NET is killer. …

“The combination means that Longhorn apps get the web-like deployment benefits: develop centrally, deploy centrally, and safely access any content with your browser.

“The sandboxed execution in .NET means that you can visit any web site and run local rich applications as oppposed to web applications without fearing about your data security: spyware, trojans and what have you.

“Avalon means also that these new ‘Web’ applications can visually integrate with your OS, that can use native dialogs can use the functionality in the OS (like the local contact picker).

“And building fat-clients is arguably easier than building good looking, integrated, secure web applications (notice: applications, not static web pages).”

What I find most interesting is that while Miguel doesn’t cover the entire Longhorn story, e.g. he doesn’t mention WinFS at all, what he does mention, he summaries well. I’m glad to see the message of what’s going to make Longhorn cool is getting out. : )

ASP.NET 2.0 gets a ton of deserved press, but the combination of the doubling in functionality of Windows Forms in .NET 2.0 and the new and improved No-Touch Deployment, now called ClickOnce, make smart clients an enormously compelling alternative to web apps when you know that the client is running Windows and .NET.

Michael Weinhardt, who took over my Wonders of Windows Forms column and is the co-author on the 2nd edition of my Windows Forms book, has dedicated himself to shouting the value of Windows Forms 2.0 from the rooftops. Subscribed.

This week, Christophe Nasarre, one of the best reviewers on my Windows Forms book, has written a 3-article series on the new command line build system and the new build core of Visual Studio 2005: MSBuild. In this installment, Christophe starts from the ground floor, building the most basic .proj files and then exploring the advanced features you need to control your builds.

Also, because MSBuild is still under development, this piece covers the details of both the MSBuild in the Longhorn PDC bits as well as the most recent Visual Studio 2005 technology preview.

I work closely with Vic and Steve on the strategy for Longhorn content and activies, so I’m planning to tune it to today’s .NET Rocks.

Robert Scoble and I walked around MSDN last week with a camera and here’s the first snippet where I talk about my experiences building Solitaire for Longhorn. Watching it now, it seems to me that I need to chill a bit and maybe take a breath now and again. : )

Karsten continues his dig into the Fundamentals Pillar of Longhorn by describing the 3 main points of the new configuration settings infrastructure of Longhorn:

1. Configuration schema, which allows settings to be schematized based on XML
2. Configuration engine that has a suite of APIs for reading and writing configuration settings
3. Optimized configuration store that can be synched with legacy stores such as the registry, INI files, etc.

Karsten also points out a tool (wcmedit.exe) for browsing the configuration store and a sample (Longhorn SDK->Samples->WMI->WMI.Configuration Sample 1).

Personally, I’ve never been happy with the various configuration settings stories of any of the Windows OSes, so I’m happy to see this problem tackled again. And if this new way of handling application and user configuration settings doesn’t meet your needs, let us know!

I’ve been silent myself on the real status of WinFS simply because I didn’t know enough to really say (although I did ask some of my internal friends who knew more to speak out). One person I didn’t even think to ask was Jeremey Mazner, a Longhorn Technical Evangelist who spends quite a bit of time WinFS.

Jeremey’s bottom line: none of the cuts affect the message from the PDC or the slides or code samples that he uses to show off the benefits of WinFS. He goes on to provide supporting evidence from inside and to speculate on where the stories to the contrary came from in the press.

That doesn’t mean that WinFS or any of the other Longhorn features we showed off at the PDC won’t take cuts in the future as we drive for our ship date, but as of right now, Jeremey has detected any real cuts in WinFS.

Karsten J rebel’s against the lack of coverage of the Fundamentals pillar of Longhorn, sketching an overview of why the Fundamentals in Longhorn are cool and also delving into a specific feature he likes (the nextgen Longhorn Event Log).

Also, if you’re looking for more Fundamentals resources, check out the Fundamentals Pillar page on the Longhorn Developer Center, which lists the Fundamentals PDC Talks, several fundamentals articles (including a nice overview of ClickOnce for Longhorn) and the WinFX Fundamentals newsgroup.

Channel9 has some interesting quicky videos of Joe Beda covering a number of Avalon-related goodies:

• Managed vs. unmanaged, how much of Avalon was done that way?
• What 3D capabilities will Longhorn/Avalon provide?
• What hardware will Longhorn/Avalon need?
• How should developers prepare for Longhorn/Avalon?
• Managed vs. unmanaged, how much of Avalon was built in .NET?
• Are all of Avalon’s APIs available to .NET programmers?
• Is Avalon a way to take over the Web?

I got all this from the Channel9 Video RSS Feed. You should, too.

Carter’s got another concept video for us, this time for manufacturing.

In general, if you haven’t seen the concept videos, they’re a fantastic way to see what the heck we’re trying to enable with Longhorn.

Jason Olson, an enterprising 3rd party, posts a look at the benefits of knowing about threading when building an entire UI stack from scratch. Instead of requiring you to transition from a worker thread to the UI thread to talk to a control, Avalon lets you grab the UI context that owns the control and party on:

void ShowProgress(int secondsElapsed) {

     try {

          this.Context.Enter();

          txtSeconds.Text = secondsElapsed.ToString();

     }

     finally {

          this.Context.Exit();

     }

}

This is far simpler code than what would be required in code based on User32. Nice.

UPDATE: Ian Griffiths points out that the code can be even sweeter!

There seems to be a common misconception that since Avalon windows/pages are/can be declared in markup (XAML), it must be a web killer/reach solution. It’s not.

In this short video, Joe Beda, answers the question of whether Avalon is meant to replace HTML/the web (it’s not) and what’s Avalon’s message of “best of the web/best of Windows” message is really about, e.g. ease of deployment for Avalon apps like web apps, accessing central services for data and functionality (using web services instead of client UI generation), etc.

Kevin Lindsey has been exploring Avalon and posting some things he didn’t expect. I love how he posts pictures of what he expected alongside of what he actually got:

• Possible Avalon SpreadMethod Bug
• Possible Avalon LinearGradient Bug
• Avalon Missing Pen Functionality
• Possible Avalon Rectangle Stroke Bug

Keep it up, Kevin!

Apparently Robert had a conversation with a customer that was holding up .NET adoption because Longhorn was coming with Avalon. If you’re already planning on building Longhorn-only applications, more power to you, but most folks will need to write apps that run on other versions of Windows for some time to come. For those folks, we have .NET and Windows Forms today and for at least another decade. Let’s do the math:

• According to recent industry rumor, Longhorn won’t ship ’til 2006.
• According to our internal OS folks, a new OS isn’t ubiquitous enough to target it as a base for new consumer application work for 6 years.
• Even 2 years after .NET was available everywhere, people are still actively doing the MFC and VB6 thing.
• 2 years ’til 2006 + 6 years ’til ubiquity + 2 years not doing the new thing = 10 years of good, strong life left in Windows Forms at least.

In spite of my love on Avalon, I’m so confidendent that Windows Forms has a life left that I’m working with Mike on Windows Forms Programming 2/e. A book is hard enough that you don’t do it if the topic is dead, so that’s me putting my time (and Addison-Wesley’s money) where my mouth is.

Robert Hess, that .NET Show guy, talks about why he’s so into Longhorn in the recent .NET Shows lately:

“What you -do- need to pay attention to, is how ‘Longhorn’ will evolve the users concept of exactly what a Windows application is all about, and what features and functionality it should be providing them with. Many application developers should be starting to think about this TODAY, and how to begin incorporating some of these features into their application moving forward. Just the schematized file system that WinFS will introduce alone can represent not only a big jump in the potential functionality of an application, but also a considerable change in how your existing application might want to begin thinking about data storage.”

Marc Clifton, a concerned 3rd party, provides thoughtful criticism of XAML.

Chris Anderson, Avalon Architect, takes Marc’s criticism and provides a thoughtful response.

Because of where we are in the Longhorn release cycle, i.e. a long way from a release, if the Avalon team agrees with Marc, they can make real changes.

As a result, Longhorn gets better because it’s able to accept early, critical feedback. Perfect.

Today, Joe Marini, a Microsoft PM on a project that dare not speak it’s name, posts a blog reader built entirely in XAML, i.e. no .NET code.

Last week, Chris Anderson, an Architect on the Avalon team, showed us that Avalon requires no XAML at all if you don’t want to use it.

However, closer to the truth are Don and ChrisAn, Longhorn architects, on using a mixture of XAML for declarative UI tasks and code for handling events.

My own preferred model is to do just as much as I can in XAML, because I find declarative style coding more flexible, but to put into code what makes sense, e.g. most event handling. My line in the sand is this: if I would have to embed code in the XAML, I go to real code, otherwise, I use XAML.

Marc Clifton, author of the MyXaml open source project, publishes a series of articles exploring opportunities for improvement for the Avalon architects to consider:

• Is Microsoft Bollixing Up XAML?–a look at “tag names are class names”
• Is Microsoft Bollixing Up XAML? — The joys of VisualTree
• Is Microsoft Bollixing Up XAML? — The case of the missing collection
• Is Microsoft Bollixing Up XAML? — Decorating the house of cards

I only wish that he would post his thoughts of how XAML should look.

The most concise description of what I love most about Monad, the next-gen Windows command line, comes from Jeffrey Snover, a Microsoft Architect, in a Peter Coffee article:

“We keep the idea of ‘A pipe to B pipe to C,’ but we pass .NET objects instead of structured text. We can pass ADO, other kinds of objects, and we can create reflection-based utilities.”

Just the idea of not having to deal with ambiguous from standard input or reparse the data at every stage of the shell pipeline makes me giddy with anticipation.

Josh Williams, an SDE on the CLR team, kicks off his 64-bit blog with an introduction to WOW64 and what it means for .NET programmers. Here’s the summary:

• WOW64 isn’t the OS per se, but a subset of the Win64 OS which enables a 32bit application to run inside of a 32bit process on a 64bit OS while using 32bit system dlls and such.
• Whidbey CLR will include both 32bit and 64bit versions, both of which will be installed on 64bit machines. This allows both 32bit and 64bit managed applications to run in bitness correct native process depending on how the assemblies are tagged at compile time.
• Once a process is started up as either 32bit or 64bit all of the dlls/assemblies that are loaded into that process have to be compatible with that bitness.
• If you have a 32bit managed app which has dependencies on 32bit unmanaged code then you’ll need to either find a 64bit version of the unmanaged code or tag your managed app as x86 at compile time to make sure that you don’t float up to a native 64bit process. This will result in you having to live with your process running under the WOW64.

Paul Thurrott finishes his 2-part series of interviews of Hillel Cooperman and Tjeerd Hoek, Longhorn User Experience mavens. The interview covers just how hard it is to make an entire OS usable and just how much work MS does to get it right.

However, one thing that Hillel said struck me particularly as someone fairly new to working at MS:

“Actually, that was the shocking thing about coming here: The problems weren’t simple. The number of people that I met who were humble, that cared deeply and passionately about making the user experience better for customers and weren’t just saying, ‘Hey, here’s a new API’–not that I don’t love a new API–was surprising. These people were really deeply concerned about how they could make customers’ lives better and had thought a lot about this, way more than I had. I was blown away. I just couldn’t believe it.”

That’s exactly how I felt coming to MS. We have a PR problem, but we definately do not have a care-about-the-customer problem.

Paul Thurrott is more of a user guy then a developer guy, but you have to be a user before you can be a developer, and his stuff is often interesting. Now he’s created a spot on his site to gather his Longhorn content. My only question: where’s the dang RSS feed?!?

If you read Ian’s article on Avalon Graphics Composition before the fireworks, you missed a wonderful discussion of how Avalon compares with Apple’s Quartz and Quartz Extreme. Not only does Ian respond to the ever popular “Doesn’t Mac OS X already do today what Longhorn will do tomorrow?” with a resounding “No!” but he does it in such a thorough manner, that you can’t help be admire it.

You go, Ian! : )

Mobiform is one of two 3rd party vendors that have been building a XAML parser that runs under the current version of .NET. Today, Mobiform went one better by releasing a working preview of an interactive XAML Editor that runs under the current version of .NET. Plus, the XAML that I created in the editor works on the PDC Longhorn bits.

Now there’s something other than the 101-Key Text Wizard to use when designing XAML for Longhorn. Mind you, what Mobiform has put together isn’t Illustrator or even Paint Brush yet, but it’s an amazing start.

Normally I like to consume something before I recommend it, but his stuff is always so good that I’m going to point out Ian’s new piece on graphical composition in Avalon before I’ve even read it. Here’s the conclusion to whet your appetite:

“The new composition model in Avalon removes many of the visual design constraints that applied to most Win32 applications. It also improves performance by making more effective use of modern graphics cards, reducing the frequency with which the OS has to call the application back to keep the display up to date, and enabling a much higher quality of user interface.”

Enjoy.

Love markup but can’t wait for Longhorn/Avalon/XAML? Check out Joe Stegman’s WFML (Windows Forms Markup Language).

[via Chris Anderson]

Rich Turner, PM on the Indigo team, answers lots of FAQs related to Indigo and how to prepare for it today, including:

• How do I prepare my code and systems to ease my adoption of Indigo?
• Which current technologies should I use, where and when?
• How will Indigo interoperate with systems based on existing platform and technologies?
• How much of my code will I have to change to migrate my code to Indigo?
• How will Services Perform & Scale?

Thanks for pointing me at Rich, folks. I’m enjoying his Indigo blog a great deal!

Looks like CodeProject is getting into the Longhorn act with a nice Hello, Longhorn sample by Deepak Kapoor.

Before watching this episode of The .NET Show, I used to think that Don’s speaking ability made the Indigo team somehow special, but after watching this episode on Indigo and seeing John Shewchuk and Steve Swartz wax elopquent about the high level interop and functionality goals of Indigo as well as the programming model goals, I think Don is just the guy that’s willing to be publicly naked (not that I can really point that finger : ).

John and Steve provide *such* a compelling story. If you haven’t heard the Indigo story or even if you have, this is the place to get it.

Following up on Steve’s places to go for more:

• Indigo newsgroup
• Joe Long’s prescriptive guidelines on preparing for Indigo
• Indigo site on the Longhorn Developer Center

BTW, does anyone have some recommendations for Indigo bloggers? I subscribe to Don, Yasser and Aaron, but don’t see much Indigo traffic on those sites.

David doesn’t get many questions to answer about the present and future of .NET, but the ones he gets asked, he answers well. My favorite:

“As for code identity, I love the vision. But I’ll acknowledge that it hasn’t taken off as we’d hoped. When people tried to write partial-trust apps, it always turned out there was one thing they needed to do and couldn’t. We have to do more work to find the right scenarios where you can do a functional smart-client app that runs in partial trust and doesn’t require the user to micromanage permissions. In WinFX, I want to make it viable to write partial-trust apps that can do real things.”

The emphasis is mine.

[via Don Box]

I’m always nervous about going to see the teacher about my kids’ performance this year. They’re both very bring, but the older one is easily bored (like his father) and the younger one is social and emotional charged (like his mother). Also, I’m of the belief that at this age (9 and 8), the parents still have an enormous influence over their children, which includes how well they do in school. All of that is wrapped up into that 20-minute meeting at those tiny little desks and it’s nerve-wracking.

On the other hand, I find myself pleasantly surprised by Jon Udell’s .NET Report Card. To be sure, there is room for improvement (Don always says, “The largest room in the world is the room for improvement” : ), but two As and two Bs is pretty damn good in this age of very high expections, so I’m a proud 2nd cousin right now (the product teams are the real parents, of course).

Ryan Dawson posts a nice sample showing the basics of a drawing program in Avalon, including a floating toolbar and the ability to draw and select lines, rectangles and circles. He also provides the source.

BTW, Ryan’s pretty darn prolific on Longhorn and I recommend his blog in general. Also, if I remember correctly, he’s 19, so you’re getting pure enthusiasm and uncensored truth. Recommended.

Since it’s inception, I’ve been a big fan of the .NET Show and I’ve seen most of the episodes. Now, the host, Robert Hess, has got himself a .NET Show-related blog. Subscribed.

Right on, Benjamin:

“The selling point of the Indigo Service model is that it is simple and easy to use.  The benefits for developers is that they get all the benefits of enterprise-quality features such as transactions, reliable messaging and security without having to write any code.  Letting Microsoft do the plumbing allows developers more time to write code that focuses on solving complex and interesting business problems.”

It’s been about 5 months since the Longhorn Developer Center was launched and I’m curious what you guys think of it. Do you like it? What about it don’t you like? How could it support your current Longhorn development goals better? What can I do for the budding Longhorn developers that we’re not doing? Don’t be shy; call it like you see it.

The one and only time that I ever met Tim O’Reilly, I turned into fan-boy, telling him how I used to be a Unix guy and I would just buy every single “animal book,” even if I didn’t know what the topic was because the quality of the books was so high that I knew I needed to know whatever was between the covers.

Now a days, ORA produces too many quality books to purchase (or even read) them all, but I’ve been very happy to see them turn more and more of their attention towards Windows, where I’ve put all of my developer energies for more than a decade. In fact, I’ve written one book for ORA myself and I’ve got two more in the works, so I continue to be a big fan. Today they launched the Windows DevCenter, where they are concentrating and aggregating all of their considerable Windows juice. And, of course, they have an RSS feed. Subscribed!

Jeremy Mazner presents his second scenario for WinFS, this time describing his idea app for event management that would be cake to implement using WinFS. In fact, I’m pretty sure you could do the whole thing in the shell.

On a related note, I was watching an internal training video on WinFS yesterday and it excited me in a way that’s not appropriate for humans to feel about technology. The enumeration, update, serialization, relationship, extensibility and notification models just all seem so *right*. I’m looking forward to another drop of the bits that enables me to extend WinFS so I can really start building stuff.

If you care about Longhorn, start first with Whidbey. According to Scott Guthrie, the first Whidbey beta will be available in June.

[via Kent Sharkey]

Jason Nadal builds a useful smart client application in Longhorn for language translation. It’s a simple front-end to a web service, but it’s the first real custom app for Longhorn I’ve seen that doesn’t have to do with demonstrating or building for the platform.

Nathan Dunlap and Jonathan Russ work together as designer and coder to build splitting bars in Avalon:

“Boy was I happy when he got back to me with a really simple solution that I have found is really easy to reuse in a lot of scenarios. I love experiences that really show me that the designer/developer split is going to be really graceful. It’s pretty cool when the design can start with me mocking up something and handing it off to the developer who can then build logic into it. It’s even better when the developer logic isn’t so intertwined with my styles and layout that I can hardly touch it without breaking something. This way I get to use my design skills at the prototype stages and early skeletal stages, and I also get to get my hands dirty in the real code at the fit and finish stages. All you designers who have spent hours refining your designs only to have your designs mangled when they get implemented in real code… your day is coming.”

BTW, if it seems like a list a lot of community Avalon pieces on my site, it’s because there’s a lot of community activity in Avalon. If you’re doing WinFS or Indigo work and I’m not seeing it, please let me know!

Ironically, his page is filled with bugs…

[via Stuart Celarier, the real Longhorn Stuart]

Ian Griffiths posts the beginnings of a XAML editor (it supports squares and elipses and saving, but not loading XAML, so no source yet). Especially interesting, however, is how he handles zooming. He wrote an explanation with source on that bit.

BTW, if you haven’t figured it out yet, Ian is quite the Avalon boy. If you’re into such things, you should subscribe to his blog.

While Rory’s virtual pet sidebar tile sample isn’t especially useful for a corporate desktop (although maybe a “virtual employee” version could be used to screen potential managers before they’re inflicted on unsuspecting “real” employees… : ), it does show off the intended usage for the sidebar: stuff that you absolutely, positively have to look at all day long.

As an example of what I mean, consider a typical example: the weather tile. Do you really need to know what the weather is all day long? Do you need to know it enough to take up valuable screen real estate to show it to you? I know I don’t.

But, do you need to see a virtual pet all day long? You do if it’s important enough to want to run it and keep it happy. Do you want to remember to flip to it all day long as an app running in the background? Nope. And that’s why it’s a perfect tile sample. If you run it at all, it’s important enough to take up screen real estate all day long.

You can read about these and other interesting sidebar guidelines in the sidebar section of the Longhorn User Experience guide (still under construction, of course). If you’ve got any feedback, the UX team would *love* to hear it.

Not only does Kenny show a cool little XAML animation sample, he does it in my favorite writing style.

I’ve always loved writers that start with something I’m familiar, in this case, a star defined in a hunk of XAML, and then build it up to add new features, in this case color, opacity, scale and rotation animations. The reason I love this style is that if I’m at a computer, I can follow along, folding the new features into my code and learning how things work by doing it. Or, if I’m reading the piece in the bathtub (which happens surprisingly often), I can build the code in my head (at least, ’til I get one of those cool waterproof military laptops).

Kenny’s piece almost does that, but the initial showing of the is shown without context, so it’s hard to know where it goes in the growing piece of XAML I was working on. Still, he follows it up a few sentences later with the entire XAML sample, so I can see the context. If he’d have been a little more explicit about the details of the animations he was applying and had wrapped it up with a summary, it would’ve been nearly perfect.

Oh, and animations in Avalon are cool, too. : )

“A journey of a thousand miles starts with a single step.”
Unknown (to me : )

In this installment of the Longhorn Foghorn, I start my Longhorn implementation of the venerable Windows Solitaire. There is no interesting code yet, but I have explored some of the same decisions any developer will face when starting their first Longhorn application from scratch. Enjoy.

Ian and I are writing an Avalon book for O’Reilly and Associates together, but he’s way out in front of me, writing cool stuff like how to get rubber band selection outlines in Avalon. He also starts with a wonderful history of the XOR technique we used to use in Windows and why we no longer need it. In fact, we don’t even need XOR in Windows Forms and GDI+ today, although lots of folks don’t know that.

The key trick in Ian’s implementation is putting a hidden element into your XAML document so that when it’s time to do the rubber hand outline, you can show it, move it and resize it based on where the mouse is, hiding the Rectangle again when the mouse button is released. This lets Avalon take care of the drawing, making this technique a thing of beauty.

As I’ve mentioned, the reason we’re put the Longhorn preview bits out so early is so that we can get feedback at a time when things can still change. So, when you see Brad Abrams, Chris Anderson or any of the other dozens of MS PMs and Architects hanging out on the web ask for feedback on what they can do to make things better, take them up on it! Don’t be shy. If you hate something, tell us so we can change it! If you love something, tell us so we don’t change it!

Even if there isn’t any specific blog entry to which you can reply, start or your or post something to the WinFX newsgroups. We’ve got members of the Longhorn team looking everywhere for your feedback. For example, yesterday Dino posted a theory he had about developer reaction to some particular aspect of the new Longhorn programming model. Rob Relyea saw that post and today he’s soliciting more feedback on XAML compound property syntax and XAML as a whole, the latter specifically becase of Dino’s post.

If you care enough about Longhorn to be running it at this stage, you really should take these guys up on their offers and use the newsgroups. And if you’re afraid that you’re not getting your feedback seen, drop me a line. I can’t guanartee that your feedback will be incorporated, but I can make sure the right folks see it.

Dino’s gotten some interesting feedback from his XAML-based articles. Apparently he’s hearing from “real programmers” that don’t want to “recycle themselves as web designers.” This feeling Dino has dubbed “un-programming” and it’s the idea that XAML takes away the need to code.

XAML is most of what’s needed to build trade-show apps, that’s true. But look at your apps today: How much of your web app is HTML and how much is C# or VB.NET? How much of your Windows Forms app is in the InitializeComponent method and how much is code? While XAML can also be used for general-purpose object creation and initialization, as far as the UI of your app is concerned, all XAML does is replace the HTML or InitializeComponent method. The power of what Avalon can do is separate the UI from the code so that trained designers can work on the specifics of the UI, while real developers work on the specifics of handling events and hooking up the business logic and talking to the back-end datastore.

I know that as a Microsoft flunky, the value of my reasoning is now suspect. So don’t listen to me. Listen to Dino:

“XAML is the hot new toy for app developers, and articles inevitably emphasizes that. However, there’s life beyond XAML. And by life here I mean code, managed code, classes, methods, delegates, events and the like. XAML is a shortcut much like ASPX tags in ASP.NET. Believe me, you wouldn’t do much with XAML alone and without smart C# or VB.NET code.

“XAML (and the Longhorn programming style) is not the negation (and let alone the death) of programming.”

Last time, Ryan Dawson posted a fun Avalon sample showing system information using graphics and animation. Today he’s back exploring the use of WinFS to build a tiny CRM app.

Karsten Jkdjflksjdf (or however you spell his last name : ) pointed out two excellent security articles today. The first is “Developing Software in Visual Studio .NET with Non-Administrative Privileges.” Longhorn applications are going to run much better assuming fewer privileges, so getting yourself out of the habit of testing and running your own code as an Administrator is something you can do today to prepare for Longhorn tomorrow.

Another excellent article on this topic is from Keith Brown, a DevelopMentor colleague and security arch-Nemesis of mine (he never did like my plan of branding “bad” applications by setting the first bit to 1 instead of 0… : ). Item #7 in Keith’s online book in progress, A .NET Developer’s Guide to Windows Security, is entitled “How to develop code as a non-admin” and well worth the read for the practical advise as well as Keith’s pleasant writing style.

Oliver Drobnik extracted a question out of a Q&A session with BillG asking about speech recognition in Longhorn. After BillG makes a very funny comment, he talks about the current state of speech recognition and synthesis today and a bit about the plan for Longhorn.

And Oliver? I’d rather not know what you’re planning on commanding your computer to do… : )

Rob Relyea, a Lead PM on the Avalon team, posts some history of XAML as well as a description of how it’s compiled into BAML and then into code. He also talks about CAML, which is used today in the PDC bits, but going away in the future.

I love these kinds of posts (and these kinds of articles) because they provide insight into what the designers of a particular technology had in mind, making it so much easier to learn. Having spent years of my life reverse-engineering the intentions of the COM designers out of the header files (because the docs and marketing materials actually pointed us in the wrong direction), it’s great when the folks behind the technology spill their guts. Thanks Chris and Jeff and Rob (and Mike and Don and the rest of the MS bloggers).

The shell-meister himself, Dino Esposito, digs into the one of the most prominent of the new shell features in Longhorn — the Sidebar — by showing you how to add your own tile, including how to create the flyout and properties views and how to extend the context menu. Sample code included. Enjoy.

Wes muses on whether XAML could become a “standard” document format for even custom types. Certainly, if a document was serialized in XAML using custom types instead of in a custom format, it would save some translation to/from the Avalon object model…

If you’ve noticed Stuart Celarier stalking the WinFX newsgroups lately, it’s because he’s been gathering the best stuff for use in his new Longhorn Developer FAQ.

Plus, Stuart’s got all kinds of cool FAQ features, like expanding/contracting items and URLs for each category and for each item. Even cooler, the source document is a WordML document that Stuart authors in Word and then translates into HTML for the MSDN site using an XSLT. It’s a very cool model for FAQs in general and I know that Stuart’s planning to share the FAQ framework on his site.

And, if you’ve got an feedback on the FAQ items or would like to see new ones (or would like to hire him — he’s amazing with all things XML), feel free to send him an email.

“Carl interviews developer and author Brian Noyes. Brian has focused his studies and development efforts on Smart Client development, and in this interview brings us from AutoDeployment of Windows Forms applications into ClickOnce, the next-generation deployment and update technology from Microsoft that will ship with the .NET Framework 2.0. We talk about the issues around AutoDeployment, and how Microsoft is addressing those issues with ClickOnce.”

ClickOnce debuts in Whidbey and will be a big part of the deployment story in Longhorn.

“This interview is the first in a series highlighting the personalities behind the technology. It’s often all too easy to depersonalize a company as large as Microsoft, but there are real people behind these products, and they care very deeply that the products they create are as aesthetically beautiful, functional, secure, and reliable as they can be.”

I agree, Paul. Thanks.

Brent Rector’s PDC book on Longhorn/WinFX is now available for purchase. We’re posting the chapters on the Longhorn DevCenter, but atoms are nice, too, especially when they come in the shape of a book.

[from Adam Kinney’s blog]

I was data binding an ArrayList of objects of a custom type, e.g. class Person { public string Name; public DateTime BirthDate; public int Teeth; }, to a DataGrid today and everything working great ’til I wanted to filter one of the columns out (who cares how many Teeth a person has?). I was all set with table styles and grid styles like so:

void Form1_Load(object sender, EventArgs e) {
  DataGridTableStyle tableStyle = new DataGridTableStyle();
  tableStyle.DataGrid = this.dataGrid1;
  tableStyle.MappingName = "Something???";
  this.dataGrid1.TableStyles.Add(tableStyle);

  string[] columns = { "Name", "BirthDate" }; // Skip Teeth
  foreach( string column in columns ) {
    DataGridTextBoxColumn columnStyle = new DataGridTextBoxColumn();
    columnStyle.HeaderText = column;
    columnStyle.MappingName = column;
    tableStyle.GridColumnStyles.Add(columnStyle);
  }

  // Create ArrayList of Person objects...

  this.dataGrid1.DataSource = personList;
}

The problem was the table style’s MappingName. When DataBinding to a DataTable, it’s just the table name, but what is it when I’ve got a collection of objects of a custom type? Daniel Herling, a Software Design Engineer at Microsoft and the “man” of the DataGrid, came to my rescue:

If you bind to an ITypedList (say, System.Data.DataTable) then the mapping name should be ITypedList::GetListName(). For a System.Data.DataTable this would be the name of the data table.

If you don’t bind to an IList that is not ITypedList then the mapping name should be list.GetType().Name where list is the list the data grid is bound to.

So, all I had to do was set the table style mapping name to the type of my custom class:

  tableStyle.MappingName = typeof(ArrayList).Name;

This wasn’t bad at all to bind a DataGrid to exactly the properties of my Person objects that I want w/o having to hack another custom shim type or changing the Person type itself to accommodate the data binding. Thanks, Daniel!

Folks have been posting Longhorn code samples on their blogs, which is great. Also, I’ve been collecting bigger code samples on the Longhorn Developer Center on the Tools & Code Samples section as well as with the PDC talks.

Also, I just noticed a Longhorn sample in the unedited section of CodeProject.com, one of my favorite user contribution sites.

Of course, you can post your sample on GotDotNet.com using the Longhorn category and there are already a coupla GDN Longhorn samples for your edification.

In talking about recent developments at Microsoft, Mary Jo sums up my own feelings nicely:

“Windows is cool again, thanks to all the excitement around Longhorn.”

But I’m hardly unbiased. : )

In this chapter, Brent Rector provides his overview of WinFS, including the programming model and how to access items from the WinFS API and via SQL directly (the latter sounds a lot more fun that it is : ).

Joe has a particularly dim view of where we’ve come with GUIs in the last 10 years. In fact, it’s much more dim than my own view. On the other hand, I think he nails one point:

“There is a core set of patterns that are repeated over and over in thousands of applications, each of which has their own subtly different behavior and visuals. Back and forward, undo and redo, delete, find, bookmark, etc… And there are a core set of graphical objects like images, text, maps, and calendars, which everybody has to reinvent every time they need one in their application, and they usually do a lousy job of reinventing it. Sure, there are classes for some of these things in GUI libraries, but the user doesn’t see that - they see the programmer’s personal interpretation of how they think it should look and work.”

As a app builder in my heart, I absolutely want the tools to build *good* applications, not just *pretty* applications.

 : )

As I’ve mentioned, one of the biggest problems I see with Longhorn is deciding exactly what to do with all of the new capabilities. So, when Carter Maslan showed me some internal training videos showing off some uses of Longhorn in potential real-world applications, I just knew we had to get them out to the world.

The first such “concept video” is centered around commercial real estate (available at 320x240 and 640x480) and Carter’s got more planned in other industries, including manufacturing, telecom, financial services and more. The goal is to help break the mental logjam around how we build Windows and web applications today to get folks thinking about the possibilities that Longhorn provides. Enjoy.

For those of you unfamiliar with Don’s reference, a “roach motel” lets roaches in, but never lets them out. That’s exactly what most apps do today, i.e. take data in from users or import routines, but never let it out again. As Don states, one of the chief benefits of WinFS is that data that apps store in it will be available to other apps, thereby letting the roaches out of the hotel. Where Don’s analogy breaks down is that in the case of application data, letting the roaches back out of the hotel is actually a good thing. : )

We’re not even to beta yet, but we already have not one, but two 3rd party XAML viewers targeting existing versions of the .NET Framework. Wow.

[From Don “XML” (donxml.com)]

In a recent interview of Don Box by Mary Jo Foley, I expressed my disappointment over the dullest of both the questions and the answers. Uncharacteristically ducking criticism, Don provided details of my frequent stays at his house suggesting an unhealthy love of his pets (which I love the normal amount, I promise). While this was amusing, it doesn’t give anyone any more information than Mary Jo’s interview did.

Anyway, talking about it on the phone just now, Don agreed with me that the interview turned out much less interesting than he intended and promised to make amends. Specifically, he said, “Chris, send me 10 questions and I’ll answer them.” So, here’s your chance. Reply to this post with the hardest hitting, most revealing questions and I’ll pick the best 10 to send along to Don. Don’t hold back — all questions are fair, although I’ll focus first on Indigo, then Longhorn, then technology in general before getting to Don’s own love of his pets (for example). Here’re some questions to seed your thinking:

-How does the version of Indigo shipping with Longhorn relate to what’s currently being used internally at MS? How does it relate to what you actually plan on shipping?

-What should an ASP.NET or WSE programmer *really* do today to prepare for Indigo?

-What’s the biggest surprise about the inner workings at MS?

-If you could do one thing to change MS, what would it be?

-If you could do one thing to change the IT industry, what would it be?

-How can ISVs be successful in the current IT industry?

-What’s the next big thing that’ll change the IT industry?

-What do you think is cool that doesn’t get enough attention?

-Has family scrutiny caused you to stop dressing your pugs in clown suits before expressing your love for them?

I’m in Minnesota over the holidays, so I thought I’d drop in on the Twin Cities .NET User Group for a short discussion of Longhorn. Please keep in mind that this talk is purely shelfish on my part — I learn best by telling the story.

Mary Jo Foley interviews Don Box on the origins of Indigo, the status of SOAP, the definition of SOA and Miguel de Icaza. Unfortunately, Mary Jo doesn’t dig for any dirt and Don doesn’t volunteer any, so it’s a relatively boring interview. Luckily, it’s short.

Apparently it’s Longhorn day for MS videos:

“Quentin Clark provides an overview of WinFS, including what benefits it produces, what it is, and how it’s put together. This episode introduces WinFS as a basis for more detailed presentations.”

And than Nathan posts another sample showing off the various kinds of resources to be defined in Avalon and how to define them on top of one another. I’m loving this guy!

BTW, this is post 1000 on this feed. I can’t keep  up with Scoble, of course, but I had no idea I was *that* wordy. : )

If you haven’t seen it, Xamlon is a .NET 1.1 implementation of Longhorn’s XAML. And while I was under the impression that it was just XAML, i.e. a language for declaring and defining objects, it looks like Xamlon is an attempt to implement Avalon, too. I haven’t downloaded it, but looking at the Xamlon samples and code online, it looks like a subset of Avalon. Interesting…

Adam Kinney seems to be that rare combination of graphic designer and coder that I want to be to survive in the brave new world of Longhorn. I’m following his blog avidly.

Drew Marsh describes the internals of the XAML dotted attribute syntax that I described a few days ago as well as contrasting it with the existing .NET IExtenderProperty model.

Drew’s documenting what he discovers as he digs into Avalon.

Don Box simplified my XAML code using resources and styles. He also illustrates another XAML-ism that I’m coming to love: dotted element names. When you see something a dotted element name in XAML:

<GridPanel>
  <GridPanel.Resources>...</GridPanel.Resources>
  ...
</GridPanel>

what you’re looking at is a more convenient way of specifying an XML attribute using XML element syntax. For example, while you can specify a menu item like s

<MenuItem Header="New" />

However, if you’re doing anything fancy, like specifying an access key, you can do this using the dotted element name syntax:

<MenuItem>
  <MenuItem.Header>
    <FlowPanel>
      <AccessKey Key="N" />
      <SimpleText>ew</SimpleText>
    </FlowPanel>
  </MenuItem.Header>
</MenuItem>

In the first case, we’re just specifying a string, so declaring the Header attribute inline makes sense. In the second case, we’re composing the Header for the MenuItem as a FlowPanel, combining an AccessKey and a SimpleText element. Underneath the covers, XAML attributes translate into properties, so for those properties more complicated than strings, the dotted element name syntax allows properties to be specified as sub-elements.