Помилка ASP.Net: "Тип" foo "існує в обох" temp1.dll "і" temp2.dll "

Під час запуску проекту веб-додатків сторінка може здаватися випадково випадковою помилкою CS0433: тип існує у кількох DLL-файлах. DLL-файли - це всі генеровані DLL-адреси, що знаходяться у каталозі "Тимчасові файли ASP.NET".

Додайте атрибут batch = "false" до елемента "компіляція" файлу web.config.

Ця проблема виникає через те, як ASP.NET 2.0 використовує посилання на додатки та структуру папок для складання програми. Якщо властивість пакетного елемента у файлі web.config для програми встановлено на істинне, ASP.NET 2.0 компілює кожну папку програми в окрему збірку.

http://www.sellsbrothers.com/1995

http://support.microsoft.com/kb/919284

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

Або виконайте дії збірки для .cs-файлів у App_Code як Вміст, або змініть ім'я App_Code на щось інше. Я змінив ім'я, оскільки intellisense не виправить .cs файли, позначені як вміст.

Більше інформації на http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Однією з можливих причин цієї помилки є те, що inherits=в <@page language=......inherits=>рядку є 2 сторінки aspx, які мають однакове ім’я .

Зміна inherits=імені вирішує помилку.

На випадок, якщо хтось інший поділиться моєю проблемою, я отримав цю помилку, коли намагався опублікувати веб-сайт нещодавно розгалуженого проекту, збірка працювала ідеально.

Виявляється, я забув зняти прапорець "Дозволити попередньо складеному сайту оновити" у розділі Налаштування публікації -> Налаштувати прекомпіляцію .

Як інший момент даних, у мене просто була ця проблема без жодних доказів циркулярних посилань, як описано у посиланнях у відповіді Бена. Створити проект мого веб-сайту не вдалося б із декількома з цих помилок і встановивши compilation batch="false"його виправлені, але я не хотів пройти цей маршрут, оскільки це великий виробничий веб-сайт.

Це рішення знаходилось у підпапці моєї папки D: \ svn, яку я відобразив у S :. Коли я відкрив рішення з S:, ці помилки сталися, але якщо я перейшов прямо до D: \ svn і відкрив рішення, помилок не було.

Я також зауважив, що, незважаючи на те, що я маю compilation batch="true"в своєму web.config, під час відкриття рішення із відображеного S: диск всіх моїх .ascx файлів збирається у власні збірки. Якщо я відкрию його з фізичного розташування, .ascx файли збираються у відповідні збірки папок (саме так batch="true"і повинно працювати).

Дивно.

Ця помилка була пов’язана з конфліктом між назвою класу веб-форми та wsdl stub (кодом за файлом .cs), що має однакове ім’я класу, тобто

Сторінка ASPX: Клас приладової панелі: клас партії

AppCode / APIServices.cs: загальнодоступна інформаційна панель часткового класу

Помилка була відтворена лише під час публікації веб-сайту, але побудова та налагодження не повідомили про помилку.

У моєму випадку я перейменував проект, тому dll був перейменований. Коли я просто скопіював новий dll, але не думав видалити старий з сервера, незабаром у мене з’явилася купа пар класів з однаковими іменами. Видалення застарілих DLL робило трюк (причину).

Жодна з цих відповідей не працювала для мене, проте я вирішив проблему. Оскільки я використовував функцію Publish VS для розгортання веб-програми, я вибрав можливість видалити всі існуючі файли перед публікацією в майстрі публікації веб. Це змусило чисту копію заявки, і звідти все працювало нормально.

Це рішення може бути корисним, якщо ваша локальна налагоджувальна копія працює нормально, але опублікована система не є. Також чудово, якщо ви не хочете витрачати час на відстеження окремих dll для видалення і не заперечуйте, щоб виробничі файли видалялися спочатку.

У моєму випадку видалення всіх вихідних збірок із папок бін у всіх проектах рішення вирішило проблему. На жаль, я не маю цього пояснення.

У моєму випадку проблема була вирішена, коли я редагував файл Designer.cs, який ще мав дублюване ім’я класу. чомусь, коли я перейменував клас "вихід" у "logout2", у дизайнерському файлі він не змінювався автоматично, і все ще залишався "вихід", і назва цього класу вже існувала в попередньо складеному DLL в моєму проекті (що належить на веб-додаток сторонніх розробників, над яким я працюю і розвиваю навколо).

Отримав цю проблему, коли помістив частину сторінки aspx в окремий елемент управління користувачем. На моїй машині все було добре, на сервері з’явилася помилка.

Перейменовано клас проблеми та файл проблеми.

http://support.microsoft.com/kb/919284 Спосіб 2: Впорядкування папок у додатку пише про можливі кругові посилання

Жодне з цих рішень не працювало на мене. Обидва мої конфліктуючі DLL-файли були в C: \ ... \ AppData \ ... \ Тимчасові файли ASP.NET \ ...

Проблема полягала в тому, що я повернув свій вихідний репо на більш ранню версію - перед тим, як ми перемістили тип з одного проекту на інший проект в рамках одного рішення.

