Partilhar via

Upgrading from March CTP to May CTP

  • Artigo

So I spent part of my weekend updating various applications to the most recent CTP. I figured I would try it the same way most people outside of Microsoft would do it -- by using Google and searching the Avalon newsgroup. All told, I found the answers I needed pretty quickly, but figured I would relate this story to give people a few more places to look for porting information.

Style.VisualTree -> Template: One of the first things I hit was Style.VisualTree was changed to Template. Although I was tangentially involved in this change, I found it easier to follow Drew Marsh's blog about the changes than try to remember the gory details on my own: https://blog.hackedbrain.com/articles/AvalonMay05BetaChangeLogCommentary.aspx

Style.Storyboards -> ControlTemplate.Storyboards: My Style had a storyboard. In this case, since there was no style left after removing the template, I moved the storyboard to be a part of the template. I noticed a call to Style.FindStoryboardClock(), took me a while to realize I didn't need to change it (it’s a static method that has more to do with storyboards than with styles)

Then there were the straightforward renames:

  • ID -> Name, StyleID -> Name
  • {Bind} -> {Binding}
  • TimelineClock -> Clock
  • TimeSeekOrigin.Begin -> TimeSeekOrigin.BeginTime

Then I got this compilation error:

<UICulture> should be set in the project file in order to support the following markup files that use types defined in this project

Fortunately, Tim Sneath told me everything I needed to know about this on https://blogs.msdn.com/tims/archive/2005/05/31/423511.aspx -- a couple hours later, I was an expert at cutting and pasting <UICulture>en-US</UICulture> into the <PropertyGroup> section of my project file.

In my applications that use WinForms interop (e.g., ElementHost), I needed to add a reference to WindowsFormsIntegration.dll, which now ships as part of the SDK rather than in the main Avalon.msi. On my machine, the path is C:\Program Files\Reference Assemblies\Microsoft\Avalon\v2.0.50215\WindowsFormsIntegration.dll, although I can't swear I'm running exactly the same build as the May CTP so your path may vary slightly. If you haven't used that part of Visual Studio before, it's pretty easy -- go into the Solution Explorer, right click on "references", choose "Add References", go to the "Browse" tab, and pick that file.

The next error was more annoying than difficult -- I used to be able to put a Page directly inside an ElementHost (ElementHost lets you put Avalon inside WinForms), but now Page complains that "Only Window and Frame can parent a Page. " I probably should have changed my root xaml tag to something other than a Page -- e.g., a Grid -- but for some reason I was feeling stubborn, and instead decided to rip the grid out of the page:

            Page1 p = new Page1();
            sw.FrameworkElement root = p.root;
            p.Child = null;
            host.AddChild(root);

Finally, I had an application that's part Win32, part Avalon, and that uses multiple assemblies. The first time I tried to instantiate page out of my Avalon assembly, it came back with this exception: Cannot locate the resource 'avclock/clock.baml' . Quick search on the newsgroups found that the solution is to call Application.RegisterComponent("assemblyname").

All told, probably took me an hour of porting to get my samples running again, so not too hard. It's definitely a change of pace for me, applying a bunch of different API changes to a small number of files. Lately I've had more experience making one API change to a whole bunch of files when we changed ID to Name, that touched about 6000 files! I'm glad we're not doing that again...