Программа компиляции ошибок в Visual Studio 2008

Question

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

Cannot register assembly "obj\Debug\MyProject.Vsto.dll". 
Loading this assembly would produce a different grant set from other instances. 
(Exception from HRESULT: 0x80131401) 

С чего начать, чтобы устранить эту проблему?

Я должен упомянуть, что это VS2008 среда с VS2008 SP1 и это решение:
1. Проект VSTO Excel 2007 (C#)
2. Доступ к данным/Service Layer DLL (C#)
3. тестовый проект MbUnit для # 2 (C#)

UPDATE: Я хотел бы добавить это сделало работу штраф в течение нескольких месяцев. Единственное, что я изменил за последнюю неделю или около того, я начал работать над кодом через Team Foundation Server (TFS).

UPDATE 2: Удаление файла .suo работал на некоторое время. Теперь я снова получаю ту же ошибку ... хммм. Угадай, что я закрою проект, еще раз удалю .suo.

ОБНОВЛЕНИЕ 3: VS2008 позволит мне скомпилировать решение один раз. Второй раз, когда я пытаюсь получить ошибку. Если я выйду, удалите файл .suo и снова запустите, я могу скомпилировать один раз снова. Любые мысли к делу? Это VS2008 SP1?

Для щедрот я ищу постоянное решение.

Answer 1

Просто FYI ... это выглядит как CLR HRESULT (13 в середине указывает на это). Acording в этом блоге: A lot of HRESULT codes... Это специфический HRESULT является SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343

Скорее всего некоторый странствующий процесс проводит открытый дескриптор по сборке и предотвращению компилятора, устанавливающего новый. Учитывая обновление №3, этот процесс, вероятно, является devenv.exe ... что бесполезно в его сужении, однако это может быть какой-то фоновый процесс, который закрывается VS (например, процесс хостинга отладчика).

Предполагая, что что-то держит файл ... чтобы отладить этот тип вещей, первым шагом является открытие procexp.exe из SysInternals набора инструментов. В нем вы можете использовать Find, чтобы определить, какой процесс имеет дескриптор, открытый для файла. Я ожидаю, что он покажет ручку, открытую в файле devenv.exe, когда вы столкнетесь с этой проблемой.

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

Если вы знаете, какой процесс имеет открытую рукоятку, вам необходимо убедиться, что вы можете предотвратить его попадание в кажущуюся утечку рукоятки. Я бы проверял настройки проекта ... включая отладочные для всего, что копирует файлы. Если есть параметр отладчика, называемый процессом VSHosting ... отключите его.

Удачи.

Answer 2

Я сделал несколько поисковых запросов и нашел this post on MSDN Forums, которые могут (или не могут) оказаться полезными для вас.

В нем упоминаются несколько исправлений Windows Updates, которые должны быть установлены (если вы используете Vista), а также обходной путь, если вы находитесь в XP. Хотя сообщение ссылается на проблемы с Silverlight ... ошибка такая же, так что, может быть?

Удачи вам!

Answer 3

Я не видел эту точную ошибку, но подобные ошибки могут возникнуть, если есть другая копия DLL, загружаемая из другого места.

Я бы сделать поиск, чтобы увидеть, если есть какие-либо другие копии этой DLL валяется

dir MyProject.*.dll /s 

Answer 4

Я видел этот thread, который, кажется, чтобы выделить некоторые похожести вопросы.

способы устранения неполадок? Я бы сказал, сначала проверьте, может ли ваше приложение генерировать подобное сообщение об ошибке. Затем проверяется, могут ли библиотеки или система, на которых работает ваше программное обеспечение, быть неисправными (затем обратитесь за поддержкой или поддержкой сообщества).

Удачи.

Answer 5

Значит, он создает dll, но не любит использовать его позже? Если это так, попытались ли вы открыть DLL в Reflector, чтобы узнать, какие различия могут быть между первой и второй компиляцией?

Другая мысль - вы пробовали очистить/восстановить после первой успешной сборки?Вы обновляете номера версий на каждом компиляции? Мне интересно, ссылается ли устаревший файл, но обновляется после первого компиляции. В этот момент ссылки не соответствуют ожидаемым.

Другая случайная мысль. Файл .suo обычно содержит информацию, связанную с вашей отдельной машиной. Что-то, связанное с компиляцией, не должно быть сохранено в этом файле - вместо этого следует перейти к .sln. Казалось бы странным, что .suo является основной причиной ...

Answer 6

кажется, что вы разрабатываете расширение ms-office. Затем вы должны установить последнюю версию COM Shim Wizard. Скачать для VS2008: here.

Расширения управляемого офиса должны быть изолированы друг от друга. This article on MSDN объясняет, почему и как.

Я предполагаю, что ваш .dll не изолирован, и, следовательно, ваш получить, что "Security-доля ошибок":

изоляции. Если вы не используете стандартный COM подкладки (например, Визуальные Studio Tools для офиса загрузчика) или предоставить собственный COM подкладку, ваши расширения DLL загружается в домен приложения по умолчанию вместе со всеми другим не- перемычки. Все библиотеки DLL , работающие в одном домене приложений , уязвимы для потенциального повреждения , вызванные любой другой DLL в том же доменном имени . Кроме того, любая добавленная надстройка, которая выходит из строя в хост-приложении , отключает все остальные надстрочные надстройки для этого приложения .

Разработка офисных расширений выглядит так просто в начале, но потом ....

Томас

Answer 7

Это немного за пределами своей области, но я нашел следующее link which suggests that you are encountering a known defect с .net 2.0.

Я скопировал следующие из предлагаемой работы-вокруг от Microsoft:

Проблема возникает, когда маршалинга объекта по значению между двумя AppDomains в том же процессе, где тип экземпляра является родовые, общий типа шаблона определяются в mscorlib, один или несколько его инстанцирования типов не определена в mscorlib и многодоменный погрузчик оптимизации включена в одном домене, но не о Ther.

К сожалению, эта ошибка была обнаружена слишком поздно и не сделала планку для продукта V2.0. Есть некоторые обходные однако:

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

set complus_UseNewCrossDomainRemoting=0 

Или путем установки реестра HKEY_CURRENT_USER \ Software \ Microsoft.NETFramework \ UseNewCrossDomainRemoting (DWORD) до 0 (или версии в HKEY_LOCAL_MACHINE).

Это немного тяжеловесный, но это также можно обмануть оптимизированный путь в избегая только конкретный вызов, который передает проблемное объект. Для этого добавьте фиктивный параметр на вызов (для различных технических соображений оптимизированный путь еще не реализует параметры).

Вы также можете избежать использования определенного типа mscorlib . В REPRO представленном случае это достаточно просто, так как вы можете просто подтипа список:

[Serializable] 
public class MyList<T> : List<T> 
{ 
} 

(Просто замените все использования списка с MyList).

И, наконец, проблема не должна возникать , если обе области приложений используют многодоменную оптимизацию.Вы не можете установить оптимизации загрузчика домена по умолчанию после того, как вы уже работает, но вы можете установить его внешне (я полагаю, через неуправляемый хостинг API или файл конфигурации , хотя я не эксперт в либо, извините), либо создав новый домен (с многодоменной опцией) в пределах ваш код и передайте управление на его (посредством вызова объекта MBRO в этот домен).

Извините, если вы уже нашли эту статью в своем поиске, но я не рассматривал ее здесь как решение.

Answer 8

Вы не возитесь с системным временем, не так ли? Это может испортить ваши сборки.