C # Неуправляемый сбой приложения при использовании Enterprise Library - PullRequest
Новая
       26

C # Неуправляемый сбой приложения при использовании Enterprise Library

1 голос
/ 27 сентября 2011

У меня есть библиотека C # DLL, которая загружается из неуправляемого процесса.Пока все хорошо.Теперь я хотел включить Enterprise Library 5.0 с ее возможностями ведения журналов.Я добавил следующие ссылки:

  • Microsoft.Practices.EnterpriseLibrary.Common.dll
  • Microsoft.Practices.Unity.dll
  • Microsoft.Practices.Unity.Interception.dll
  • Microsoft.Practices.ServiceLocation.dll
  • Microsoft.Practices.EnterpriseLibrary.Logging.dll

... и все необходимые операторы использования.Вот выдержка из класса: 

using Microsoft.Practices.EnterpriseLibrary.Common;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.InterceptionExtension;
using Microsoft.Practices.ServiceLocation;
using Microsoft.Practices.Unity.Configuration;    

[StructLayout(LayoutKind.Sequential,CharSet=CharSet.Unicode,Pack=2)]
unsafe public static class DLLDispatch
{
    private static IConfigurationSourceBuilder LoggingBuilder = new ConfigurationSourceBuilder();
    ...
}

Проблема в том, что, когда это поле определено, происходит сбой неуправляемых процессов.Если это закомментировано, этого сбоя не происходит.И вот журнал приложений Windows для этого сбоя:

** Sig [0] .Name = Имя приложения

Sig [0] .Value = Terminal64.exe

Sig [1] .Name = версия приложения

Sig [1] .Value = 5.0.0.507

Sig [2] .Name = метка времени приложения

Sig [2].Value = 003f5e00

Sig [3] .Name = имя модуля сбоя

Sig [3] .Value = clr.dll

Sig [4] .Name = FaultВерсия модуля

Sig [4] .Value = 4.0.30319.237

Sig [5] .Name = метка времени неисправности модуля

Sig [5] .Value = 4dd2333e

Sig [6] .Name = код исключения

Sig [6] .Value = c00000fd

Sig [7] .Name = смещение исключения

Sig [7] .Value = 000000000007382a **

Я искал в Интернете код исключения c00000fd и обнаружил, что это исключение stackoverflow :-).Я немного поиграл, и этот сбой происходит каждый раз, когда в корпоративной библиотеке задействован экземпляр.Если из этой библиотеки ничего не используется, то сбоев не будет.Что здесь происходит?Это потому, что класс находится в небезопасном контексте или что еще это может быть?Заранее спасибо.

1 Ответ

1 голос
/ 28 сентября 2011

Я нашел решение этой проблемы.Необходимо поместить файл app-config в папку неуправляемого приложения со следующим содержимым: 

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
 <runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <probing privatePath="Unmanaged application startup folder" />
   </assemblyBinding>
 </runtime>
</configuration>

С этой информацией CLR может связывать сборки и выполнять поиск в правильной папке.Мне не было ясно, что файл конфигурации также полезен для неуправляемых приложений.

Спасибо, Юрген

...