Справочник по обновлению VS2010 * сумасшедший * медленный (около 5 минут)

Question

наша команда начинает бояться обновлять сервисные ссылки в нашем решении, потому что это 5 + минутная инвестиция. Внутри веб-сервера Visual Studio все локально.

Мой вопрос - как я могу отладить, что это за проблема? Он работает нормально, как только он закончился, но долгая задержка сводит с ума. Если бы у меня была подсказка, где искать, возможно, я мог бы решить эту проблему.

Answer 1

С VS2012 я столкнулся с той же проблемой: мне потребовалось почти 10 минут, чтобы обновить одну справочную службу. Мне просто удалось это исправить, повторно добавив сервис следующим образом:

• Удалить ссылку на услугу.
• Щелкните правой кнопкой мыши «Service References» и выберите «Add Service Reference».
• Нажмите «Обнаружить» (требуется в моем случае, для других может отличаться).
• Выберите услугу, которую вы хотите добавить в разделе «Услуги».
• Дайте службе имя (под «Пространством имен» внизу »).
• Нажмите «Дополнительно».
• Снимите флажок «Повторное использование типов в ссылочных сборках» и нажмите «ОК».
• Нажмите «ОК», чтобы добавить сервисный справочник.

Для меня повторное использование типов было большой проблемой: теперь, когда это не проверено, новые обновления занимают всего несколько секунд. Поскольку я не мог найти это решение где-либо еще, я подумал, что просто опубликую его здесь, если другие столкнутся с подобной проблемой.

Answer 2

Я заметил, что использование svcutil вместо Add Service Reference в Visual Studio приводит к сокращению времени генерации, хотя иногда сгенерированный код немного отличается (подробнее об этом позже).

На работе у нас есть служба WCF, состоящая из около 100 сервисных операций и 100 сервисных контрактов, а генерация прокси в Visual Studio 2012, начиная с WSDL, предоставляемой сервисом, занимает около 7 минут.Затем я попытался использовать svcutil (без каких-либо опций), и генерация заняла всего около 2 минут.

Мне пришлось добавить несколько опций, чтобы соответствовать тем же характеристикам, указанным в справочнике услуг (/enableDataBinding, /serializable, /namespace:*,myns, /syncOnly и collectionType:System.ComponentModel.BindingList'1) и с помощью этой опции время генерации увеличено до 3 с половиной минут.В целом генерация прокси не на порядок быстрее, но по крайней мере время генерации должно быть сокращено вдвое.

По моему опыту, у двух методов генерации есть некоторые различия, на которые я хотел бы обратить внимание:

• Visual Studio создает файлы datasource (файл, сгенерированный Visual Studio при добавлении источника данных объекта в проект Windows Forms, см. Также этот поток SO );svcutil не имеет возможности их генерировать.Это не должно быть серьезной проблемой, так как при первой привязке данных к контракту файл должен быть сгенерирован Visual Studio.Кроме того, если прокси-сервер скомпилирован в отдельной сборке, ссылающийся проект не сможет повторно использовать сгенерированные файлы datasource, поскольку они не включены в сборку и все равно будут восстановлены.

• свойство ConfigurationName контрактов на обслуживание может отличаться, очевидно, потому что два метода генерации по-разному учитывают целевое пространство имен при генерации значения атрибута.В нашем случае это проблема, поскольку мы не используем сгенерированный app.config.Однако этим можно легко управлять, изменив app.config в соответствии с новым значением или (автоматически) изменив свойство ConfigurationName в созданном источнике прокси.

• svcutil делаетне украшайте свойство ExtensionData атрибутом Browsable(false) - это может быть проблемой, если (как и мы) вы используете контракты данных в качестве источника для привязки данных в Windows Forms, поскольку все сетки теперь получат дополнительный столбец для ExtensionData.Как и предыдущий сбой, это можно сделать, добавив атрибут с помощью sed -подобного инструмента (например, я использовал фрагмент PowerShell, содержащийся в этом ответе ).

Answer 3

Скорее всего, файлы .suo стали нелепыми из-за постоянного обновления. Вы можете проверить это, изучив источник. Если это так, вы можете удалить .suo и обновить ссылку. Возможно, вы захотите сделать резервную копию, на тот случай, если вы забыли какие-то другие ваши пользовательские настройки.

Другой вариант - WSDL, поскольку служба только что стала чертовски большой, и вам нужно прикусить пулю.

Если вы хотите уменьшить воздействие, попросите сотрудников службы заключить договор, используя малоизвестный секрет, называемый планированием. ;-) Честно говоря, плохое планирование часто является основной причиной многих проблем, возникающих в VS.

Answer 4

Медленная проблема с обновлением веб-ссылок.Я был сбит с толку о времени.Более 1 часа.

Какой-то сотрудник сказал добавить мой путь к рабочей области, исключаемый из Защитника Windows, и это решит мою проблему.

Answer 5

Я столкнулся с этой же проблемой только сейчас, и обновление моей справочной службы занимало около 10-15 минут, иногда ее не удавалось обновить. Я был разочарован и, наконец, удалил ссылку, а затем добавил ее еще раз. И теперь все работает нормально.

Итак, я предлагаю вам удалить ссылку и добавить ее снова, и посмотрим, что произойдет