Ошибка ASP.Net: "Тип" foo "существует в файлах"temp1.dll"и"temp2.dll"
При запуске проекта веб-приложения в случайные на первый взгляд страницы может произойти сбой с ошибкой CS0433: тип существует в нескольких DLL. Все DLL являются сгенерированными DLL, находящимися в каталоге "Temporary ASP.NET Files".
26 ответов
Добавьте атрибут batch="false" в элемент "compilation" файла web.config.
Эта проблема возникает из-за способа, которым ASP.NET 2.0 использует ссылки приложения и структуру папок приложения для компиляции приложения. Если для свойства пакета элемента в файле web.config для приложения установлено значение true, ASP.NET 2.0 компилирует каждую папку в приложении в отдельную сборку.
Это может произойти, если вы поместите файлы.cs в App_Code и измените их действие сборки для компиляции в проекте веб-приложения.
Либо используйте действие сборки для файлов.cs в App_Code как Content, либо измените имя App_Code на другое. Я изменил имя, так как intellisense не исправит файлы.cs, помеченные как содержимое.
Более подробная информация на http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html
Одной из возможных причин этой ошибки является то, что есть 2 страницы ASPX, которые имеют одинаковое имя в их inherits= в <@page language=......inherits=> линия.
Изменение inherits= имя решает ошибку.
На тот случай, если кто-то еще поделится моей проблемой, я получил эту ошибку при попытке опубликовать веб-сайт недавно разветвленного проекта, сборка работала отлично.
Оказывается, я забыл снять флажок "Разрешить обновление предварительно скомпилированного сайта" в разделе " Параметры публикации" -> "Настроить прекомпиляцию".
Эта ошибка произошла из-за конфликта между именем класса веб-формы и заглушкой wsdl (код файла.cs), имеющей то же имя класса, т.е.
Страница ASPX: Панель инструментов Класс: класс панели инструментов
AppCode/APIServices.cs: публичный частичный класс Dashboard
Ошибка воспроизводилась только при публикации сайта, но сборка и отладка не сообщали об ошибке.
В качестве еще одного пункта данных, у меня просто была эта проблема без каких-либо свидетельств циклических ссылок, как описано в ссылках в ответе Бена. Создание моего проекта веб-сайта не удастся с некоторыми из этих ошибок, и настройка compilation batch="false" исправил это, но я не хотел идти по этому пути, так как это крупный производственный сайт.
Это решение находилось в подпапке моей папки D:\svn, которую я сопоставил с S:. Когда я открыл решение из S:, произошли эти ошибки, но если я пошел прямо в D:\svn и открыл решение, ошибок не было.
Я также заметил, что, несмотря на compilation batch="true" в моем файле web.config при открытии решения с подключенного диска S: все мои файлы.ascx компилируются в свои собственные сборки. Если я открою его из физического местоположения, файлы.ascx будут скомпилированы в сборки соответствующих папок (как batch="true" должен работать).
Странный.
В моем случае удаление всех выходных сборок из папок bin во всех проектах в решении решило проблему. К сожалению, у меня нет объяснения этому.
Ни один из этих ответов не помог мне, но я решил проблему. Поскольку я использовал функцию публикации VS для развертывания веб-приложения, я выбрал опцию удаления всех существующих файлов перед публикацией в мастере публикации в Интернете. Это заставило чистую копию приложения, и оттуда все работало нормально.
Это решение может быть полезно, если ваша локальная отладочная копия работает нормально, а опубликованная система - нет. Также замечательно, если вы не хотите тратить время на поиск отдельных dll для удаления и не возражаете против производственных файлов, удаляемых в первую очередь.
В моем случае я переименовал проект, поэтому dll также была переименована. Когда я просто скопировал новую DLL-библиотеку, но не думал об удалении старой с сервера, у меня вскоре возникла пара классов с одинаковыми именами. Удаление устаревших dll делало свое дело (причины).
В моем случае проблема была решена, когда я отредактировал файл Designer.cs, который все еще имел дублированное имя класса. по какой-то причине, когда я переименовал класс "logout" в "logout2", в файле конструктора он не был автоматически изменен и все еще был "logout", и это имя класса уже существовало в предварительно скомпилированной dll в моем проекте (который принадлежит стороннему веб-приложению, с которым я работаю и разрабатываю).
Ни одно из этих решений не помогло мне. Компиляция в режиме "Release" работала, но когда я переключился на "Debug", я получил множество сообщений об ошибках.
Я не понимаю почему, но простой перезапуск Visual Studio был моим решением.
Эта проблема возникла, когда вы поместили часть страницы 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 "Temporary ASP.NET Files", ошибка Intellisense - при наведении указателя мыши на конфликтующий тип - фактически жаловалась на библиотеки DLL в выходных каталогах. Видимо, "Чистый" и "Восстановить" не делали свою работу. Я вручную удалил библиотеки DLL в выходных каталогах, определенных Intellisense, и проблема была решена.
tl; dr - Убедитесь, что вы закрываете все свои web.configs с помощью пакетной настройки, и попробуйте использовать Intellisense для дальнейших подсказок.
Моя проблема была связана с.dll, которая генерировалась в папке моего проекта.
Если вы ссылаетесь на другой файл, вместо того, чтобы делать все, что вы видите выше, то, что сразу же решило мою проблему, было просто удалить.dll, которая находилась в моей директории / bin для моего проекта.
Проблема не обязательно является исправлением web.config - это круговая ссылка, которую необходимо решить. Я понял, что очистил старый.dll в моем исходном файле проекта, но не в проекте, который ссылался на него.
Я не рекомендую вносить изменения в ваш файл web.config, потому что это всего лишь исправление бинта, а не решение реальной проблемы. Сделайте это, если вам не хочется решать проблему, но если вы хотите избежать головной боли в будущем, просто удалите.dll из обоих мест.
У меня был частичный класс с тем же именем в двух разных проектах. Я решил это, оставив только в одном проекте.
Была похожая проблема. В моем случае я заметил, что очистка решения не очищает папку bin в визуальной студии. В папке, вызывающей проблему, присутствовала старая скомпилированная .dll.
Решения:
- Вручную удалите папку bin и перекомпилируйте
- В случае публикации выберите удалить существующие файлы перед публикацией.
Это решит проблему.
Для меня это произошло, когда я установил для моего PrecompiledWeb/Publish местоположение текущего каталога, в котором также находилась корневая папка сайта.
Мой веб-сайт затем просматривал папку публикации как часть проекта при компиляции / сборке, а затем находил дубликаты таким образом.
т.е. не помещайте опубликованную / предварительно скомпилированную версию вашего сайта в папки кода вашего сайта.
Перейдите к Добавить ссылку и найдите обе библиотеки DLL. Обе библиотеки DLL проверили бы, снимите галочку с одной библиотеки DLL, поскольку генерируются ссылки на одну и ту же библиотеку DLL с разной версией неоднозначности.
Опубликовать мое решение:
Эта проблема была связана с "Сканированием при доступе" антивируса Mcafee. Отключение этого решило проблему. Каким-то образом ASP Temporary папка не использовалась должным образом ASP, когда антивирус был включен.
Надеюсь, это кому-нибудь поможет.
Если библиотеки DLL отображаются во временной папке, попробуйте очистить решение.
У меня была такая же проблема, когда я компилировал приложение на компилирующем сервере.
Мой контроллер имел простой статический код, поэтому я изменил свой 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" %>
Также удалил частичное ключевое слово из codebehind и добавил пространство имен в codebehind.
Это:
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)
{
}
}
}
И это сработало для меня.
Папка App_Code вызывает проблему, поместите класс вне папки (Работает нормально)
Папка App_Code не предназначена для проектов веб-приложений
http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html
Иногда это может помочь удалить решение и создать его заново. Поскольку такое использование происходит при преобразовании из VS2005 в vs2010, некоторые ссылки на Framework 4.0 (после обновления) остаются в решении, даже все проекты определены как 3.5.
Обычно восстановление решения должно очистить эти проблемы.
У меня была такая же проблема, когда я компилировал приложение на компилирующем сервере.
Я согласен с манерой атрибутов batch="true", но ошибка говорит о том, что существуют две сборки и объект в контексте проекта. Решение должно состоять в том, чтобы удалить один из них, который устарел. В вышеупомянутом случае проект - asp.net, и я думаю, что framework 2.0 там, где целевая сборка должна быть в App_Code
Мое решение состояло в том, чтобы заменить CodePage="...." на CodeBehind="..." в файле.aspx. Каким-то образом он был оставлен как CodePage во время миграции с предыдущих версий.NET. Эта директива страницы создает другой файл DLL, который конфликтует с файлом DLL проекта.
Вы должны определить псевдоним для одной из ваших ссылок.
В вашем файле проекта.csprojдобавить следующий пункт:
<ItemGroup>
<Reference Include="temp1.dll">
<Aliases>MyAssembly</Aliases>
</Reference>
</ItemGroup>
После добавления указанной выше ItemGroup,MyAssemblyбудет представлять корневое пространство имен, которое будет содержать все пространства имен в сборке.
Затем вы можете получить доступ к типуfoo, который находится вtemp1.dll, следующим образом:
using MyAssembly.foo;