Rob Relyea - XAMLified

Just stepped a developer on my team through the basics of a .csproj file, the targets it imports (Microsoft.CSharp.targets), and how targets and tasks work in msbuild.

He is debugging why a Blend 3 project has a strange warning when upgrading a SketchFlow WPF project to VS 2010.

My team works on both the Silverlight and WPF MarkupCompilers (we generate .baml and .g.cs files for WPF and .g.cs files for Silverlight).  Lots of things we want to do for both of those MarkupCompilers when we get a chance.  The WPF one is built on top of the WPF v3 Parser.  The Silverlight one is build on an earlier version of System.Xaml.dll’s code base.  We want to move both on top of System.Xaml.dll and provide a number of benefits to you all.

We’re also exploring having more pluggability in the build pipeline…the Blend team would like to transform some XAML files during build, but before markup compilation.

Fun stuff!

Windows 7 has a preview handler in the Explorer that provides a nice preview for many file types. I noticed the other day that .cs files show up in the preview window.  Also, .xaml files didn’t.

I just dug through the registry to figure out how to enable .xaml files to use the same text previewer as .txt and .cs files.

Setting the PerceivedType of the .xaml file format via this .reg file (or by hand in the registry) to “text” will enable this text preview window for you.

Update (12/14/2009): it may also be useful to have this set for .csproj/etc... Modified the .reg file below...

xamlPerceivedType.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.xaml]
"PerceivedType"="text"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.csproj]
"PerceivedType"="text"

Visual

1. select the XAML file to preview
2. the preview pane shows the text for that file
3. this button will show/hide the preview pane
4. this enables shell actions such as “open” and “open with”

[this may work in older versions of windows as well…at home, i don’t have a Vista or XP machine to try it on]

Both Office and XPS uses OPC (Open Packaging Conventions) to have a XML inside of .ZIP file format.  I’ve been very excited about OPC for a number of uses since we first shipped support in .NET 3 with System.IO.Packaging apis.

The Windows team continues to innovate in this area in Windows 7 and beyond and now they are blogging about the work they are doing: http://blogs.msdn.com/opc/archive/2009/05/18/adventures-in-packaging-episode-1.aspx

Haven’t done this ride this year, but last summer I did it three times.  Left from Microsoft Campus or Marymoor park and went to the Mukilteo Ferry to get to Whidbey island.  A friend wanted directions…

The Ribbon Control is important for many apps.  As such, Microsoft is trying to make sure that whether you are building a WPF application or a native Windows application (win32) or a MFC based application, that you have strong Ribbon services.

• WPF Ribbon Preview info is available on Codeplex.  This PDC Talk (PC45) covered the WPF Ribbon control at PDC 2008.

Before you start your Ribbon development, please check out the Ribbon V1 Roadmap page to learn about the major features and design changes that are planned for V1 of the Ribbon control.

• Windows 7 also provides a native implementation of a Ribbon with the Windows Ribbon Framework.  Interestingly, even though this doesn’t require .NET or Silverlight (as it is native), it uses XAML (from MSDN’s Introducing Windows Ribbon Framework):

The Ribbon framework provides this flexibility by separating functionality from presentation with two distinct development structures: an Extensible Application Markup Language (XAML)-based markup language to declare controls and the visual layout of a Ribbon implementation, and C++ COM-based interfaces to define low-level functionality and host application hooks. This distinction enables UI developers and designers to be solely responsible for the appearance of a Ribbon application, while core functionality remains the domain of software engineers.

[Link to the PDC 2008 talk about Windows 7 Ribbon.]

