Ссылки на циркулярные файлы не допускаются
У меня возникла проблема в построении моего решения в 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. Я скучаю по тонкости?
17 ответов
Таким образом, кажется, что MasterPages вызывают больше проблем с ASP.NET 2.0. У меня были проблемы с ними раньше, а теперь, кажется, то же самое.
Я создал новую страницу без MasterPage, и она работала нормально. MasterPage буквально используется только для стиля. Позор.
Перемещено из:
http://ellisweb.net/2009/12/fixing-the-circular-file-references-are-not-allowed-error-in-asp-net/
Если у вас есть следующие настройки: /folder1/Control1.ascx > Ссылки Control2 /folder2/Control2.ascx > Ссылки Control3 /folder1/Control3.ascx Это означает, что dll folder1 будет ссылаться на dll folder2, которая снова будет ссылаться на dll folder1, вызывая "круговую ссылку на файл".
Это помогло мне сегодня; У меня была главная страница в корне, ссылающаяся на главную страницу в папке, которая ссылалась на другую страницу в корне. Перемешивать, какие страницы были, в каких папках работал шарм.
Я столкнулся с вашим постом, когда столкнулся с той же проблемой. Вероятно, существует миллион вариантов решения Циркулярной ссылки, но мое было прямым результатом Master Pages.
Я случайно создал страницу, используя вложенную главную страницу, вне вложенной папки. Пример:
Master1.Master
Page.aspx
(Folder1)
Master2.Master
В то время как Page.aspx ссылался на Master2.Master в качестве главной страницы, он работал нормально и выдает ошибку при публикации.
Я также столкнулся с этой проблемой и смог успешно выполнить публикацию из Visual Studio, выбрав "Использовать фиксированные имена и одностраничные сборки". По некоторым причинам это, кажется, избегает мысли компилятора, что есть круговая ссылка.
У меня была похожая проблема, и я получил точную подсказку от ответа @JBicford. Я использовал Default.aspx в корне сайта, используя Master.master в другой папке. Не знаю, может ли это быть причиной, еще не тестировали это решение.
Но для тех, кто заинтересован в решении проблемы с публикацией, нижеприведенная опция работает для VS 2012, все остальные опции не работают из-за неправильных зависимостей от других папок и страниц.
Я обнаружил, что получаю эту ошибку, когда Visual Studio пакетно компилирует страницы. Я смог решить эту проблему, установив batch="false" в элементе компиляции в web.config.
Чтобы быть более конкретным, я добавил web.config в каталог, в котором были страницы с проблемами. Этот файл web.config имеет только следующее содержимое:
<?xml version="1.0"?>
<configuration>
<system.web>
<!-- Added to prevent error ASPPARSE: Circular file references are not allowed. -->
<compilation batch="false" />
</system.web>
</configuration>
Таким образом, Visual Studio/MSBuild по-прежнему может пакетно скомпилировать другие не затронутые каталоги, если того пожелает.
Дополнительная информация об элементе компиляции и атрибуте пакета доступна по адресу msdn.
Для меня это было также регистрация страницы aspx на главной странице.
Например (на главной странице):
<%@ Register Assembly="MyPage" Namespace="MyPage" TagPrefix="MyPage" %>
...
<asp:ContentPlaceHolder id="MyPage" runat="server"></asp:ContentPlaceHolder>
А затем на странице aspx:
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true"
CodeFile="MyPage.aspx.cs" Inherits="MyPage" Title="Untitled Page" %>
<asp:Content ID="SomeContent" ContentPlaceHolderID="MyPage" Runat="Server">
Удаление реестра исправило это.
Для тех из вас, кто, как я, ходили по кругу с этим вопросом. Я полагаю, что у меня может быть другое решение - все остальное терпит неудачу. У нас была эта проблема с приложением MVC, и мы потратили несколько недель, пытаясь различные предложения безрезультатно.
Мы обнаружили, что у нас запущен McAfee Virus scanner V 8.0. мы обнаружили, что когда мы отключили сканер при доступе с консоли VirusScan, мы смогли собрать и отладить без проблем.
Единственное, что при отключении этого параметра он автоматически включается каждые 15 минут.
Я чувствовал, что этим стоит поделиться..
Спасибо декан
Изменить: это работает, только если у вас есть локальный доступ администратора к вашему компьютеру. С точки зрения безопасности существуют серьезные опасения по поводу отключения AV-сканеров (это справедливо). Фактически, если вы работаете в рабочей среде, контролируемой сетевым администратором, вы можете даже получить от них отпор. Я уверен, что есть другой способ сделать это, но сейчас это, кажется, работает для нас, но если я найду другой обходной путь (который является чистым для администратора), я поделюсь здесь.
Эта ошибка все еще существует в ASP.NET 4.0.
Я получил ошибку:
/DirA/PageA.aspx(3): error ASPPARSE: Circular file references are not allowed.
/DirA/PageA.aspx(71): error ASPPARSE: Unknown server tag 'Controls:ControlA'.
ControlA был тем же контролем, на который ссылается PageA.aspx(3). Я обнаружил, что мне пришлось переместить ControlA в тот же каталог, что и PageA, чтобы остановить эту ошибку.
У меня была эта проблема, но ни одно из предложений не сработало для меня, мое может быть уникальным случаем, но на случай, если другие люди столкнутся с той же проблемой:
Моя, казалось бы, не имела ничего общего с Circular References и был на самом деле из-за моего вывода сборки. Через некоторое время, когда я никуда не попал, я установил контрольную точку на элемент управления, который не мог быть загружен, и получил уведомление о том, что он не будет активирован.
Изменение свойств проекта и параметров конфигурации решения для Any CPU исправил проблему.
На самом деле, этот пост объясняет, почему это происходит и как это исправить: 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 в другой каталог, и да, ошибка исчезла!
Я испытываю это поведение, если у меня есть пользовательский элемент управления (ASCX), который включен в главную страницу.
Обычно я просто игнорирую ошибку, так как она исчезла после второй сборки.
У меня была такая же ошибка во время капитального ремонта. В моем конкретном случае это было потому, что я использовал папку "JUNK", куда я перетаскивал неиспользуемые или переименованные файлы. Моя папка нежелательной почты компилировалась, и файл, который я недавно удалил, вызывал эту проблему.
Я исправил это, исключив отдельный файл из папки нежелательной почты.
В большинстве случаев это происходит после копирования страниц aspx. Убедитесь, что ваш класс указан как Inherits="MyPage" не повторяется на всем сайте.
Для меня эти трюки не сработали
-setting batch=true -удаление временных файлов asp.net и сброс IIS-замена подозрительных ascx файлов
и проблема была в том, что я ссылался на недавно добавленный проект в моём решении и выгружал его после окончательной сборки. Удаление ссылки на эту добавленную библиотеку решило проблему
Еще одна проблема заключается в коде: MasterPageA: B => PageC: B => PageC использует MasterPageA . Возникает ошибка «Циклические ссылки на файлы не допускаются». Visual Studio не сообщает об ошибке в этих классах. Приходится проверять вручную.
Та же проблема с некоторым кодом, который я унаследовал.
У меня была проблема с файлом в папке app_data, но в нем было пространство имен MyControls. В итоге я переместил этот файл из папки app_data и создал новую папку "Мои элементы управления".