Неуправляемым DLLs не удается загрузиться на сервере ASP.NET

В моем случае я использую EF 6 и украсил одно из свойств моей модели:

[Index(IsUnique = true)]

Чтобы поймать нарушение, я делаю следующее, используя C # 7, это становится много проще:

protected async Task<IActionResult> PostItem(Item item)
{
  _DbContext.Items.Add(item);
  try
  {
    await _DbContext.SaveChangesAsync();
  }
  catch (DbUpdateException e)
  when (e.InnerException?.InnerException is SqlException sqlEx && 
    (sqlEx.Number == 2601 || sqlEx.Number == 2627))
  {
    return StatusCode(StatusCodes.Status409Conflict);
  }

  return Ok();
}

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

66
задан Werg38 5 December 2008 в 17:33
поделиться

6 ответов

Попытайтесь поместить dlls в \System32\Inetsrv каталог. Это - рабочий каталог для IIS на Windows Server.

, Если это не работает попытка, помещая dlls в каталог System32 и файлы зависимости в каталоге Inetsrv.

22
ответ дан Matt 7 November 2019 в 11:08
поделиться

Смотрите с FileMon или ProcMon и фильтр на названиях неприятного DLLs. Это покажет Вам, какие каталоги сканируются в поисках DLLs и любых проблем разрешения, которые Вы могли бы иметь.

6
ответ дан Arnout 7 November 2019 в 11:08
поделиться

Всегда стоимостью в проверка пути переменная в Ваших параметрах среды также.

2
ответ дан annakata 7 November 2019 в 11:08
поделиться

Выполненный ЗАВИСИТ от XYZ.dll непосредственно, в месте, на котором Вы развернули его. Если это ничего не показывает пропавшие без вести, используйте fuslogvw инструмент в SDK платформы для трассировки ошибок загрузчика. Кроме того, журналы событий иногда содержат информацию об отказах загрузить DLLs.

1
ответ дан jlew 7 November 2019 в 11:08
поделиться

В дополнение к ответу Мэтта, это то, что я наконец-то сработал для 64-битного сервера 2003 / IIS 6:

  1. убедитесь, что ваши dlls / asp.net имеют ту же версию (32 / 64 бита)
  2. Поместить неуправляемые dll в inetsrv dir (обратите внимание, что в 64-битных окнах это находится под syswow64, даже если каталог sys32 / inetsrv создан)
  3. Оставьте управляемые dll в / bin
  4. Make уверен, что оба набора DLL имеют разрешения на чтение / выполнение
11
ответ дан 24 November 2019 в 14:58
поделиться

Это происходит из-за того, что управляемые библиотеки DLL копируются теневым образом во временное место в каталоге .NET Framework. См. http://msdn.microsoft.com/en-us/library/ms366723.aspx для получения дополнительных сведений.

К сожалению, неуправляемые библиотеки DLL НЕ копируются, и процесс ASP.NET не копируется. быть в состоянии найти их, когда потребуется их загрузить.

Одно из простых решений - поместить неуправляемые библиотеки DLL в каталог, который находится в системном пути (введите «путь» в командной строке, чтобы увидеть путь на вашем компьютере) так что они могут быть найдены процессом ASP.NET. Каталог System32 - это всегда в пути, поэтому размещение неуправляемых библиотек DLL всегда работает, но я бы рекомендовал добавить в путь какую-нибудь другую папку, а затем добавить туда библиотеки DLL, чтобы предотвратить загрязнение каталога System32.

45
ответ дан 24 November 2019 в 14:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: