Adding XMLNS causes VS seize up

Question

Currently in my XAML editor view I am experiencing frequent seizing episodes of around 3 seconds each. I've been able to narrow down the reason for it to custom namespaces.

By default, my page has the 2 default XMLNS declarations:

<Page 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"&gt;
</Page>

This works fine, no seizing. However as soon as I add an XMLNS for controls inside my application it starts seizing up.

<Page 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"    
    xmlns:controls="clr-namespace:MyNamespace.Controls">
</Page>

Its not specific to just that namespace. I've tried a large variety of namespace combinations. Basically any XMLNS pointing to one of MY namespaces causes this issue. I'm not really sure how to diagnose this issue. Any pointers?

SOLUTION

We found out the solution. We had a reference to a Microsoft assembly that was about 7mb in size (ACtiveX stuff for web browsers). When removed, everything sped up. We're now looking at ways to abstract that assembly so that it can exist in the runtime folder but no need for a reference to it from the project. Thanks all for your ideas.

Answer 1

This could be that it is looking for something or that it is recompiling code.

Select the output tag to view compile activity, then see if that is what it is doing next time it siezes up.

In some projects we get this behaviour if we exit debug mode by pressing the stop debug button instead of exiting the program.

Also, there have been several bugs reported for Visual Studio hanging when using DataGrid controls with WPF, it could be related to this. Here are a couple:

http://wpf.codeplex.com/WorkItem/View.aspx?WorkItemId=10542 https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=420621

Answer 2

Are you running a real-time virus scanner? These can often cause sluggish performance when VS needs to compile your code...

Answer 3

First of all we should find out what happens when you close quote mark inside Visual Studio. It's just a program (although a good one) - debug it/profile it.

• Do you have any additional plug-ins installed? Turn them off.
• Turn off Intellisense.
• What happens with MS Expression Blend? Does it seize?
• Turn off all antiviruses.
• Run Process Monitor and track what happens with VS. Are there any errors with file name/registry keys resolution?
• If nothing helped, use profiler on Visual Studio process.
• If nothing helped, write your question on StackOverflow. Oh. Hold on. You did this already. Let's wait for more responses :)!

Cheers!

Answer 4

A plausible guess is that this behavior is tied to VS's XAML editor attempt to provide Intellisense for nodes declared with clr-namespace. This is after all one of the differences between clr-namespaces and other types of namespace (whereby the URI is merely taken as a unique string, but no attempt is done to assert the definition of the underlying XML language.)

A possible workaround is too define the xmlns prefix under a bogus URI, during the xaml editing phase (and hence forgo any hints from intellisense), and to revert to the proper clr-namespace for other phases of the project.

Also, maybe adding the assembly=xxxx to the namespace declaration may help the situation. Even if the assembly in question is that of the current application, this may save the editor and associated intellisense some hesitation.

Another, counter intuitive workaround could be to have these controls in a separate assembly, as this may spare the system from the Intellisense's attempts at dynamically inferring the types structure from the source code, with all the associated hickups caused for example by the background polling for changes etc. (I do not know that it tries to do that, but sometimes, tools are getting to be quite intelligent, but too result in CPU or I/O blocks of the kind you describe.