Подтвердить что ты не робот

FileNotFound пытается загрузить v14.0.0.0 из "Microsoft.VisualStudio.Web.PageInspector.Runtime"

У меня есть проект MVC, который работал отлично, пока я не обновил свою машину неделю назад. Теперь я получаю ошибку привязки при попытке запустить проект

Управляемый помощник по отладке "BindingFailure" обнаружил проблему в "C:\Program Files (x86)\IIS Express\iisexpress.exe".

Дополнительная информация: сборка с отображаемым именем "Microsoft.VisualStudio.Web.PageInspector.Runtime" не удалось загрузить в контексте привязки "LoadFrom" AppDomain с идентификатором 2. Причиной отказа был: System.IO. FileNotFoundException: Не удалось загрузить файл или сборку "Microsoft.VisualStudio.Web.PageInspector.Runtime, Version = 14.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" или одна из его зависимостей. Система не может найти указанный файл.

Если я продолжу ошибку, проект загрузится правильно. Однако, когда я запускаю проект как веб-роль в облачном сервисе, он не запускается, поскольку он продолжает выскакивать, поскольку роль занимает больше времени, чем ожидалось.... message

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

Кто-нибудь сталкивался с этим раньше?

ИЗМЕНИТЬ Я искал ссылку на сборку в файлах конфигурации, ничего не возникало. В конце концов я просто переустановил новый лазурный SDK. Сообщение об ошибке привязки с помощью pageinspector по-прежнему всплывает при загрузке, но если я продолжу проект, он отлично работает. На данный момент мне придется жить с этим досадным сообщением, пока не найду решение

4b9b3361

ОТВЕТЫ

Ответ 1

Я заметил, что это произошло на машине с установленной Visual Studio 2013.

это начало происходить, насколько я могу судить, после обновления VS2013 4.

(возможно, это произошло ранее, но это новое для моей среды)

Я разместил эту сборку в GAC (две версии, одна для VS2012, другая для VS2013), но эти версии имеют сильную именованную (очевидно) версию с версией 12.3.0.0 (обратите внимание, что вышеупомянутая ошибка разрешения для сборка версии "14".)

Вот стек вызовов для первого экземпляра этого конкретного исключения:

mscorlib.dll!System.Reflection.RuntimeAssembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly locationHint, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) + 0x23 bytes   
mscorlib.dll!System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly reqAssembly, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) + 0x99 bytes   
mscorlib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef) + 0x25 bytes   
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.GetRuntimeAssembly(out System.Reflection.Assembly runtime) + 0xdb bytes   
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.LoadRuntime() + 0x2a bytes    
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.PreApplicationStart() + 0x27 bytes    
[Native to Managed Transition]  
System.Web.dll!System.Web.Compilation.BuildManager.InvokePreStartInitMethodsCore(System.Collections.Generic.ICollection<System.Reflection.MethodInfo> methods, System.Func<System.IDisposable> setHostingEnvironmentCultures) + 0x142 bytes 
System.Web.dll!System.Web.Compilation.BuildManager.InvokePreStartInitMethods(System.Collections.Generic.ICollection<System.Reflection.MethodInfo> methods) + 0x5a bytes 
System.Web.dll!System.Web.Compilation.BuildManager.CallPreStartInitMethods(string preStartInitListPath, out bool isRefAssemblyLoaded) + 0x67 bytes  
System.Web.dll!System.Web.Compilation.BuildManager.ExecutePreAppStart() + 0x9a bytes    
System.Web.dll!System.Web.Hosting.HostingEnvironment.Initialize(System.Web.Hosting.ApplicationManager appManager, System.Web.Hosting.IApplicationHost appHost, System.Web.Configuration.IConfigMapPathFactory configMapPathFactory, System.Web.Hosting.HostingEnvironmentParameters hostingParameters, System.Security.Policy.PolicyLevel policyLevel, System.Exception appDomainCreationException) + 0x20a bytes   
System.Web.dll!System.Web.Hosting.HostingEnvironment.Initialize(System.Web.Hosting.ApplicationManager appManager, System.Web.Hosting.IApplicationHost appHost, System.Web.Configuration.IConfigMapPathFactory configMapPathFactory, System.Web.Hosting.HostingEnvironmentParameters hostingParameters, System.Security.Policy.PolicyLevel policyLevel) + 0x16 bytes 
[Appdomain Transition]  
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x12f3 bytes 
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x25 bytes    
System.Web.dll!System.Web.Hosting.ApplicationManager.GetAppDomainWithHostingEnvironment(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x6c bytes  
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateObjectInternal(string appId, System.Type type, System.Web.Hosting.IApplicationHost appHost, bool failIfExists, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x4d bytes   
System.Web.dll!System.Web.Hosting.ProcessHost.StartApplication(string appId, string appPath, out object runtimeInterface) + 0x18f bytes 
[Native to Managed Transition]

Это говорит о том, что проблема заключается в Microsoft (а не в том, что я сделал, например, в сборке, приложении или в машинной конфигурации.)

Я проверил все мои конфиги (буквально все, мой проект web.config, а также все конфигурационные файлы .NET, все версии/платформы), и я не смог найти ссылку на эту сборку в любом месте.

Чтобы обойти эту ошибку (которую Microsoft должна адресовать), я добавил привязку привязки сборки, как показано ниже, к моему web.config(НЕ с моими конфигурациями):

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.VisualStudio.Web.PageInspector.Runtime" publicKeyToken="b03f5f7f11d50a3a" />
    <bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="12.3.0.0" />
  </dependentAssembly>

Это предполагает, что Microsoft выпустила сборку Visual Studio или аналогичную, которая является обязательной для будущей, невыпущенной версии этих сборок.

Надеюсь, это поможет кому-то еще!

Ответ 2

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

Ответ 3

Вместо изменения файлов фреймов попробуйте добавить это в файл web.config:

<system.web>
    <httpRuntime targetFramework="4.5" />
        <compilation debug="true" targetFramework="4.5" >
          <assemblies>
            <remove assembly="Microsoft.VisualStudio.Web.PageInspector.Loader, 
               Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
          </assemblies>
        </compilation>
    ...
</system.web>

Ответ 4

Мы столкнулись с аналогичной проблемой, развернув сборки, сгенерированные ASP.NET, с машины разработчика в производственную среду (ссылаясь на сборки, сгенерированные для элементов управления .ascx и .aspx, которые скомпилированы во время выполнения).

Мы (хакерски) копируем и сохраняем такие сборки, созданные во время выполнения, из временных временных папок ASP.NET(например, "C:/Users/[USER]/AppData/Local/Temp/Temporary ASP.NET Files/" ) во избежание некоторой перекомпиляции при загрузке службы, чтобы повысить производительность. Однако использование сборок, скомпилированных на dev-машине, вводит зависимости к сборкам VisualStudio.

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

Убедитесь, что вы не выполняете такое неудобное использование сгенерированных ASP.NET сборок, и, вероятно, это исправит.