Ссылки на циркулярные файлы не допускаются

Question

У меня проблема с построением решения в VS2008. Обычно он прекрасно компилируется в среде. Иногда происходит сбой с:

/xxx_WEB/secure/CMSManagedTargetPage.aspx(1): error ASPPARSE: Circular
file references are not allowed.

Я перестраиваюсь и все работает нормально.

Однако сейчас я нахожусь в процессе настройки системы CruiseControl.NET и тестирую свой проверенный код с помощью MSBuild, прежде чем интегрировать сборку в CC. Теперь, каждый раз, когда я MSBuild, я получаю:

"Q:\cc\xxx\checked out from svn\xxx.sln" (default target) (1) ->
(xxx_WEB target) ->
  /xxx_WEB/secure/CMSManagedTargetPage.aspx(1): error ASPPARSE: Circular
file references are not allowed.

Проблема в том, что я не вижу, где эта ссылка.

• Я искал ссылку по всему решению и не могу найти никаких ссылок на саму страницу (CMSManagedTargetPage) нигде, кроме как на странице или в ее коде, или внутри строки, например:

  C: \ dev2008 \ xxx \ IWW.xxx.ASPNET \ AspxHttpHandler.cs (82): inputFile = context.Server.MapPath ("~ / secure / CMSManagedTargetPage.aspx"); C: \ dev2008 \ xxx \ IWW.xxx.ASPNET \ AspxHttpHandler.cs (83): virtualPath = "~ / secure / CMSManagedTargetPage.aspx";

Мои ссылки на сборки также хороши (насколько я знаю). Мое веб-приложение находится на «вершине» зависимостей, и ничто не ссылается на него, и поэтому неисправная страница не может вызвать циклическую ссылку. Конечно, сама страница может ссылаться на что-то вроде UserControl в той же сборке / веб-сайте, но, как упоминалось ранее, поиск по CMSManagedTargetPage не дал результатов, поэтому этого не происходит.

Изменение атрибута пакета в web.config не повлияло на MSBuild.

Мне показалось очень странным, что «иногда» происходит сбой в VS и всегда происходит сбой в MSBuild. Мне не хватает какой-то тонкости?

Answer 1

Собственно, этот пост объясняет, почему это происходит и как это исправить: http://www.gitshah.com/2011/04/how-to-fix-circular-file-references-are.html

Как исправить «круговые ссылки на файлы не допускаются» Ошибка в ASP.Net

В одном из моих проектов .Net я столкнулся с интересной проблемой. Я потратил пару часов, чтобы починить его. Поэтому я решил поделиться своими выводами, чтобы другим не пришлось тратить свое время на решение той же проблемы.

выпуск

Проблема была довольно простой, приложение не собиралось. Ошибка, которую я получал при создании веб-проекта ASP.Net с использованием MSBuild: /someProject/Controls/A/ucA.ascx(2): ошибка ASPPARSE: ссылки на циклические файлы не допускаются.

Конечно, ошибка говорит, что в моем коде есть какая-то круговая ссылка. Я оглянулся вокруг, чтобы проверить и перепроверить, если я создал круговую ссылку по ошибке. Однако, если бы была какая-либо циклическая ссылка, код не компилировался бы. Код компилировался нормально, но не получалось, когда мы запускали aspnet_compiler.exe.

Средство компиляции ASP.Net (aspnet_compiler.exe) позволяет скомпилировать веб-приложение ASP.Net, что способствует повышению производительности приложения, поскольку конечные пользователи не сталкиваются с задержкой при первом обращении к приложению.

Я проверил еще раз, но, конечно, не было циклической зависимости, связанной с кодом, тогда почему aspnet_compiler.exe жаловался на ссылки на циклические файлы?

Объяснение

Немного погуглив, я обнаружил, что по умолчанию в проекте веб-сайта ASP.Net создает одну DLL на папку. Следовательно, если у вас есть следующие настройки:

Пользовательский элемент управления ucA.ascx присутствует в каталоге «А». ucA.ascx ссылается на другой пользовательский элемент управления ucB.ascx Пользовательский элемент управления ucB.ascx присутствует в каталоге «B». ucB.ascx ссылается на другой пользовательский элемент управления ucC.ascx Пользовательский элемент управления ucC.ascx присутствует в каталоге «A».

DLL папки A будет ссылаться на DLL папки B, которая снова будет ссылаться на DLL папки A, вызывая «циклическую ссылку на файл».

Это причина, по которой aspnet_compiler.exe завершается с ошибкой «циклическая ссылка на файл».

Исправление

Существует два способа устранения этой проблемы

Перестановка пользовательских элементов управления (или MasterPages) для удаления циклических ссылок. Обычно это означает перемещение пользовательских элементов управления в отдельные каталоги. В нашем примере перемещение ucC.ascx в новый каталог «C» (Preferred Solution). Используйте batch = ”false” в теге компиляции файла web.config. Это приведет к созданию новой библиотеки DLL для каждого элемента управления / страницы сайта. Это должно исправить ошибку, но очень плохо для производительности, поэтому ее следует избегать.

Я переместил ucC.ascx в другой каталог, и да, ошибка исчезла!

Answer 2

В большинстве случаев это происходит после копирования страниц aspx. Убедитесь, что ваш класс, указанный как Inherits="MyPage", не повторяется на всем сайте.

Answer 3

Та же проблема с некоторым унаследованным кодом.

Моя проблема была в том, что у меня был файл в папке app_data, но в нем было пространство имен MyControls. В итоге я переместил этот файл из папки app_data и создал новую папку «Мои элементы управления».

Answer 4

У меня была такая же ошибка во время капитального ремонта разработки. В моем конкретном случае это было потому, что я использовал папку «JUNK», куда я перетаскивал неиспользуемые или переименованные файлы. Моя нежелательная папка компилировалась, и файл, который я недавно удалил, вызывал эту проблему.

Я исправил это, исключив отдельный файл из папки нежелательной почты.

Answer 5

у меня эти трюки не сработали

-установка партии = истина удаление временных файлов asp.net и сброс IIS замена подозрительных файлов ascx

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

Answer 6

Так что кажется, что MasterPages вызывает больше проблем с ASP.NET 2.0. У меня были проблемы с ними раньше, а теперь, похоже, то же самое.

Я создал новую страницу, без MasterPage, и она работала нормально. MasterPage буквально используется только для стиля. Позор.