Rob Relyea


December 2004 - Posts

  • Beta1 VisualStudio perf problems after compiling Avalon projects

    Filed under:

    I think I wrote details about this recently, but I can't find it (was it in the newsgroups?  a comment on somebody's blog?  an internal email?)  ...from now on, I'll put more things like this in my blog, so I can write it once...and find it.

    The question came up from Brandon this time:

    This may be a VS bug, but it only happens with Avalon applications. When I run an Avalon application in debug mode from VS I get 99% CPU usage AFTER I stop debugging. This doesnt go away until I close Visual Studio.


    The beta1 version of Visual Studio Whidbey's C# language service had problems if you tried to give it a .cs file to compile that didn't have an ID.  Unfortunately, that is what happens with Avalon projects.  You start with 1 or more .xaml files and they create a .baml and .g.cs file.  See MarkupCompilation: XAML, BAML, .g.cs Details if you want to learn more.

    So, this problem only occurs when you do one of the following:

    • build a project for the first time.
    • build a project after “cleaning” it.
    • build a project after adding any new XAML pages to it.


    We found this problem before we shipped the November 2004 Avalon CTP.  We got a special build of cslangsvc.dll from the C# team that fixed this problem and had the WinFX SDK team install it with the SDK.

    So, if you installed the WinFX SDK after you installed VisualStudio, you should have a .51 version of cslangsvc.dll that will make the problem go away.

    UPDATE: Chris Sells said that didn't work for him.  Turns out he has a 40607.85 build of VS installed...yes beta1, but I think it came with Yukon.  It appears like the .51 patch doesn't install on top of that build.  Lars had already worked with some VS folks to learn of another solution: In HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor change the data of value UpdateRegisterDesignViewOnIdle from 1 to 0... we're not exactly sure how the two fixes relate...but looks like one or the other should fix it...let me know if not.

    Other lame workaround:

    File/Close Solution, then reopen the solution.  Do this whenever you get into the bad state.

    A measure of Visual Studio “Whidbey“ progress

    If you measure the Visual Studio team's progress by how many Visual Studio “Whidbey” assemblies we need to patch, they are doing very well.  For PDC 2003, they patched about 10 assemblies to make sure msbuild worked inside of Visual Studio for us.  For Avalon CTP Nov 2004, we only had to patch this one assembly.  Hopefully, next release we get to 0!

  • Funny theory predicting the failure of C#

    Filed under:

    Funny post predicting failure/success of languages based on photos... [via Stéphane Rodriguez]

  • MsBuild and Avalon

    Filed under:

    If you peek under the covers in a .csproj or .vbproj of an Avalon project, you'll be looking at the msbuild project file format.  The Avalon team has gone through a long journey with our markup compilation, but I'm happy about where we have arrived.

    First, a long time ago (~3 years ago?) we started by building AMC.exe - Avalon markup compiler.  It would take a .xaml file and create a .g.cs or .g.vb file.

    Soon, we realized we really needed to own more of the build process, so we built AC.exe - Avalon compiler.  It not only did markup compilation, but it also called CSC, VBC, etc... but we had to hardcode support for each language in there.

    Eventually, we found out about MsBuild (then under a code name) and realized that we didn't need to own the whole build process to add value.  We could refactor much of what we did in AC.exe into some build Tasks that did markup compilation, etc...

    That is where we are now.  In every project file, you'll notice an:

    <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />

    That is the targets file where we say: during build, markup compilation should come before code compilation, etc...

    The MsBuild team has done a great job with their project!


    I just thought to blog this because of JeffCal's recent blog that has several excellent pointers:

    “there's an msbuild wiki over at channel 9, and there's a good preview of the msbuild documentation over at msdn:


     Go check out the wiki, docs, and read blogs of JeffCal and Alex Kipman to learn more about msbuild.


    Let me know if you have any questions about Avalon's use of msbuild...

  • Why isn't xmlns:def="Definition" gone yet...cost of change...

    Filed under: , ,

    Drew Marsh asked a good question recently about why we didn't Uri-ize the Definition xmlns yet...  I answered via a comment here.

    Keep raising issues that you don't see getting fixed...

    Thanks, Rob

    PS.  Making any breaking change is way too expensive.  We are working on a tool right now that can make any object model name change for xaml.  We're also getting it to work with C#.  If things work well, perhaps we'll have a tool in the future to help our developers make changes and all the customers building on top of us may get some of their code changed automatically...Won't be perfect, but may get people a long way.

    I look at it as a delayed refactoring tool.  Love the VS Whidbey refactoring stuff for your local project...but when you have hundreds or thousands or more people building on top of you, the refactoring features don't do anything to delay the refactoring.

  • Attached Properties, Dependency Object, Dependency Properties

    Filed under: ,

    Drew Marsh wrote a great intro to those topics today.

    I'll add a few things...Drew covers the concept of Attached Properties.  He should update the post to include examples of non-attached properties as well...

    We have tried to make the fact that DependencyProperties exist pretty hidden.  I can remember ~2 years ago when you had to call .SetValue() to do much of anything.  Since then we require all properties to be normal CLR properties.  Some of those properties have DPs (Depenency Properites) under the covers which give additional services.  But to a developer, when I want to set the Background color of a button, I just do use a strongly typed property:

    button1.Background = Brushes.Green;

    instead of the loosely typed:

    button1.SetValue(BackgroundProperty, Brushes.Green);

    Anyway, we hope that most people don't need to know all the reasons for them, but DOs, DPs and Attached Properties are important Avalon concepts.

    Let us know how it feels...try styles, try inheritance of properties, type programming against properties and attached properties...and then write down your thoughts...

  • Testers are customer advocates - and are best when they ...

    Filed under:

    Testers are customer advocates - and are best when they...
     know what real customers want to do with the technology/product that they are testing.

    It takes a number of different disciplines to build software.  At Microsoft, 4 different categories make up most of the people on our development teams: Developers, Program Managers, Testers and Technical Writers.  (Our team also has a few designers...)

    We have a few Testers from the Avalon team who are blogging: Zhanbo, Marcelo

    A little while ago Zhanbo had a post about Avalon's visual tree.
    Marcelo just posted about Avalon, high DPI and screen real estate

    Anybody else out there yet?

    Update: I totally forgot to mention Architects...kinda silly seeing that I work closely with them all...

  • Xaml Page Design for Designers?

    Filed under: ,

    I enjoy reading John Dowdell.  The latest thing I learned there about was Web Page Design for Designers.  As a non-designer, I had never known about Joe Gillespie's work with - looks like he built a great destination.  Joe's final editorial before his retirement is an interesting read as it talks about his history with waves of new technology.

    Learning of Joe's work and comments like this on my blog from Arturo Toledo make we wonder who is going to step up and be the authority on Xaml Page Design for Designers?

    From XAMLs and Avalon´s real potential will only be realized when we have a graphic editor. XAML strongest users will be designers. They don´t code (some do but aint common)... they draw, drag, pull and sketch. They use a mouse or a tablet not a keyboard. This side of the story... the designer one, is what makes Avalon ENORMOUS in its potential. The techie side matters a lot too, specially right now where the infrastructure is being developed as we speak but the ultimate goal should be based on a creative / designer point of view who at the end will be the kind of user / developer exploiting Avalon / XAML capabilities.

    Yes, I am graphic designer - animator ... and I can code :)

    Joe please let me know if you are initerested in a copy of our latest Customer Tech Preview of Avalon & XAML...perhaps can be your next passion?

    Designers - What would you want to see on