Я спробував видалити новішу DLL - яка навіть не мала там взагалі в старій кодовій базі - з місця "Тимчасові файли ASP.NET", визначеного msbuild. msbuild просто поверніть його назад.

Я також спробував налаштувати web.config, який деякі тут успішно використовували, але це теж не працювало. Хоча, коли я це пишу, я розумію, що насправді було два проекти MVC в одному і тому ж рішенні, і в обох були помилки, тому проблема могла бути в тому, що я не додав налаштування обом.

Я спробував прокатати своє джерело repo вперед та чистити, відкочувати знову та чистити. Нічого.

Я спробував видалити все з місця "Тимчасові файли ASP.NET". msbuild просто поверніть його знову.

Нарешті, я спробував перебудувати у Visual Studio. Хоча вихід командного рядка та вихід "Помилки" давали однакову помилку "Тимчасові файли ASP.NET", помилка Intellisense - при наведенні курсору на конфліктний тип - насправді скаржилася на DLL у вихідних каталогах. Мабуть, "Чисті" та "Перебудувати" не виконували своїх робіт. Я вручну видалив DLL з вихідних каталогів, визначених Intellisense, і проблема була вирішена.

tl; dr - Переконайтесь, що ви охоплюєте всі свої веб-файли налаштуваннями партії, і спробуйте використовувати Intellisense для подальших доказів.

Моя проблема була пов'язана з файлом .dll, який генерувався в моїй папці проекту.

Якщо ви посилаєтесь на інший файл, замість того, щоб робити все, що ви бачите вище, мою проблему миттєво виправили - це просто видалення .dll, який знаходився в моєму каталозі / bin для мого проекту.

Проблема не обов'язково виправляє web.config - це кругла посилання, яку потрібно вирішити. Я зрозумів, що я очистив старий .dll у своєму оригінальному файлі проекту, але не в проекті, на який він посилався.

Я не рекомендую вносити зміни до вашого файлу web.config, оскільки це лише виправлення смуги допомоги - насправді не вирішення фактичної проблеми. Зробіть це, якщо вам не подобається вирішити проблему, але якщо ви хочете уникнути майбутніх головних болів, просто видаліть .dll з обох місць.

У мене був частковий клас з однойменною назвою у двох різних проектах. Я вирішив це, залишивши лише в одному проекті.

Іноді це може допомогти видалити розчин і створити його заново. Оскільки це використання відбувається при перетворенні з VS2005 на vs2010, деякі посилання на Framework 4.0 (після оновлення) залишаються у рішенні, навіть усі проекти визначаються як 3.5.

Зазвичай відбудова рішення повинна усунути ці проблеми.

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

Мій контролер мав простий статичний код, тому я змінив свій ascx:

 <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

До

 <%@ Control Language="C#" AutoEventWireup="true" Src="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

Також видалили часткове ключове слово з коду "за" і додали простір імен до коду позаду.

Це:

using System;
using System.Web.UI;

/// <summary>
/// My controller
/// </summary>
public partial class controllerName: UserControl
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

До цього:

using System;
using System.Web.UI;

namespace Controles
{
    /// <summary>
    /// My controller
    /// </summary>
    public class controllerName : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

І це працювало на мене.

Для мене це сталося, коли в моєму розташуванні PrecompiledWeb / Publish було встановлено поточну директорію, де також була коренева папка сайту.

Потім мій веб-сайт бачив папку публікації як частину проекту при складанні / складанні, а потім знаходив дублікати таким чином.

тобто не розміщуйте опубліковану / попередньо складену версію свого сайту в папках коду вашого сайту.

Якщо DLL відображаються у тимчасовій папці, спробуйте очистити своє рішення.

Опублікування мого рішення:

Проблема стосувалася "сканування під час доступу" антивіруса Mcafee. Відключення цього вирішило проблему. Так чи інакше тимчасова папка ASP не використовувалася належним чином ASP, коли антивірус був увімкнено.

Сподіваюся, що це комусь допоможе.

Папка App_Code викликає проблеми, кладіть клас поза папкою (працює чудово)

Папка App_Code не розроблена для проектів веб-додатків

http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html

Перейдіть на Додати посилання та шукайте обидва dll. Обидва DLL перевірили б, зніміть прапорець одного з dll, оскільки є посилання на один і той же dll з різною неоднозначністю версії.

Моє рішення було замінити CodePage = "...." на CodeBehind = "..." у файлі .aspx. Якось він залишився як CodePage під час міграції з попередніх версій .NET. Ця директива сторінки створює ще один файл dll, який конфліктує з файлом DLL проектів.

Жодне з цих рішень не працювало для мене. Компіляція в режимі "Випуск" спрацювала, але коли я перейшов на "Налагодження", у мене з'явилися вказівки цієї Повідомлення про помилки.

Я не розумію, чому, але простий перезапуск Visual Studio був моїм рішенням.

Я зіткнувся з проблемою під час компіляції.

Я згоден з batch = "true" атрибутами , помилка повідомляє, що існує 2 складання

Рішення 1: видалення одного з них

Рішення2: Налаштуйте один із них