Откуда возникает ошибка 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 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Предыдущее полное предупреждение:

Предупреждение: CS0436: тип 'WebApplication3._Default' в 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs 'конфликтует с импортированным типом' WebApplication3._Default 'в' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL '. Используя тип, определенный в 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ 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 на мастер, все идет хорошо. У мастера есть только код.

На самом деле это одно из многих небольших тестовых веб-приложений, которые можно запустить и забыть, так что мне все равно. Но я этого раньше не видел, и теперь мне интересно, что делать, кроме копирования кода в новый проект (чистящее средство не помогает).

Примечание: я прочитал этот пост и некоторые другие, они не применяются.

Теория

Если эта проблема не вызвана ошибкой в ​​приложении (например, повторяющимся именем класса):

Эта проблема возникает после того, как в проект приложения внесены изменения, которые приводят к новой сборке (например, изменение кода / ссылки / ресурса). Проблема, по-видимому, связана с выходными данными этой новой сборки: по разным причинам Visual Studio не заменяет все содержимое папок obj / bin вашего приложения. Это приводит к тому, что по крайней мере часть содержимого папки bin вашего приложения устаревает.

При возникновении указанной проблемы очистка папки «Временные файлы ASP.NET» сама по себе не решает проблему. Это не может решить проблему, потому что устаревшее содержимое папки bin вашего приложения копируется обратно в папку «Temporary ASP.NET Files» при следующем доступе к вашему приложению, в результате чего проблема сохраняется. Ключ состоит в том, чтобы удалить все существующие файлы и заставить Visual Studio перестроить каждый объект, чтобы при следующем доступе к вашему приложению новые файлы bin будут скопированы в папку «Временные файлы ASP.NET».

Решение

1. Закройте Visual Studio
2. Выполните iisreset
3. Удалите все папки и файлы в папке «Временные файлы ASP.NET» (путь указан в сообщении об ошибке)
4. Удалите папки "obj" и "bin" проблемного приложения.
5. Перезапустите Visual Studio и откройте решение.
6. Выполните «Чистое решение», а затем «Восстановите решение»

Объяснение

• Шаги 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

После всех этих предложений у меня все еще была проблема. Какой-то класс внутри 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» в «Code». Это проект MVC5, поэтому проблем с обслуживанием файлов .cs внутри корня веб-проекта быть не должно.

Удаление файлов классов из App_Codeпапки и размещение их непосредственно под веб-сайтом решило эту проблему для меня.

Это также может произойти, если у вас есть дубликат TagPrefix в вашем файле ASPX.

Это вызовет эту ошибку ...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>

Вы можете исправить это, просто изменив второй «uc1» на «uc2».

Исправлена...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>

Справка : https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

При создании проекта ASP.NET с помощью Visual Studio вы можете случайно увидеть сообщение об ошибке, подобное приведенному ниже:

Сообщение об ошибке компилятора: CS0433: тип 'ASP.summary_common_controls_notes_ascx' существует как в 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' и ' c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ 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

Описание: Когда для атрибута пакета в 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, чтобы запустить полную перекомпиляцию.

Это случилось со мной из-за ошибки в моем 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.

Это может произойти, когда одно и то же имя класса указано в нескольких .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.

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

Я нашел другую причину: разные версии, используемые для значков в панели инструментов и ссылок в проекте. После вставки объектов в какую-то форму началась ошибка.

«Чистое решение», за которым следует «Восстановить решение», похоже, тоже исправляет.

Я закончил тем, что изменил способ ссылки на MasterType в разметке страницы.

Я изменил: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> на<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Смотрите здесь .

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

По крайней мере, для меня это произошло, когда я удалил ссылку на сборку и добавил ссылку на ее более новую версию, у которой было другое имя. В этом случае кажется, что старая сборка осталась в папке bin и obj и не была удалена с помощью операции чистого решения из Visual Studio (возможно, потому, что она больше не является частью проекта). В этом случае достаточно было удалить содержимое папок bin и obj проекта, в котором произошла ошибка, из проводника Windows (или инструмента управления файлами). Затем из Visual Studio очистите решение и перестройте его.

В нашем случае причина заключалась в различии между версиями .dll и сайтами в IIS. Они размещаются друг под другом в IIS, что позволяет вам получить доступ к другому через поддомен. Он унаследован от первого web.config, и, объединив его со следующим web.config, он потерпел неудачу, имея разные версии mvc.dll.

У меня была аналогичная проблема. Это мое решение: поместите изолированные классы, для которых требуется [Build Action]набор свойств, как [Compile]для любой папки, кроме App_Codeкак, Application_Codeпоскольку App_Codeпапка будет скомпилирована как отдельная сборка, имеющая один и тот же класс, скомпилированный в 2 сборки.

У меня была такая же проблема с двумя элементами управления 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 ...>

Закройте Решение и снова откройте его, затем проверьте ссылки на проекты на предмет дублирования :

Это может произойти, если вы использовали 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')" />

Обратите внимание, эти ссылки «<Импорт» могут появляться в разных местах файла proj.

Очень быстрое и удобное решение - злоупотребить невероятным intellisense 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, это может объяснить, почему проверка ваших изменений не решает проблему для других членов вашей команды.

Я конвертирую старый веб-сайт 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)
    {

Для этого есть множество причин. И большинство из упомянутых выше применимы к разным сценариям. Я заметил, что ошибка возникает ТОЛЬКО, когда для аутентификации установлено иное значение, кроме «Нет». Для целей тестирования я отключу это, и он работает.

Меня перенаправили сюда при нажатии на первое обращение 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 ++ на любую версию не изменило поведения. Я не уверен, почему это внезапно перестало работать, но, надеюсь, кто-то так же заблокированный может выйти из рассола, используя аналогичные стратегии.

Помимо попытки ответить 2Toad, мне также пришлось закрыть Visual Studio и удалить мою папку .vs. После этого все построилось правильно.

Между прочим, ошибка, с которой я столкнулся, вообще не указывала мою папку Temp, а ссылалась на что-то еще, что явно было сгенерировано системой. Я не позаботился о сохранении конкретной ошибки: \

если никакое другое решение не помогло, просто переименуйте наследующий класс этой проблемы, вызывая файл 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
{