Welcome to WindowsClient.net | Sign in | Join

Rob Relyea - XAMLified

WPF, Silverlight and XAML

Yes, XAML2009 isn't everywhere yet...

Rob commented on the beta 1 announcement post:

  • "So, are you saying, you created Xaml2009, but we can't actually use it with VS or Blend until post .NET 4.0?  And are you saying that we can't write applications with it without writing some bootstrapping code, because it currently doesn't compile to BAML + IL?  Can you elaborate please."

Yes, when VS 2010 and .NET 4 ship, VS 2010 (Cider designer + XAML editor), Blend, Silverlight, and WPF's BAML won't have support for the new language features yet.  This isn't ideal, but is the best we could do in this timeframe.

The major accomplishments that we have achieved in .NET 4 is:

  • having one consistent XAML stack that is shared in WPF/WCF/WF (and beyond)
  • moving XAML lower in the stack, out of WPF assemblies, into an assembly that depends on MsCorLib, System, System.Xml.  In Beta1, it still depends on WindowsBase.dll, we hope to do some type forwarding (of ContentPropertyAttribute, etc...) from WindowsBase.dll to System.Xaml.dll in the next beta.
  • moving WPF to 1 parser, instead of 3...it used to have seperate code paths for template, styles, and other parsing.  Consistent behavior everywhere!
  • creating a public API for BAML Reading, enabling analysis of XAML or BAML with the same API.  ("BamlReader as Text" mode should be available next beta, it didn't make beta1.)
  • ...

We had intended to enable BAML for the new language features, but "flipping" WPF/WF/WCF to all use the new stack ended up taking more work than we thought.  Once WPF was flipped, we realized we also had significant perf work to do...as BAML in v3 avoided reflection, and we weren't doing that yet.

WPF 4 users will be able to use all of the XAML2009 lanugage features if they change the build action from Page to Resource.  This will avoid compiling the XAML into BAML/IL.  Events can still work in this scenario...Button Click="foo" looks for a "foo" method on the root object, so put a Window1 class at the root.  We'll work on a sample.

We'll be working across all those groups to get support as soon as possible after .NET 4.

I understand that this fact makes it harder for WPF users to be excited about the new language features...

Published Wednesday, May 20, 2009 8:18 AM by Rob_Relyea
Filed under: , ,

Comments

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 12:05 PM

Are you serious? You'll only be solving this AFTER .net 4 is released? Is it so hard to fix?

by Bruno Silva

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 12:31 PM

Bruno-

Our v3 MarkupCompiler is built on top of the old parser, so it wouldn't be cheap to enhance it to understand all the new language features.  In addition, we need to enhance or replace the BAML format for these new language features.

Our goal was to build a new MarkupCompiler for WPF, work on a public BamlWriter API that it would leverage, and support Xaml2009 at that point.

We have enough balls in the air right now that it is important that we don't throw more in the air.

I'd love to know what XAML2009 feature pains you the most to not have support for in BAML in WPF 4?

Thanks, Rob

by Rob_Relyea

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 1:53 PM

is xaml2009 going to have its own namespace??

thnx douglas

by Douglash

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 2:37 PM

Hi Rob, First of all thanks for your reply, it cleared part of my confusion. I still have some questions though. Wouldn't it make sense to delay .net4 until you develop the new markupCompiler? I know this isn't an easy task, but I've been using hacks, beta, alpha versions since you introduced WPF for the first time in the 2003 PDC. I loved it right from the start, but this situation feels like a step back using hacks to use new features, one would expect that v4 would work out of the box. The problem here isn't that big if you turn the pages into resources, if your user controls use commanding, etc. I see it mostly as an inconvinience to new users. My main pain with this solution will be performance, startup time of solutions using resources instead of compiled BAML.

by Bruno Silva

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 2:38 PM

In beta1, you can use the XAML2009 features using the same 2006 namespace.

If you choose to use any of the new attributes/elements, they will just work, without having to twiddle with namespaces.

Thanks, Rob

by Rob_Relyea

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 4:01 PM

Slightly OT, sorry: The first thing I tried with the beta was binding to dynamic properties, but it didn't work. Is support for this on the roadmap? I'm working on an extensible object framework using MEF and I need to be able to provide binding to properties provided by the dynamic meta-object pattern.

by Mark Rendle

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 20, 2009 4:07 PM

Can you shed some light on Silverlight with regards to the one consistent Xaml stack that is shared? SL4? Never? Unknown?

Thanks.

by Kendall

# re: Yes, XAML2009 isn't everywhere yet...@ Thursday, May 21, 2009 3:04 AM

Rob,

I've been working with the 2010 beta today, and trying to compile one of my WPF projects.  I have reported one bug related to XAML parsing: connect.microsoft.com/.../ViewFeedback.aspx.

I also have a problem because my main window won't load.  It is derived from a custom navigation window type that I have created because the WPF navigation window didn't work the way that I wanted to.  The xaml works perfectly fine in .net 3.5, but gives a "Exception has been thrown by the target of an invocation." exception.  The innermost exception is "Key cannot be null.

Parameter name: key".

I've tried to isolate it in the editor, and it comes down to either a content presenter in a toggle button style or a menu's ItemContainerStyle property (both part of the navigation window style).  Either of these cause the above exception, although I'm not sure about the inner exception it maybe different between them.

I can't find any easy way to isolate the point of getting it small enough to be a bug to post on the connect site, but if you have any other suggestions as to how I could isolate it more easily please let me know.  I can't even find a way to isolate it outside of the particular window where the problem occurs.

I'm going to replace my navigation window with a Window/Frame system, so that it is more similar to the way Silverlight implements it, and hopefully that will resolve the problem.

...Stefan

by Stefan Olson

# re: Yes, XAML2009 isn't everywhere yet...@ Thursday, May 21, 2009 3:16 PM

Thanks Stefan.

We will dig into your 2 issues.  The first still repros.

The 2nd sounds like an issue we recently fixed (in Beta2 tree), but we'll verify.  We can't repro without your code though...can you please send as minimal code as you can get that shows the problem and send it to me (rob.relyea at microsoft.com).

Thanks, Rob

by Rob_Relyea

# re: Yes, XAML2009 isn't everywhere yet...@ Thursday, May 21, 2009 5:59 PM

Mark-

Support for this is definitely on the roadmap, although it is not slated for this release.  We recognize this as an important integration feature, and look forward to getting it done when the schedule permits.

Sorry, Rob

by Rob_Relyea

# re: Yes, XAML2009 isn't everywhere yet...@ Thursday, May 21, 2009 6:01 PM

Kendall-

We’re looking at which XAML features to expose in Silverlight and in which timeframe.  We’re also considering sharing more of the internal implementations between System.Xaml.dll and the XAML parser in Silverlight.

Beyond that, System.Xaml.dll will be useful for Silverlight XAML scenarios in a few ways:

• We want to ensure that System.Xaml.dll can process Silverlight XAML, in order to make analysis, tools, etc… easily buildable.

• At runtime, we’ll see what demand exists for System.Xaml.dll services running on the Silverlight runtime (for example XamlWriter.Save() like functionality).

Thanks, Rob

by Rob_Relyea

# re: Yes, XAML2009 isn't everywhere yet...@ Tuesday, May 26, 2009 3:45 PM

Francis have you looked at prism for sl?? they emulate Icommand, Haven't checked it out yet myself but from what I have read in the docs.

Rob,

My hope is to see a WPF Futures implementation soon even if it is closed source.

It is ashame we won't see it in vs2010 but it is also something I don't want to wait for 2 years to play with either.

Douglas

by Douglash

# re: Yes, XAML2009 isn't everywhere yet...@ Wednesday, May 27, 2009 9:51 PM

Hi Douglas,

Thanks for your answer. I did look at Prism, but I still wondered if ICommand would be native to SL4 (or a later version). The less references I have in my app, the happier I am ;)

by Frances

# re: Yes, XAML2009 isn't everywhere yet...@ Thursday, May 28, 2009 8:14 PM

Frances,

Silverlight does include ICommand but no implementation of commands.

...Stefan

by Stefan Olson

# re: Yes, XAML2009 isn't everywhere yet...@ Tuesday, August 11, 2009 8:36 PM

Despite the delays, this is still fantastic news.  I'm excited by these (long overdue) features, but given Microsoft's requirement for backwards compatibility I would rather a well thought out implementation rather than a hacky mess we'll be stuck with for a long time.

Still, I'm hoping XAML2009 will become available between releases or maybe in SP1.

by Carl Scarlett

Leave a Comment

(required) 
(required) 
(optional)
(required) 
Page view counter