Добавянето на XMLNS причинява блокиране на VS

В момента в моя изглед на XAML редактор получавам чести епизоди на припадъци от около 3 секунди всеки. Успях да стесня причината за това до персонализирани пространства от имена.

По подразбиране моята страница има 2 XMLNS декларации по подразбиране:

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

Това работи добре, без засядане. Но веднага щом добавя XMLNS за контроли в моето приложение, той започва да блокира.

<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>

Не е специфично само за това пространство от имена. Опитах голямо разнообразие от комбинации от пространства от имена. По принцип всеки XMLNS, сочещ към едно от МОИТЕ пространства от имена, причинява този проблем. Не съм много сигурен как да диагностицирам този проблем. Някакви насоки?

РЕШЕНИЕ

Открихме решението. Имахме препратка към сборка на Microsoft, която беше с размер около 7mb (неща ACtiveX за уеб браузъри). При премахването всичко се ускори. Сега търсим начини да абстрахираме това събрание, така че да може да съществува в папката за изпълнение, но няма нужда от препратка към него от проекта. Благодаря на всички за вашите идеи.


person DarkwingDuck    schedule 08.09.2009    source източник
comment
Трябва да спомена, че това се случва и на машина на друг разработчик. И двамата работим с XP с VS2008SP1. Аз използвам XP SP3, а той е на XP SP2, и двамата имат същия проблем.   -  person DarkwingDuck    schedule 23.09.2009


Отговори (4)


Първо трябва да разберем какво се случва, когато затворите кавичките във Visual Studio. Това е просто програма (макар и добра) - дебъгвайте я/профилирайте я.

  • Имате ли инсталирани допълнителни плъгини? Изключете ги.
  • Изключете Intellisense.
  • Какво се случва с MS Expression Blend? Схваща ли се?
  • Изключете всички антивирусни програми.
  • Стартирайте Process Monitor и проследете какво се случва с VS. Има ли грешки с разрешаването на името на файла/ключовете в регистъра?
  • Ако нищо не помогна, използвайте профильор в процеса на Visual Studio.
  • Ако нищо не помогна, напишете въпроса си на StackOverflow. о дръж се Ти вече направи това. Да чакаме още отговори :)!

наздраве!

person Anvaka    schedule 28.09.2009
comment
Здравей Anvaka, да, изключихме приставките, не, това не се случва в intellisense. Не знаех за използването на proc mon, добър за бъдещи справки! Реших го, ще публикувам най-горе по-късно. +1 за добра поредица от неща, които да опитате. - person DarkwingDuck; 01.10.2009

Това може да е, че търси нещо или че прекомпилира код.

Изберете изходния таг, за да видите дейността на компилиране, след което вижте дали това е, което прави следващия път, когато се заеме.

В някои проекти получаваме това поведение, ако излезем от режима за отстраняване на грешки, като натиснем бутона за спиране на отстраняването на грешки, вместо да излезем от програмата.

Освен това има няколко докладвани грешки за висене на Visual Studio при използване на DataGrid контроли с WPF, може да е свързано с това. Ето няколко:

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

person Shiraz Bhaiji    schedule 24.09.2009
comment
Здравей Шираз, не е свързано с нито едно от тези неща и изходът не показва нищо свързано. - person DarkwingDuck; 01.10.2009

Пускате ли скенер за вируси в реално време? Те често могат да причинят бавна производителност, когато VS трябва да компилира вашия код...

person Rob Fonseca-Ensor    schedule 28.09.2009
comment
Здравейте Роб, да, но моля, обяснете как това причинява проблем само когато са вмъкнати пространства от имена към локални контроли. - person DarkwingDuck; 01.10.2009

Правдоподобно предположение е, че това поведение е свързано с опита на XAML редактора на VS да предостави Intellisense за възли, декларирани с clr-namespace. В края на краищата това е една от разликите между пространствата от имена clr и други типове пространства от имена (при което URI просто се приема като уникален низ, но не се прави опит да се утвърди дефиницията на основния XML език.)

Възможно заобиколно решение е твърде дефиниране на префикса xmlns под фалшив URI по време на фазата на редактиране на xaml (и следователно да се откажат от всякакви подсказки от intellisense) и да се върнете към правилното clr-namespace за други фази на проекта.

Също така може би добавянето на assembly=xxxx към декларацията на пространството от имена може да помогне за ситуацията. Дори ако въпросното сглобяване е това на текущото приложение, това може да спести известно колебание на редактора и свързания intellisense.

Друго, контраинтуитивно заобиколно решение може да бъде разполагането на тези контроли в отделна сглобка, тъй като това може да спести системата от опитите на Intellisense за динамично извеждане на структурата на типове от изходния код, с всички свързани проблеми, причинени например чрез фоново проучване за промени и т.н. (Не знам дали се опитва да направи това, но понякога инструментите стават доста интелигентни, но също водят до CPU или I/O блокове от вида, който описвате.

person mjv    schedule 30.09.2009
comment
+1, защото това е по правилния път. В крайна сметка го решихме, ще публикувам подробности в горната част. - person DarkwingDuck; 01.10.2009