Ошибка ASP.Net: «Тип 'foo' существует как в« temp1.dll », так и в« temp2.dll »

При запуске проекта веб-приложения в кажущееся случайное время страница может завершиться с ошибкой CS0433: тип существует в нескольких библиотеках DLL. Все библиотеки DLL - это сгенерированные библиотеки DLL, находящиеся в каталоге «Temporary ASP.NET Files».

Добавьте атрибут batch = "false" в элемент "compilation" файла web.config.

Эта проблема возникает из-за того, как ASP.NET 2.0 использует ссылки на приложения и структуру папок приложения для компиляции приложения. Если свойство пакетной обработки элемента в файле web.config для приложения имеет значение true, ASP.NET 2.0 компилирует каждую папку в приложении в отдельную сборку.

http://www.sellsbrothers.com/1995

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

Это может произойти, если вы поместите файлы .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=в <@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 (код файла .cs), имеющей то же имя класса, т.е.

Страница ASPX: Dashboard Class: partiacl class Dashboard

AppCode / APIServices.cs: общедоступная панель управления частичным классом

Ошибка воспроизводилась только при публикации веб-сайта, но сборка и отладка не сообщали об ошибке.

В моем случае я переименовал проект, поэтому была переименована и dll. Когда я просто скопировал новую dll, но не подумал об удалении старой с сервера, у меня вскоре была куча пар классов с одинаковыми именами. Удаление устаревших dll помогло (разумеется).

Ни один из этих ответов не помог мне, однако я решил проблему. Поскольку для развертывания веб-приложения я использовал функцию публикации VS, я выбрал вариант удаления всех существующих файлов перед публикацией в мастере публикации в Интернете. Это заставило создать чистую копию приложения, и оттуда все заработало.

Это решение может быть полезно, если ваша локальная отладочная копия работает нормально, а опубликованная система - нет. Также отлично, если вы не хотите тратить время на отслеживание отдельных dll, которые нужно удалить, и не возражаете, чтобы сначала удалили производственные файлы.

В моем случае удаление всех выходных сборок из папок bin во всех проектах в решении решило проблему. К сожалению, у меня нет объяснения этому.

В моем случае проблема была решена, когда я отредактировал файл Designer.cs, у которого все еще было дублированное имя класса. по какой-то причине, когда я переименовал класс «logout» в «logout2», в файле конструктора он не был автоматически изменен и все еще оставался «logout», и это имя класса уже существовало в предварительно скомпилированной dll в моем проекте (которая принадлежит в стороннее веб-приложение, с которым я работаю и над которым работаю).

Получил эту проблему, когда поместил часть страницы aspx в отдельный пользовательский элемент управления. На моей машине все было нормально, на сервере вылетела ошибка.

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

http://support.microsoft.com/kb/919284 Метод 2: Изменить порядок папок в приложении пишет о возможных циклических ссылках

Ни одно из этих решений не помогло мне. Обе мои конфликтующие библиотеки DLL находились в C: \ ... \ AppData \ ... \ Temporary ASP.NET Files \ ...

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

Я попытался удалить новую DLL - которой вообще не должно было быть в старой кодовой базе - из местоположения «Временные файлы ASP.NET», идентифицированного msbuild. msbuild просто положил обратно.

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

Я попытался перемотать репозиторий с исходным кодом вперед, очистить и снова откатиться и очистить. Ничего.

Я попытался удалить все, что находится в папке «Временные файлы ASP.NET». msbuild просто поставил обратно.

Наконец, я попробовал перестроить в Visual Studio. Хотя вывод командной строки и вывод «Ошибки» выдавали одну и ту же ошибку msbuild «Временные файлы ASP.NET», ошибка Intellisense - при наведении курсора на конфликтующий тип - фактически жаловалась на библиотеки DLL в выходных каталогах. Судя по всему, «Чистка» и «Реконструкция» не выполняли свою работу. Я вручную удалил библиотеки DLL в выходных каталогах, определенных Intellisense, и проблема была решена.

tl; dr - Убедитесь, что вы покрываете все свои web.configs с помощью пакетной настройки, и попробуйте использовать 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" %>

Также было удалено ключевое слово partial из внутреннего кода и добавлено пространство имен для внутреннего кода.

Это:

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

Перейдите в раздел «Добавить ссылку» и найдите обе библиотеки. Обе библиотеки должны были проверить, снимите флажок с одной из библиотек, поскольку создаются ссылки на одну и ту же библиотеку с неоднозначностью версии.

Мое решение заключалось в замене CodePage = "...." на CodeBehind = "..." в файле .aspx. Каким-то образом он остался как CodePage во время миграции с предыдущих версий .NET. Эта директива страницы создает другой файл DLL, который конфликтует с файлом DLL проекта.

Ни одно из этих решений не помогло мне. Компиляция в режиме «Release» работала, но когда я переключился на «Debug», я получил множество таких сообщений об ошибках.

Не понимаю почему, но моим решением был простой перезапуск Visual Studio .

Я столкнулся с проблемой во время компиляции.

Я согласен с атрибутами batch = "true" , ошибка сообщает, что существует 2 сборки

Решение 1: удаление одного из них

Решение 2. Настройте один из них.