Ошибка компиляции программы в 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. DLL доступа к данным / уровня обслуживания (C #)
3. Тестовый проект MbUnit для # 2 (C #)

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

ОБНОВЛЕНИЕ 2: Удаление файла .suo работало некоторое время. Теперь я снова получаю ту же ошибку .... хммм. Думаю, я закрою проект, удалите .suo снова.

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

За награду я ищу постоянное решение.

Answer 1

Просто к вашему сведению ... это похоже на CLR HRESULT (13 в середине указывает на это). Согласно этому сообщению в блоге: Много кодов HRESULT ... Это конкретный HRESULT SECURITY_E_INCOMPATIBLE_SHARE 0x80131401 -2146233343

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

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

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

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

Удачи.

Answer 2

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

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

Я предполагаю, что ваш .dll не изолирован, и поэтому вы получаете "Security-share-error":

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

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

Thomas

Answer 3

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

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

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

Answer 4

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

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

dir MyProject.*.dll /s

Answer 5

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

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

Удачи!

Answer 6

Ты не тратишься на системное время? Это может испортить ваши сборки.

Answer 7

Это немного за пределами моей области, но я нашел следующую ссылку , которая указывает на то, что вы столкнулись с известным дефектом в .net 2.0.

Я скопировал следующее из предложенного обходного пути от Microsoft:

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

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

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

set complus_UseNewCrossDomainRemoting=0

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

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

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

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

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

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

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

Answer 8

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

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

Удачи.