Изменения моего кода приложения ASP.NET не принимаются (или кэшируются ??) - PullRequest
Новая
       51

Изменения моего кода приложения ASP.NET не принимаются (или кэшируются ??)

7 голосов
/ 17 июня 2011

Помощь !! У меня есть один файл .cs в каталоге (корневой уровень) App_Code с целью получения правильного шаблона для запрошенного URL-адреса (он связан с нашей собственной базой данных управления контентом). Первоначально он работал нормально - я мог внести в него изменения, и они были подобраны веб-приложением. Потом что-то произошло (не знаю, что), и теперь, какие бы изменения я ни сделал, они не распознаются. Даже если я удаляю весь каталог App_Code, это не имеет значения - я все еще, кажется, выбираю более раннюю (кэшированную ??) версию того, что было в каталоге App_Code. Код в файле .cs ниже: 

using System;
using Custom.CMS.Facade;
using Custom.CMS.BO;
public class CMHttpModule : IHttpModule
{
    code here...
}

Та же проблема возникает даже после того, как я скопировал веб-сайт на наш действующий сервер.

Что я не понимаю, так это то, что если я ввожу преднамеренную ошибку в код .cs, я все равно получаю ошибку компиляции, и при успешной компиляции создается файл App_Code.xxxx.dll в папке C: \ WINDOWS \ Microsoft. NET \ Framework \ v2.0.50727 \ Временные файлы ASP.NET

Итак, какую версию App_Code на самом деле берет мое веб-приложение? Как заставить его подобрать «правильный»?

FYI Я использую C #, Visual Web Developer Express 2008 и IIS 6, веб-сервер

Буду признателен за любую помощь.

Ответы [ 6 ]

6 голосов
/ 18 апреля 2013

Повторное открытие решения также работает.

3 голосов
/ 31 июля 2012

Я не совсем уверен, как вы публикуете свое веб-приложение, но есть несколько вещей, которые вы можете попробовать:

  • Как упоминалось ранее, убедитесь, что вы используете ссылки на проекты вместо ссылок на файлы для библиотек DLL, которые создаются из ваших собственных проектов C #. Кроме того, убедитесь, что ваш файл .cs в каталоге App_Code имеет Build Action, установленный на Compile
  • Убедитесь, что все проекты ориентированы на одну и ту же среду .NET: v2.0, v3.5, v4.0 или v4.5. Вы можете проверить это на вкладке Application Properties каждого проекта. не используйте вариант профиля клиента.
  • В исходном коде удалите встроенные библиотеки DLL (обычно те, что находятся в папках bin и obj), а затем используйте Visual Studio для полной сборки. Это эквивалент Перестройки (читай: Очистить, затем Построить). Затем опубликуйте на своем веб-сервере.
  • С риском констатации очевидного убедитесь, что веб-браузер, который вы используете для просмотра своего сайта, очистил свой кэш до того, как вы зашли на него.

Надеюсь, это поможет.

РЕДАКТИРОВАТЬ: Просто внезапно подумал: действительно ли это веб-приложение ASP.NET веб-сайт ? Если это так, то изменения вашего кода могут не распознаваться Компилятор ASP.NET , потому что «если на файл кода нет ссылки, он не компилируется».

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

3 голосов
/ 25 июля 2012

Можете ли вы щелкнуть правой кнопкой мыши файл, перейти к свойствам и проверить действие сборки. Должно быть установлено значение «Компилировать».

1 голос
/ 31 июля 2012

@ SeanW -

1) Вы пытались изменить свой Web.Config вместо того, чтобы удалить его напрямую?Web.Config кэшируется, но любая его редакция должна перерабатывать ваш кэш приложений.

2) Вы пытались уничтожить весь свой сайт и скопировать его с нуля?(Особенно убедитесь, что вы удалили и скопировали все предварительно скомпилированные файлы в вашем каталоге bin.)

@ Patrick -

1) Вы пытались удалить все в вашем временном ASP.Каталог сетевых файлов?

2) Если у вас были изменения в зависимых проектах в вашем решении (не в вашем начальном проекте), вручную ли вы перестраивали эти зависимые проекты по отдельности?

3) У вас есть доступ?переработать пул приложений для вашего живого веб-сайта в IIS?

4) Вы пытались переписать свой живой веб-сайт с нуля или изменили Web.Config на своем живом веб-сайте?

Общие советы по кэшу приложений -

  • Вы можете часто обновлять кэш приложений, внося тривиальные изменения в файл Web.Config.

  • Как обсуждалось в , этот поток , изменения Global.asax, изменения каталога bin и изменения App_Code также могут вызывать обновление пула приложений.

  • В качестве долгосрочного решения выВозможно, вы захотите управлять своим кешем приложений с помощью файловой зависимости или SQLCacheDependency Class .(Хотя это последнее предложение может не работать на сайтах с общим хостингом, таких как GoDaddy.)

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

Вчера у меня была такая же проблема, и я исправил ее, убедившись, что ссылки на библиотеки классов в проекте веб-сайта указывают на ваши проекты библиотек классов (а не на dll в папке bin).

Похоже, что веб-сайт нацелен на .net 2.0, а библиотеки классов находятся в .net 3.5, так или иначе, проект веб-сайта проигнорировал восстановленные библиотеки DLL и использовал их в папке bin проекта веб-сайта.

0 голосов
/ 24 мая 2014

ASP.NET Web Application имеет несколько ловушек.Перезагрузка проекта - один из способов решения нескольких проблем ... Действительно, достаточно странно (назовите меня багом)!Лично я предпочитаю веб-сайты ASP.Net (вместо приложений) с функцией JIT Compilation .FMO, это более быстрый, легкий и простой способ поддерживать PRJ.

...