Звідки береться помилка 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 \ 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 \ WebApplication \ WebApplication .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 вашої програми. Це призводить до того, що принаймні частина вмісту папки кошика вашої програми застаріла.

Коли виникає згадана проблема, очищення папки "Тимчасові файли ASP.NET" самостійно не вирішує проблему. Це не може вирішити проблему, оскільки застарілий вміст папки кошика вашої програми копіюється назад у папку "Тимчасові файли ASP.NET" під час наступного доступу до вашої програми, через що проблема зберігається. Головне - видалити всі існуючі файли та змусити Visual Studio відновити кожен об’єкт, тому наступного разу, коли буде здійснено доступ до вашої програми, нові файли кошика будуть скопійовані в папку "Тимчасові файли 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" у "Код". Це проект MVC5, тому не повинно виникати проблем із обслуговуванням файлів .cs у корені веб-проекту.

Видалення файлів класів із App_Codeпапки та розміщення їх безпосередньо під веб-сайтом вирішило цю проблему для мене.

Це також може статися, якщо у вашому файлі ASPX є дублікат TagPrefix.

Це спричинило б цю помилку ...

<%@ 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" %>

Довідково: 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. 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

Опис: Поширеною причиною є те, що в одній папці кошика веб-додатків є дві збірки, що містять два визначення класу, але мають однакову назву класу. Це може трапитися, якщо більше одного 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. Коли це відбувається, весь стан сеансу втрачається, а кешовані елементи видаляються з кешу під час перезапуску веб-сайту. Можливо, проблема викликана невідповідним станом веб-програми. Вирішення. Виконайте перезапуск 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.

Супер швидке та зручне виправлення - це зловживання неймовірною інтелісенцією 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)
    {

Причин цьому досить багато. І більшість із згаданих вище стосуються різних сценаріїв. Що я зауважив, так це те, що помилка виникає ТІЛЬКИ, коли для автентифікації встановлено щось інше, крім "None". Для своїх цілей тестування я відключаю це, і воно працює.

Мене перенаправили сюди, натиснувши перше звернення 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 для репозиторію, який потребував оновлення коду. Пакети були досить старі (близько року), і все, що я спочатку намагався зробити, - це оновити його для проекту 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
{