Visual Studio 2010 UnresolvedAssemblyException: Тип юниверса не может разрешить сборку: log4net

Question

Недавно я столкнулся с исключениями в конструкторе WPF Visual Studio 2010, по-видимому, из-за log4net.Если я заново создаю свой проект, файл XAML будет правильно отображаться в конструкторе.Затем, как только я начинаю нажимать на элементы управления для перехода в XAML, быстро выдается это исключение:

System.Reflection.Adds.UnresolvedAssemblyException

Type universe cannot resolve assembly: log4net, Version=1.2.10.0, Culture=neutral,    PublicKeyToken=1b44e1d426115821.

at System.Reflection.Adds.AssemblyProxy.GetResolvedAssembly()
at System.Reflection.Adds.AssemblyProxy.GetHashCode()
continues...

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

Примечание: Я использую .NET 4 Full (не Client Profile), и я переключил конкретную версию на ссылку log4netT / F безрезультатно.

Answer 1

Мне удалось решить проблему после:

1. Поиск этого блога , где автор разрешил аналогичную ситуацию, поместив неразрешенную сборку в папку Public Assemblies (найдена с помощью инструмента k3b fuslogvw)

2. Встреча с FileLoadException, которая привела меня к этой ТАКОЙ записи .

3. Загрузка новой копии log4net, разблокировка zip-файла и замена ссылки в VS и папке Public Assemblies.

Но я все еще не уверен, почему мне пришлось поместить эту конкретную сборку в папку Public Assemblies. Все остальные сборки, на которые я ссылаюсь, не требуют этого шага.

Answer 2

Оказывается, когда у нас возникла эта проблема, это было связано с путями, которые мы использовали для добавления ссылок.

Мы используем несколько пользовательских файлов ".targets", которые определяют ссылки. Существует множество смешанных зависимостей с проектами, и использование файлов .targets помогает хранить ссылки, определенные в одном месте.

Ну, ссылки HintPath в конечном итоге что-то вроде ...

<HintPath>C:\Program Files (x86)\\Custom\CustomControlsWPF2.2011\Source\\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>

Когда мы удалили двойную черную косую черту, заменив ее одним «\», ошибка «UnresolvedAssemblyException для Visual Studio 2010: тип юниверса не может разрешить сборку» исчезла.

Вот как это должно было быть.

<HintPath>C:\Program Files (x86)\Custom\CustomControlsWPF2.2011\Source\..\Binaries\WPF\Custom.Windows.Controls.dll</HintPath>

Answer 3

Добавьте путь к вашей сборке "log4net" в Свойствах проекта / Ссылочные пути.

http://msdn.microsoft.com/en-us/library/6taasyc6(v=VS.100).aspx

Answer 4

Вы можете использовать «Средство просмотра журнала привязки сборки» (Fuslogvw.exe), принадлежащее dotnet sdk, чтобы узнать, какая dll загружена, когда и почему.Если ведение журнала включено, он может показать, какие сборки загружены и какая сборка вызвала его загрузку.

Подробнее см. http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.80).aspx

Иногда dll есть, но в неправильной версии.

если вы включаете в свой файл universe.dll, вы также должны включить log4net.dll с локальной копией = true

Answer 5

Убедитесь, что ваш код выполняется во время разработки, а также во время выполнения.Если ваш код выполняется во время разработки, не думайте, что Application.Current является вашим приложением.Например, когда вы используете Expression Blend, Current является Expression Blend.Типичные операции, которые вызывают сбой пользовательского элемента управления во время разработки, включают следующее.

-Casting Current to your custom subclass of Application.

-Using the FindName method on Current.

-Not checking whether Application.Current has returned a value that is null. If Visual Studio does not create an application object, then Application.Current may return null.

http://msdn.microsoft.com/en-us/library/ff356886%28v=vs.95%29.aspx

.добавьте его в начале ваших функций:

// Check for design mode. 
if ((bool)(System.ComponentModel.DesignerProperties.IsInDesignModeProperty.GetMetadata(typeof(DependencyObject)).DefaultValue))
{
    return;
}