[Looks like we are backporting the Windows 7 framework to Vista/Server 2008: http://www.istartedsomething.com/20090818/scenic-ribbon-ui-framework-backported-windows-7-client-platform-update/]

• MFC Ribbon is also coming. http://blogs.msdn.com/vcblog/archive/2007/11/09/quick-tour-of-new-mfc-functionality.aspx

Had a thread with some VS folks… now working on a little prototype for a new CheckUid/UpdateUid to be a bit smarter.  Last bit to get working is the actual updating…

I think the logic should be reversed: which elements DO need Uids for localization?

There are probably too many to exclude, but here is a list for start:

• ResourceDictionary,
• Triggers, DataTrigger, MultiTrigger, MultiDataTrigger
• Setters, Conditions,
• ControlTemplate, Style,
• ContentPresenter, ItemPresenter
• RowDefinition, ColumnDefinition
• Rectangle, DrawingBrush, Border, Path, *Geometry , *Transform,

Stop adding UIDs to these and you’ve probably eliminated 90% of the noise for us…

Thanks,

VS Guy

From: Rob Relyea
Sent: Thursday, August 06, 2009 11:59 AM
Subject: RE: Uid clashes - improvements to UpdateUid

No new news on this front since my April 2008 email from your attached thread.

From: Rob Relyea
Sent: Saturday, April 19, 2008 7:54 AM
Subject: RE: Xaml & localization

We will make CheckUid and UpdateUid smarter over time if you think there is a large benefit we can achieve.  Today, they are written on top of System.Xml, so it is difficult for them to add smarts.  We will likely enhance them to work on System.Xaml.dll in the .NET4 or later timeframe and will be able to more easily optimize them to only add UIDs on some types, etc…

Please give feedback to us on ways you would like to see the Uid addition logic changed…

Thx, Rob

We don’t have short term plans to improve UpdateUid, however, given that we have System.Xaml.dll, it wouldn’t be hard to do…it may even make a good sample.

VS folks-

What elements should we stop writing Uids on, ideally?

Thx, Rob

From: VS Guy
Sent: Thursday, August 06, 2009 11:50 AM
Subject: RE: Uid clashes

We had this discussion ages ago, and we were told pretty much to go with the bloat, same way Cider and Expression did

As for stopping using UpdateUid, as soon as I enabled it, the next day there was a checkin that added a localizable field and forgot the Uid. We caught it because it caused a build break, so the checks are not useless. The question is whether the added value is greater than the pain of running the tool…

It looks like we should send some feedback to them to get this Uid addition logic changed…

Rob, are you aware of any upcoming changes that improve how UpdateUid adds uids to elements?

Thanks,

VS Guy

From: VS Guy 2
Sent: Wednesday, August 05, 2009 9:45 PM
Subject: RE: Uid clashes

(Plus it bloats the size of the resulting XAML and adds to BAML parsing time.)

From: VS Guy 3
Sent: Wednesday, August 05, 2009 9:15 PM
Subject: RE: Uid clashes

I have said this from the beginning, but VS Guy says the loc people claim we have to do it.  I think the tool is stupid and puts UID’s everywhere making the XAML MUCH harder to read (who needs to do that anyway…ohh yeah, us) and obscures what needs to be localized from what doesn’t.  We definitely should figure out if there is any alternative here.

VS Guy 3

From: VS Guy 4
Sent: Wednesday, August 05, 2009 7:37 PM
Subject: RE: Uid clashes

Or we could stop using UpdateUid to litter the code with x:Uid’s.  I really think this is overkill since so little of the XAML has text that needs to be localized. 

The Start Page styles and loose xaml files are excluded from the CheckUid build step and we take care to periodically review the code for localizable strings.

From: VS Guy 5
Sent: Wednesday, August 05, 2009 7:29 PM
Subject: x:Uid clashes

On a side note, this problem (I’ve ran into it myself today - almost checked in a dupe Uid) highlights the general problem with our current approach if two people work on the same .xaml file at the same time.

Technically, the proper way to handle this is to do msbuild /t:updateuid immediately before every checkin (and after merge). However, that thing generates Uids in a pretty straightforward manner, incrementing the largest used number. Furthermore, if it finds dupes, it always leaves the first Uid intact and updates the following ones. This isn’t what is always desired. Imagine that we have some XAML like this:

<Setter x:Uid=”Setter_1”/>

<Setter x:Uid=”Setter_2”/>

<Setter x:Uid=”Setter_3”/>

You check that out and start working on it. Meanwhile, someone else checks that out, modifies it, and checks in the updated version:

<Setter x:Uid=”Setter_1”/>

<Setter x:Uid=”Setter_2”/>

<Setter x:Uid=”Setter_3”/>

<Setter x:Uid=”Setter_4”/>

You finish your work, and try to check in your own version:

<Setter x:Uid=”Setter_1”/>

<Setter x:Uid=”Setter_4”/>

<Setter x:Uid=”Setter_2”/>

<Setter x:Uid=”Setter_3”/>

Get a conflict, and merge it as follows:

<Setter x:Uid=”Setter_1”/>

<Setter x:Uid=”Setter_4”/>

<Setter x:Uid=”Setter_2”/>

<Setter x:Uid=”Setter_3”/>

<Setter x:Uid=”Setter_4”/>

If you now run updateuid, you’ll get this:

<Setter x:Uid=”Setter_1”/>

<Setter x:Uid=”Setter_4”/>

<Setter x:Uid=”Setter_2”/>

<Setter x:Uid=”Setter_3”/>

<Setter x:Uid=”Setter_5”/>

So your diff is one line larger than it has to be. For this example it probably doesn’t matter much, but it grows proportionally to the amount of changes, and there are some elements which can be changed in large numbers in a typical checkin (style setters probably being the most notable).

Using some other way to generate Uids (GUID? Epoch time?) would solve this problem, but I don’t know any way to make updateuid use different Uid generation algorithm. Any other ideas? Or is it something not worth bothering about in the end?

---

…

Excited to see a file format converter from PowerPoint to Silverlight/WPF XAML from electricrain.

Saw a Microsoft developer evangelist's signature line on email today with Twitter | Blog | Facebook links.  I’ve been giving thought to the different ways I use those 3 communication techniques:

• Blog – broadcasting pointers or short write ups on topics, mostly work topics, but a few personal ones.
• Facebook – i generally only make “friends” there with people I know personally.
• Twitter – i treat this as mostly as a work (WPF/XAML) communication vehicle.

Blogs.msdn.com/officewebapps posts: “The Office Web Apps Love Your Browser”