Почему App_GlobalResources компилируется для x86, даже если для параметра «Включить 32-разрядные приложения» установлено значение false в IIS?

Question

Почему App_GlobalResources компилируется для x86, даже если для параметра «Включить 32-разрядные приложения» установлено значение false в IIS?

1

Веб-приложение, над которым я работаю, имеет три зависимости x86:

Crystal Reports 32-bit Runtime
Старая домашняя библиотека служебных данных
Старая библиотека доморощенных журналов

Я предпринял следующие действия на нашем промежуточном сервере и на моей локальной машине:

Удалено 32-разрядное время выполнения CR и установлено 64-разрядное
Декомпилировало две доморощенные библиотеки и разместил нужный код в веб-приложении (и удалил ссылку на две сборки)
Установите "Включить 32-разрядные приложения" в значение false в пуле приложений в IIS

Веб-приложение теперь имеет 64-разрядную зависимость (Lync UCMA SDK), что привело к необходимости удаления 32-разрядных зависимостей. Проблема в том, что теперь я получаю следующее сообщение от IIS в браузере или из командной строки, если я пытаюсь вручную использовать aspnet_compile:

Не удалось загрузить файл или файл сборки:///C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Временные файлы ASP.NET\root\6b69372f\fdfe0d46\App_GlobalResources.melxzfvs.dll 'или одна из его зависимостей, Была сделана попытка загрузить программу с неправильным форматом.

Я попытался выполнить следующие действия в своих попытках решить эту проблему:

Очистка временных файлов ASP.NET, где эта DLL существует
Запуск aspnet_regiis -i (64-разрядная версия)
Настройка конфигурации проекта на x64, а не на "Любой процессор",

Просмотр DLL App_GlobalResources в таком инструменте, как Telerik JustDecompile, указывает, что dll скомпилирована специально для платформы x86, даже несмотря на то, что 64-разрядная версия aspnet_compile явно запущена. Каждая другая сборка в папке bin - "Любой процессор".

Что я могу сделать для компиляции для x64?

Изменение: если я удалю папку App_GlobalResources, компилятор ASP.NET продолжает жаловаться, за исключением теперь о App_Code.dll. Та же проблема.

tuespetre 27 авг. 2014, в 17:19

Источник

0

Возможно, попробуйте явно удалить и переустановить сценарии, выполнив aspnet_regiis -u затем aspnet_regiis -i затем aspnet_regiis -c . < msdn.microsoft.com/en-US/library/k6h9cz8h(v = vs.80 ) .aspx > Полагаю, стоит попробовать, возможно, попробовать свежий пул приложений.
Kirk 27 авг. 2014, в 15:38
0

Запустил удаление из 32- и 64-разрядных каталогов, затем установил только из 64-разрядных и перезапустил IIS; не повезло
tuespetre 27 авг. 2014, в 15:41
0

Я не могу воспроизвести эту проблему, к сожалению. Если вы можете подключиться к серверу разработки, возможно, удалите ISAPI-фильтр для 32-разрядных версий .NET, чтобы узнать, может ли он помочь вам решить проблему. Может быть немного решительным, но может помочь определить проблему.
Kirk 27 авг. 2014, в 15:58
0

Я только что проверил другое веб-приложение, и его App_Code и App_Global скомпилированы в 'Any CPU', в то время как файлы этого проекта скомпилированы в 'x86', будь то в Visual Studio с прекомпиляцией в профиле публикации или в IIS после отключения прекомпиляции.
tuespetre 27 авг. 2014, в 16:51

Показать ещё 2 комментария

Теги:

c#

asp.net

.net

iis

1 ответ

Ещё вопросы

Возможно, попробуйте явно удалить и переустановить сценарии, выполнив aspnet_regiis -u затем aspnet_regiis -i затем aspnet_regiis -c . < msdn.microsoft.com/en-US/library/k6h9cz8h(v = vs.80 ) .aspx > Полагаю, стоит попробовать, возможно, попробовать свежий пул приложений.
Запустил удаление из 32- и 64-разрядных каталогов, затем установил только из 64-разрядных и перезапустил IIS; не повезло
Я не могу воспроизвести эту проблему, к сожалению. Если вы можете подключиться к серверу разработки, возможно, удалите ISAPI-фильтр для 32-разрядных версий .NET, чтобы узнать, может ли он помочь вам решить проблему. Может быть немного решительным, но может помочь определить проблему.
Я только что проверил другое веб-приложение, и его App_Code и App_Global скомпилированы в 'Any CPU', в то время как файлы этого проекта скомпилированы в 'x86', будь то в Visual Studio с прекомпиляцией в профиле публикации или в IIS после отключения прекомпиляции.

tuespetre · Answer 1 · 2014-08-27T15-15-00.000Z

После некоторого утомительного параллельного сравнения файлов.csproj и Web.config я решил, что следующий раздел в файле web.config был виновником:

  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" compilerOptions="/unsafe /platform:x86" warningLevel="1">
        <providerOption name="CompilerVersion" value="v4.0" />
        <providerOption name="WarnAsError" value="false" />
      </compiler>
    </compilers>
  </system.codedom>

После удаления этого раздела App_Code, App_GlobalResources и их родственники скомпилированы для "Любой процессор".

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