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.
Problem:
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.
Solution:
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!