Ошибка ASP.Net: "Тип" foo существует как в "temp1.dll", так и в "temp2.dll" (pt 2)
Решение:
Я также перемещал файлы ashx и asmx одновременно с этим. Атрибут Class в директивах WebService/WebHandler указывался на неправильное пространство имен. Мораль этой истории состоит в том, чтобы убедиться, что вы просмотрите разметку для файлов all as*x
, которые вы меняете пространство имен, щелкнув их правой кнопкой мыши и выбрав "Просмотр разметки".
Я испытываю ту же проблему, что и в этот вопрос и эта ссылка, но ни один из ответов не устранил мою проблему. (edit: настройка атрибута партии web.config работает, но это закрытие, а не решение)
Проблема, с которой я столкнулась, - это элемент управления пользователя, который я переместил из корневого каталога в подкаталог в рамках одного и того же проекта веб-приложения. Раньше он работал нормально, прежде чем я его перевел. Когда я переместил его, он начал давать мне сообщение об ошибке.
Говорят, что имя класса существует в двух файлах dll в Temporary ASP.NET Files. Конечно, когда я открываю Reflector, это в двух DLL.
Если я переименую файл класса и ascx, все будет хорошо. В любом из файлов во всем моем приложении не существует никаких исходных названий. Когда я переименую файл, я открыл все файлы dll в Temporary ASP.NET Files с Reflector, и никаких ссылок на исходное имя класса не существует.
Итак, откуда эта ссылка phantom, откуда я могу это исправить?
Обновление: я буквально grepped каждый файл в моей рабочей директории для решения и мой каталог temp для старого имени класса и удалял каждый файл, который содержал его. Затем я переименовал обратно в исходное, сломанное имя, и я все еще получаю ошибку.
Ошибка сервера в приложении "/". Ошибка компиляции: ошибка во время компиляции ресурса, необходимого для обслуживания этого запрос. Просмотрите следующие конкретные сведения об ошибках и исходный код.
Ошибка компилятора: CS0433: Тип 'ASP.dashboard_badusercontrol_ascx' существует как в c:\Docunts, так и в Настройки\я\Local Настройки \Temp\Temporary ASP.NET Файлы\корень\3c2b7e1f\2e8a7620\App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll" и 'c:\Docunts и Settings\me\Local Настройки \Temp\Temporary ASP.NET Файлы\корень\3c2b7e1f\2e8a7620\App_Web_bhdqaimy.dll '
Ошибка источника:
Линия 1098: Строка 1099:
[System.Diagnostics.DebuggerNonUserCodeAttribute()] Строка 1100: конфиденциальная глобальный:: ASP.dashboard_badusercontrol_ascx @__ BuildControlMyBadUserControl() { Строка 1101:
глобальный:: ASP.dashboard_badusercontrol_ascx @__ctrl; Строка 1102:
Исходный файл: c:\Docunts и Настройки\я\Local Настройки \Temp\Temporary ASP.NET Файлы\корень\3c2b7e1f\2e8a7620\App_Web_foo.aspx.a57ad085.1nw6dais.0.cs Линия: 1100
Изменить:
Хорошо, поэтому я сделал еще несколько тестов на то, что работает и не работает.
Скажем, исходное имя файла было "BadUserControl.ascx" в пространстве имен "MyNamespace".
Я переместил файл в каталог под названием "NewDirectory" и изменил пространство имен на "MyNamespace.NewDirectory". На моем жестком диске нет копий "BadUserControl.ascx" в другом месте. Я дважды проверял историю TFS, чтобы обеспечить ТОЛЬКО разницу в добавлении ".NewDirectory" к пространству имен в файлах разметки и кода.
Внутри этого пространства имен находятся два других пользовательских элемента управления с именем "OtherUserControl" и "AnotherUserControl".
Эта ситуация не выполняется:
У меня есть 2 директивы реестра:
<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
Эти ситуации работают:
-
Я сохраняю "BadUserControl.ascx" с именем as is.
У меня есть директива 1 Register на странице в том же пространстве имен:
<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>
-
Я меняю "BadUserControl.ascx" на "GoodUserControl.ascx"
У меня есть 2 директивы реестра:
<%@ Register src="GoodUserControl.ascx" tagname="GoodUserControl" tagprefix="uc1" %>
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
-
2 Регистрируйте директивы без BadUserControl.ascx:
<%@ Register src="AnotherUserControl.ascx" tagname="AnotherUserControl" tagprefix="uc1" %>
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
Ответы
Ответ 1
UPDATE: ok, как вы нашли, круговая ссылка была неправильной догадкой, так как есть другая ситуация, которая может вызывать подобное поведение.
Более общий способ описания проблемы заключается в том, что пакетная обработка во время выполнения работает очень разрешительно, что может маскировать проблемы. В принципе, мы пытаемся выполнить все в одной папке, но если мы получим ошибку компиляции при компиляции этой партии, мы возвращаемся к отдельной компиляции файлов. Во многих случаях это работает нормально, но иногда это может привести к тому, что заданная страница будет скомпилирована дважды (как описано ниже, но по другой причине).
С другой стороны, aspnet_compiler работает строгим образом, где, если пакетная обработка завершается с ошибкой, она терпит неудачу и не отступает. Поэтому запуск этого инструмента - отличный способ найти различные типы проблем (или скрытые проблемы), которые могут быть далеки от очевидности во время выполнения. Думаю, мы не очень хорошо евангелизировали этот инструмент для этой цели:)
Что касается того, почему переименование файла было исправлено, это может быть вызвано изменением порядка обработки файлов, что является немного произвольным. Возможно, если вы переименуете его в нечто другое, вы увидите, что это произойдет снова.
Откровенно говоря, оглядываясь назад, я как бы пожелал, чтобы мы сделали это поведение дозирования строгим во время выполнения, чтобы поймать эти ситуации раньше. Причина, по которой мы выбрали текущий дизайн назад, заключалась в том, чтобы избежать сбоев, когда это было возможно, но это произошло с ценой: когда что-то не так, это боль, чтобы ее поймать:)
ОРИГИНАЛЬНЫЙ ОТВЕТ:
Короче говоря, проблема заключается в том, что при включении пакетной обработки (и по умолчанию) вам следует избегать использования круговых зависимостей на уровне каталога. Позвольте мне объяснить, что я имею в виду.
Вот пример. Скажите, что у вас есть:
- В папке1: page.aspx и uc2.ascx
- В forder2: uc1.ascx
И скажите, что page.aspx ссылается на uc1.ascx(через директиву @register) и что uc1.ascx ссылается на uc2.ascx. На уровне файла это прекрасно, но на уровне каталога существует циклическая зависимость: folder1 ссылается на что-то в папке2, которая ссылается на что-то в папке1.
Почему это проблематично в том, как работает пакетная обработка: когда вы запрашиваете страницу, она сначала пытается скомпилировать все в папке1 вместе. Но так как folder1/page.aspx ссылается на папку2/uc1.ascx, ему необходимо скомпилировать папку2, прежде чем она сможет сделать папку1. Но тогда uc1 использует uc2, то есть он должен сначала сделать folder1! На этом этапе ASP.NET обнаруживает ситуацию и пытается сделать все возможное, компилируя uc2.asc самостоятельно. Хотя это позволяет некоторым сценариям работать, это также может вызывать странные вещи, потому что некоторые элементы заканчиваются компиляцией в двух сборках. Здесь uc2.ascx будет скомпилирован сам по себе и с пакетом folder1.
На самом деле есть способ легко определить, имеет ли ваш сайт такие круговые зависимости уровня папки. В окне консоли VS перейдите в корень вашего сайта и запустите:
aspnet_compiler -v foo -p .
Если у вас есть круговые зависимости уровня папки, вы получите некоторые ошибки, которые выглядят следующим образом:
/foo/Sub/UC1.ascx(2): error ASPPARSE: Circular file references are not allowed.
Дешевый способ избежать этой проблемы - это то, что вы уже знаете: отключить дозирование. Теперь, по крайней мере, вы знаете, почему это работает:)
Но лучше всего сделать, если вы можете, это избежать круговых зависимостей уровня папки. Если вы начинаете думать о каждой папке как о "компоненте, который создает сборку, это действительно имеет смысл и может помочь сделать части вашего сайта более модульными".
Да, также справедливо назвать это "ошибкой в системе компиляции или, по крайней мере, ограничением". Но как только вы узнаете об этом, его довольно легко избежать.
Ответ 2
Очистить Temporary ASP.NET Files
. Может быть, контроль перед перемещением имеет сборку, а после - еще один
Ответ 3
Эта ошибка возникает из-за пространства имен. Проверьте пространство имен для всех файлов, чтобы убедиться, что ошибка ошибки дублирования или ошибки пространства имен отсутствует.
Ответ 4
Я иногда получаю это с помощью моих веб-пользователей. Они будут жаловаться, что они существуют два раза, когда я редактирую другой файл. Я не знаю, что это за сумасшествие, но я знаю, что если я нажимаю пробел > сохраняя жалобы, он заставляет сервер перекомпилировать и после этого он отлично работает.
Ответ 5
Есть ли в вашем решении более одного проекта?
Попробуйте очистить папку /bin (вручную). Возможно, старый файл сборки все еще сохраняется где-то, что мешает вам строить...
Кроме того, взгляните на свои ссылки - возможно, вы дублируете определение того, на что вы ссылались?
Это дикий снимок - но, возможно, у вас есть .dll, установленный в GAC?
Ответ 6
Я думаю, что некоторые из этих ответов, возможно, были безрезультатными. Я видел это, когда ваш код ссылается на другую версию сборки, чем ваш web.config. например:.
(версия 1.1.0.0 указана в aspx и 1.2.0.0, на которую ссылается в web.config)
MyFile.aspx
<%@ Register TagPrefix="cc1" Namespace="StrongNamed.Namespace" Assembly="StrongNamed, Version=1.1.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" %>
web.config:
<assemblies>
<add assembly="StrongNamed, Version=1.2.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
...
Я видел случаи, когда если обе версии сборки находятся в GAC, ASP.NET даст вам описанную вами ошибку.
Ответ 7
- Закройте все экземпляры Visual Studio.
- Остановить IIS (если он запущен, в противном случае остановите действие "devserver" )
- Очистить папку файла ASP.NET Temp (полностью)
- Очистить папку BIN
- Запустите IIS (если выполняется)
- Запустить VS
- Реконструкция
Ответ 8
С большим количеством проектов и папок иногда бывает, что пространство имен перепутано, особенно если вы пытаетесь заставить вещи с помощью объявлений пространства имен.
Чтобы убедиться, что это действительно проблема, я просмотрел все свои файлы кода -.cs и .designer.cs - и удалил ВСЕ объявления пространства имен, а затем перестроил все, чтобы узнать, устраняет ли это проблему.
Вы не указываете, какую версию Visual Studio и .net вы используете, что тоже может помочь - я помню, что рассматриваю аналогичную проблему в VS2005.
Ответ 9
Я столкнулся с этой проблемой хотя бы дважды.
Ответ Дэвида Эббо определенно объясняет, что происходит.
В моем проекте я создал пользовательский элемент управления, который я динамически вставил в placeholder.
Таким образом, код для элемента управления будет выглядеть примерно так:
public partial class CustomerAppointmentList : System.Web.UI.UserControl
{
}
Обратите внимание, что этот элемент управления не находится в каком-либо пространстве имен.
В коде позади "customer.aspx.cs" я загружаю этот пользовательский контроль динамически:
{
var contentControl = (CustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");
}
Поскольку класс "CustomerAppointmentList" не существует на странице aspx, я должен ссылаться на него в моем custmer.aspx:
<%@ Reference Control="../controls/customerappointmentlist.ascx" %>
Когда компилятор asp.net должен скомпилировать customer.aspx, он будет проходить через класс CustomerAppointmentList и добавит его в библиотеку для этой папки.
Через несколько секунд компилятор asp.net добавит класс CustomerAppointmentList в другую библиотеку для "элементов управления" папки.
После добавления интерфейса "ICustomerAppointmentList" во внешнюю библиотеку (projectname.web.dll) и внесения изменений в код проблема исчезла.
Итак:
- Удалить часть "Ссылка" в вашем файле aspx.
- Создайте интерфейс для вашего пользовательского элемента управления.
- Убедитесь, что класс CustomerAppointmentList наследуется от пользовательского элемента управления.
- При использовании LoadControl отбрасывайте только что созданный интерфейс.
Мой новый код (ascx.cs):
public partial class CustomerAppointmentList : System.Web.UI.UserControl, ICustomerAppointmentList
{
}
(aspx.cs)
{
var contentControl = (ICustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");
}
Ответ 10
Попробуйте удалить все файлы и папки в папке "Временные файлы ASP.Net", по этому пути:
c:\windows\Microsoft.NET\Framework\v2.0.50727\Временные файлы ASP.NET
это сработало для меня
Ответ 11
Для меня это произошло, когда у меня было установлено мое расположение PrecompiledWeb/Publish в текущем каталоге, в котором находилась корневая папка сайта.
Затем мой веб-сайт видел папку публикации как часть проекта при компиляции/создании, а затем поиск дубликатов таким образом.
то есть. Не помещайте опубликованную версию своего сайта в свои папки кода сайта.
Ответ 12
- Прежде всего вы должны использовать vs 2013 для этой проблемы.
- Во-вторых, это ошибка, потому что файл с расширением
.dll
и таким образом отображается в браузере
Ошибка компилятора ssage: CS0433: Тип "ASP.dashboard_badusercontrol_ascx" существует как в "c:\Docunts, так и в Настройки\me\Локальные настройки\Temp\Временный ASP.NET Файлы\корень\3c2b7e1f\2e8a7620\App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll" и 'c:\Документы и настройки\me\Локальные настройки\Temp\Временный ASP.NET Файлы\корень\3c2b7e1f\2e8a7620\App_Web_bhdqaimy.dll '
Поэтому вы должны удалить тот файл, который отображается с этой ошибкой. (App_Web_bhdqaimy.dll)