Откуда возникает ошибка CS0433 "Тип" X "в файлах A.dll и B.dll "?
Когда я запускаю веб-приложение из Visual Studio 2008 SP1, используя внутренний веб-сервер (не IIS), я получаю вышеупомянутую ошибку.
Полная ошибка (исходный файл Default.aspx.cs):
Сообщение об ошибке компилятора: CS0433: тип "WebApplication3.Site1" существует в обоих файлах: c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\aa563bcf\59deedc0\App_Web_site1.master.cdcab7d2.muczzy9v.dll'и'c:\Windows\Microsoft.NET\Framework\v2.0.50727\ Временные файлы ASP.NET \root\aa563bcf\59deedc0\assembly\dl3\44c3a3cf\80dd34ed_6968ca01\WebApplication3.DLL'
Предыдущее полное предупреждение:
Предупреждение: CS0436: тип "WebApplication3._Default" в "c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Временные файлы ASP.NET \root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'конфликтует с импортированным типом'WebApplication3._Default'в'c:\Windows\Microsoft.NET\Framework\v2.0.50727\ Временные файлы ASP.NET \ root \ aa563bcf \ 59deedc0 \ Assembly\dl3\44c3a3cf\e096e61c_6568ca01\WebApplication3.DLL. Используя тип, определенный в 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Временные файлы ASP.NET \root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs'.
Источник предупреждения указывает на промежуточный файл App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs:
Line 162:
Line 163: [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
Line 164: public class default_aspx : global::WebApplication3._Default, System.Web.IHttpHandler {
Line 165:
Line 166: private static bool @__initialized;
и мой вопрос: откуда это взялось?
Веб-приложение (не веб-сайт!) Имеет один Default.aspx и один Site1.Master, никаких зависимостей. Они почти пустые, с asp:Label на странице. Ранее это веб-приложение работало нормально. Когда я удаляю любые ссылки в Default.aspx.cs на мастера, все идет хорошо. Мастер имеет только некоторый код.
На самом деле это один из множества маленьких тестовых веб-приложений, которые меня устраивают, так что мне все равно. Но я не видел этого раньше, и теперь мне интересно, что делать, кроме копирования кода в новый проект (решение для очистки не помогает).
Примечание: я прочитал этот пост и некоторые другие, они не применяются.
28 ответов
теория
Когда эта проблема не вызвана ошибкой в приложении (например, повторяющееся имя класса):
Эта проблема возникает после изменения проекта приложения, который приводит к новой сборке (например, изменение кода / ссылки / ресурса). Проблема, по-видимому, заключается в выходных данных этой новой сборки: по разным причинам Visual Studio не заменяет все содержимое папок obj/bin вашего приложения. Это приводит к тому, что по крайней мере часть содержимого папки bin вашего приложения устарела.
Когда указанная проблема возникает, очистка папки "Temporary ASP.NET Files" сама по себе не решает проблему. Это не может решить проблему, потому что устаревшее содержимое папки bin вашего приложения копируется обратно в папку "Temporary ASP.NET Files" при следующем обращении к вашему приложению, вызывая проблему до сих пор. Ключ заключается в том, чтобы удалить все существующие файлы и заставить Visual Studio перестроить каждый объект, поэтому при следующем обращении к вашему приложению новые файлы bin будут скопированы в папку "Temporary ASP.NET Files".
Решение
- Закрыть Visual Studio
- Выполнить iisreset
- Удалите все папки и файлы в папке "Temporary ASP.NET Files" (путь указан в сообщении об ошибке)
- Удалите папки "obj" и "bin" вызывающего приложения
- Перезапустите Visual Studio и откройте решение
- Выполните "Чистое решение", а затем "Восстановить решение"
объяснение
- Шаги 1-2: удалите блокировки ресурсов из папок / файлов, которые нам нужно удалить.
- Шаги 3-4: удалить все старые файлы сборки
- Шаги 5-6: создайте новые версии файлов сборки
Выключите w3svc и удалите все из c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\
добавленной
в Windows 7
c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\на серверах IIS (64-разрядных) это также может произойти. Ищу:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root(замените v4.0.30319 версией фреймворка, который вы используете, если новее на вашем сервере)
Это может произойти, если вы поместите файлы.cs в App_Code и измените их действие сборки для компиляции в проекте веб-приложения.
Либо используйте действие сборки для файлов.cs в App_Code как Content, либо измените имя App_Code на другое. Я изменил имя, так как intellisense не исправит файлы.cs, помеченные как содержимое.
Более подробная информация на http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html
Посмотрите на тег Inherits всех ваших aspx-страниц и главных страниц. Скорее всего, есть два частичных класса с одинаковыми именами. Измените один и перекомпилируйте.
Вот еще немного информации:
http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx
При создании проекта ASP.NET с использованием Visual Studio вы можете случайно увидеть сообщение об ошибке, подобное следующему:
Сообщение об ошибке компилятора: CS0433: тип "ASP.summary_common_controls_notes_ascx" существует в обоих "c:\Windows\Microsoft.NET\Framework64\v2.0.50727\ временных файлах ASP.NET \Book_Details\abc12345\def8910\App_Web_msftx123.dll" и " c:\Windows\Microsoft.NET\Framework64\v2.0.50727\ Временные файлы ASP.NET \Book_Details\abc12345\def8910\App_Web_msfty456.dll'
Описание: во время компиляции ресурса, необходимого для обслуживания этого запроса, произошла ошибка. Пожалуйста, просмотрите следующие конкретные подробности ошибки и измените свой исходный код соответствующим образом.
Ошибка источника: строка 100: строка 101:
Новая строка примечаний 102:
Строка 103:
1450 строка 104:Резюме.
Исходный файл: d:\http\post\publisher\default.aspx Строка: 102
Общие сценарии, где эта ошибка может произойти, обсуждаются ниже
Сценарий 1
Описание. Распространенной причиной является наличие двух сборок в одной папке bin веб-приложения, содержащей два определения классов, но с одинаковым именем класса. Это может произойти, если в одну сборку было скомпилировано несколько файлов Default.aspx. Обычно это происходит, когда главная страница (Default.master) и страница ASPX по умолчанию (Default.aspx) оба объявляют класс _Default. Решение: Измените имя класса главной страницы (в большинстве случаев это _Default) и перестройте проект. Важно разрешить любой конфликт имен между классами.
Сценарий 2
Описание. Путь к ссылкам в Visual Studio используется для указания пути к папке для ссылок на сборки, используемых проектом. Возможно, что путь содержит сборку с тем же именем класса. Возможно, к одной сборке добавлено несколько ссылок (возможно, с другой версией или именем), что вызывает конфликт имен.
Решение: Удалить ссылку на старую версию. Для этого в Visual Studio щелкните правой кнопкой мыши свой веб-сайт и выберите "Ссылки" в свойствах.
Сценарий 3
Описание: по умолчанию при компиляции веб-приложения ASP.NET скомпилированный код помещается в папку временных файлов ASP.NET. По умолчанию права доступа предоставляются локальной учетной записи ASP.NET, которая имеет разрешения с высоким уровнем доверия, необходимые для доступа к скомпилированному коду. Возможно, что в разрешениях по умолчанию произошли некоторые изменения, которые привели к конфликтам версий. Другая возможность - антивирусное программное обеспечение может непреднамеренно заблокировать сборку. Решение: Очистите папку временных файлов ASP.NET от всего содержимого.
Сценарий 4
Описание: если для атрибута batch в файле web.config задано значение True, это устраняет задержку, вызванную компиляцией, которая требуется при первом обращении к файлу. ASP.NET предварительно компилирует все не скомпилированные файлы в пакетном режиме, что вызывает задержки при первой компиляции файлов. Отключение пакетной компиляции может привести к появлению маскированных ошибок компиляции, которые могут существовать в приложении, но о которых не сообщается. Однако, что более важно для этой проблемы, он говорит ASP.NET динамически компилировать отдельные файлы.aspx/.ascx в отдельные сборки, а не в одну сборку. Решение: установите batch=false в разделе в web.config. Это следует рассматривать как временное решение, так как установка batch=false в разделе компиляции оказывает значительное влияние на производительность для времени сборки приложения в Visual Studio.
Сценарий 5
Описание. Изменение файла web.config для приложения ASP.NET или изменение файла в папке bin (например, добавление, удаление или переименование) приводит к перезапуску AppDomain. Когда это происходит, все состояние сеанса теряется, и кэшированные элементы удаляются из кэша при перезапуске веб-сайта. Возможно, проблема вызвана несовместимым состоянием в веб-приложении. Решение. Запустите перезапуск домена приложения, коснувшись (отредактировав) файл web.config.
Сценарий 6
Описание: Вы можете сохранить исходный код в папке App_Code, и он будет автоматически скомпилирован во время выполнения. Полученная сборка доступна для любого другого кода в веб-приложении. Поэтому папка App_Code работает так же, как папка Bin, за исключением того, что в ней вы можете хранить исходный код вместо скомпилированного кода. Класс будет перекомпилирован при изменении исходного файла. Если существует конфликт из-за устаревшей сборки, то принудительная перекомпиляция может решить проблему. Решение. Коснитесь файла в папках Bin или App_Code, чтобы запустить полную перекомпиляцию.
У меня все еще была проблема после всех этих предложений. Некоторые классы внутри App_Code компилировались в две библиотеки DLL. Примерно так (упрощенно):
warning CS0436: The type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs'
conflicts with the imported type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\assembly\dl3\ea0aa3ee\6022e6d5_2cc8cf01\HCM.Web.Backoffice.DLL'.
Я просто переименовал папку "App_Code" в "Код". Это проект MVC5, поэтому проблем с обслуживанием файлов.cs внутри корня веб-проекта не должно быть.
Удаление файлов классов из App_Code папка, и размещение их прямо под сайтом, решило эту проблему для меня.
Это также может произойти, если у вас есть дубликат TagPrefix в вашем файле ASPX.
Это вызвало бы эту ошибку...
<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>
<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>
Вы можете исправить это, просто изменив 2-й "uc1" на "uc2"
Исправлена...
<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>
<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>
"Чистое решение", за которым следует "Перестроить решение", похоже, тоже исправляет это.
Это может произойти, если одно и то же имя класса указано в нескольких .aspx.cs файлы, т.е. когда две страницы создаются с разными именами файлов, но по ошибке имеют одинаковые имена классов.
// file a.aspx
public partial class Test1: System.Web.UI.Page
// file b.aspx
public partial class Test1: System.Web.UI.Page
При создании веб-приложения это дает предупреждение, но приложение работает, однако, после публикации приложение больше не работает и выдает исключение, как упомянуто в вопросе OP.
Убедиться в том, что два имени класса не перекрываются, решает проблему.
Чтобы устранить двусмысленность, вы можете определить псевдоним для одного из элементов ссылки.
В вашем целевом файле проекта.csprojдобавить следующий пункт:
<ItemGroup>
<Reference Include="WebApplication3.Site1">
<Aliases>MyAssembly</Aliases>
</Reference>
</ItemGroup>
Затем вы можете использоватьWebApplication3.Site1следующим образом:
using MyAssembly;
Я нашел еще одну причину: разные версии используются для значков на панели инструментов и ссылок в проекте. После вставки объектов в какой-либо форме началась ошибка.
Это случилось со мной из-за ошибки в моем Web.Config
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
Sytem.Web.Helpers было указано 1.0.0.0 вместо 3.0.0.0 (MVC 3 используется в этом проекте).
Поскольку IIS не смог найти ссылку в локальной папке, он посмотрел в GAC и обнаружил две разные версии. После указания на правильную ссылку IIS нашел локальную DLL и использовал ее вместо поиска в GAC.
Я закончил тем, что изменил способ ссылки на MasterType в разметке страницы.
Я изменился: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %>в <%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>
Смотрите здесь для деталей.
Надеюсь, это поможет кому-то.
Помимо попытки ответить 2Toad, мне также пришлось закрыть Visual Studio и удалить папку.vs. После этого все построилось правильно.
Между прочим, ошибка, с которой я столкнулся, вообще не указывала мою папку Temp, а ссылалась на что-то еще, что явно было сгенерировано системой. Я не позаботился о сохранении конкретной ошибки:\
В нашем случае причиной была разница в.dll-версиях сайтов в IIS. Они помещены друг в друга в IIS, что позволяет вам получить доступ к другому через поддомен. Он унаследован от первого файла web.config, и в сочетании с другим файлом web.config произошел сбой, поскольку он имеет разные версии mvc.dll.
По крайней мере, для меня это произошло, когда я удалил ссылку на сборку и добавил ссылку на более новую версию с другим именем. В этом случае кажется, что старая сборка осталась в папке bin и obj и не была удалена с помощью операции чистого решения из Visual Studio (возможно, потому что она больше не является частью проекта). В этом случае достаточно было удалить содержимое папок bin и obj проекта, в котором произошла ошибка, из проводника Windows (или инструмента управления файлами). Затем из Visual Studio очистите решение и восстановите его.
У меня была та же проблема с двумя элементами управления ascx, имеющими одно и то же имя класса:
Control1: <% @ Control Language = "C#" ClassName = " myClassName" AutoEventWireup = "true...> Control2: <% @ Control Language =" C# "ClassName =" myClassName"AutoEventWireup =" true...>
Я исправил это, просто переименовав имя класса:
Control1: <% @ Control Language = "C#" ClassName = " myClassName1" AutoEventWireup = "true...> Control2: <% @ Control Language =" C# "ClassName =" myClassName2"AutoEventWireup =" true...>
Для этого есть множество причин. И большинство из упомянутых выше применимо к различным сценариям. Что я заметил, так это то, что ошибка возникает ТОЛЬКО, когда для аутентификации установлено что-то другое, кроме "Нет" Для моих целей тестирования я отключу это, и оно работает.
У меня была похожая проблема. Это мое решение: поставить изолированные классы, которые требуют свойства [Build Action] установить как [Compile] в любую папку, кроме App_Code лайк Application_Code так как App_Code папка будет скомпилирована как отдельная сборка, с тем же классом, скомпилированным в 2 сборках.
Закройте Решение и снова откройте его, затем проверьте ссылки проектов на удвоение:
Это может произойти, если вы использовали NuGet и изменили расположение ссылки на DLL. Чтобы исправить это, вы должны вручную отредактировать файл proj, удалив записи, например:
<Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />
Обратите внимание, что эти ссылки
Если никакое другое решение не помогло, просто переименуйте наследуемый класс этой проблемы, вызывая файл aspx и файл aspx.cs, на новое имя, а затем перестройте решение. тогда вопрос обязательно будет решен. это сработало только для меня.
например:
в файле aspx сделайте следующее: измените имя наследуемого класса на Defaultnew
<%@ Page Title="" Language="C#" MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>
в файле aspx.cs переименуйте класс в тот же, что и в файле aspx
using System;
using System.Collections.Generic;
using System.Web;
public partial class Defaultnew : System.Web.UI.Page
{
Я конвертирую старый веб-сайт asp.net (v 1 или 2) для работы под.net 4.5 в качестве веб-приложения.
Мое решение состояло в том, чтобы переместить делегаты обработчика событий пользовательского элемента управления, которые вызывали проблему, в отдельный физический файл:
//move this line to a new physical file:
public delegate void LocationSearchedEventHandler( object sender );
public partial class controls_Drives_LocationAddPanel : UserControl
{
public event LocationAddedEventHandler LocationAdded;
protected virtual void OnLocationAdded(LocationAddEventArg e)
{
Сверхбыстрое и удобное решение состоит в том, чтобы злоупотреблять невероятной интеллигентностью Visual Studio, временно ссылаясь на класс где-то.
Пример:
System.Runtime.CompilerServices.ExtensionAttribute x = null;
При построении или наведении курсора на линию вы можете увидеть следующую ошибку:
"System.Runtime.CompilerServices.ExtensionAttribute" существует в обоих каталогах "C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll".
Это говорит вам о двух источниках, вызвавших конфликт немедленно.
System.Core.dll это файл.dll, который вы хотите сохранить, поэтому удалите другой.
Я нашел мой, сидящий в bin каталог, но это может быть в другом месте в проекте.
На самом деле это стоит иметь в виду, потому что, так как bin каталог может быть не включен как часть набора изменений TFS, он может объяснить, почему проверка ваших изменений не решает проблему для других членов вашей команды.
Меня перенаправили сюда при нажатии на первое обращение Google при нажатии на URL-адрес ошибки для CS0433, в частности,
The type 'Package' exists in both 'Windows... Version=N.N.N.N, Culture=neutral, PublicKeyToken=null, ContentType=Windows...' and 'Windows..., Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=Windows...'
Вместо того, чтобы описывать все, что я сделал, чтобы исправить это, позвольте мне рассказать вам, что я сделал, что сломало его. Я пошел обновить пакеты NuGet для репозитория, который нуждался в обновлении кода. Пакеты были довольно старыми (1 год или около того), и все, что я изначально пытался сделать, это обновить их для проекта C#.
В какой-то момент между запуском этого процесса и появлением этой ошибки я каким-то образом понизил версию проектов C++ в этом SLN, чтобы 15063. Я также заметил, что в проекте C# есть какTargetPlatformMinVersion а также TargetPlatformVersion недавно установлен на 10.0.17134.0
Единственное, что мне нужно было сделать, чтобы "исправить" это, - это изменить TargetPlatformMinVersion к более высокой версии, чем TargetPlatformMinVersionдля проекта C#. Изменение проекта C++ на любую версию не изменило поведения. Я не уверен, почему это внезапно перестало работать, но, надеюсь, кто-то так же заблокированный может выйти из рассола, используя аналогичные стратегии.
Закройте Visual Studio и очистите папки bin и obj в каталоге вашего проекта.
Идти к web.config
в <compilation добавлять batch="false"
это должно решить проблему
Да, возникла та же проблема и была решена путем изменения наследования кода C# и тега страницы в aspx