it-swarm.com.de

ASP.Net-Fehler: "Der Typ" foo "ist in" temp1.dll "und" temp2.dll "vorhanden.

Beim Ausführen eines Webanwendungsprojekts kann zu scheinbar zufälligen Zeitpunkten eine Seite mit einem CS0433-Fehler fehlschlagen: Der Typ ist in mehreren DLLs vorhanden. Die DLLs sind alle generierten DLLs, die sich im Verzeichnis "Temporäre ASP.NET-Dateien" befinden.

107
Ben Fulton

Fügen Sie das Attribut batch = "false" zum Element "compilation" der Datei "web.config" hinzu.

Dieses Problem tritt aufgrund der Art und Weise auf, in der ASP.NET 2.0 die Anwendungsreferenzen und die Ordnerstruktur der Anwendung zum Kompilieren der Anwendung verwendet. Wenn die batch-Eigenschaft des Elements in der Datei web.config für die Anwendung auf true festgelegt ist, kompiliert ASP.NET 2.0 jeden Ordner in der Anwendung in einer separaten Assembly.

http://www.sellsbrothers.com/1995

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

130
Ben Fulton

Dies kann passieren, wenn Sie .cs-Dateien in App_Code platzieren und ihre Erstellungsaktion so ändern, dass sie in einem Webanwendungsprojekt kompiliert wird.

Entweder muss die Build-Aktion für die .cs-Dateien in App_Code als Inhalt erstellt oder der Name von App_Code in einen anderen Namen geändert werden. Ich habe den Namen geändert, da Intellisense die als Inhalt markierten .cs-Dateien nicht korrigiert.

Mehr Infos unter http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

21
Lilja

Ein möglicher Grund für diesen Fehler ist, dass es 2 Aspx-Seiten gibt, die in ihrem inherits= in der <@page language=......inherits=>-Zeile denselben Namen haben.

Durch Ändern des inherits=-Namens wird der Fehler behoben.

11
Amrinder Singh

Für den Fall, dass jemand anderes mein Problem teilt, habe ich diesen Fehler erhalten, als ich versuche, eine Website eines neu verzweigten Projekts zu veröffentlichen. Build funktionierte einwandfrei.

Es stellte sich heraus, dass ich vergessen hatte, das Kontrollkästchen für "Aktualisierbare vorkompilierte Site zulassen" unter publish-Einstellungen -> Vorkompilieren konfigurieren zu entfernen.

7
ErikDaBe

Als weiterer Datenpunkt hatte ich gerade dieses Problem ohne Hinweise auf Zirkelverweise, wie in den Links in Bens Antwort beschrieben. Die Erstellung meines Website-Projekts würde mit einigen dieser Fehler fehlschlagen, und durch die Einstellung von compilation batch="false" wurde dieses Problem behoben, aber ich wollte diesen Weg nicht gehen, da dies eine große Produktions-Website ist.

Diese Lösung befand sich in einem Unterordner meines D:\svn-Ordners, den ich S: zugeordnet hatte. Beim Öffnen der Lösung von S: sind diese Fehler aufgetreten, aber wenn ich direkt zu D:\svn gegangen bin und die Lösung geöffnet habe, keine Fehler. 

Ich habe auch bemerkt, dass, obwohl compilation batch="true" in meiner web.config vorhanden ist, beim Öffnen der Lösung aus dem zugeordneten S: drive alle meine .ascx-Dateien in ihre eigenen Assemblys kompiliert werden. Wenn ich es vom physischen Speicherort aus öffne, werden die .ascx-Dateien in die Assemblys ihrer jeweiligen Ordner kompiliert (so soll batch="true" funktionieren).

Seltsam.

4
Mike Powell

Dieser Fehler war auf einen Konflikt zwischen dem Klassennamen des Webformulars und dem WSDL-Stub (Code hinter der Datei .cs) mit demselben Klassennamen zurückzuführen, d. H.

ASPX-Seite: Dashboard Klasse: Partiacl-Klasse Dashboard

AppCode/APIServices.cs: Öffentliches Teilklassen-Dashboard 

Der Fehler war nur beim Veröffentlichen der Website reproduzierbar, aber beim Build und Debugging wurde kein Fehler gemeldet.

4
Ravi Garg

In meinem Fall löste das Löschen aller Ausgabebaugruppen aus Ordnerordnern in allen Projekten der Lösung das Problem. Leider habe ich keine Erklärung dafür.

3
dannydk

In meinem Fall hatte ich ein Projekt umbenannt, daher wurde auch die DLL umbenannt. Als ich gerade die neue DLL kopiert hatte und nicht daran gedacht war, die alte vom Server zu löschen, hatte ich bald eine Reihe von Klassenpaaren mit denselben Namen. Das Löschen der veralteten DLLs war der Trick (aus gutem Grund).

2
simaglei

Keine dieser Antworten funktionierte für mich, jedoch habe ich das Problem behoben. Da ich die Publizierungsfunktion von VS zum Bereitstellen der Webanwendung verwendet habe, habe ich im Publizierungsassistenten die Option Alle vorhandenen Dateien vor dem Publizieren löschen ausgewählt. Dies erzwang eine saubere Kopie der Anwendung und alles funktionierte von dort aus gut.

Diese Lösung kann hilfreich sein, wenn Ihre lokale Debugging-Kopie einwandfrei funktioniert, das veröffentlichte System jedoch nicht. Es ist auch großartig, wenn Sie sich nicht die Zeit nehmen möchten, einzelne zu löschende DLLs aufzuspüren und sich nicht um die Produktionsdateien zu kümmern, die zuerst gelöscht werden.

2
kad81

Keine dieser Lösungen funktionierte für mich. Meine beiden in Konflikt stehenden DLLs befanden sich in C:\...\AppData\...\Temporäre ASP.NET-Dateien\...

Das Problem war, dass ich mein Quell-Repo auf eine frühere Version zurückgesetzt hatte - bevor wir einen Typ von einem Projekt in ein anderes Projekt innerhalb derselben Lösung verschoben haben.

Ich habe versucht, die neuere DLL - die in der älteren Codebase überhaupt nicht vorhanden sein sollte - aus dem von msbuild angegebenen Speicherort "Temporäre ASP.NET-Dateien" zu löschen. Msbuild legte es einfach zurück.

Ich habe auch die web.config-Einstellung ausprobiert, die einige hier erfolgreich verwendet haben, aber das hat auch nicht funktioniert. Während ich dies schreibe, stelle ich fest, dass es tatsächlich zwei MVC-Projekte in derselben Lösung gab und beide Fehler hatten. Das Problem war möglicherweise, dass ich die Einstellung nicht zu beiden hinzugefügt habe.

Ich habe versucht, mein Quell-Repo nach vorne zu rollen und zu reinigen und wieder zurückzurollen und zu reinigen. Nichts.

Ich habe versucht, den gesamten Speicherort "Temporäre ASP.NET-Dateien" zu löschen. Msbuild legte es einfach wieder zurück.

Schließlich habe ich versucht, in Visual Studio neu zu erstellen. Obwohl die Befehlszeilenausgabe und die Ausgabe "Errors" den gleichen msbuild-Fehler "Temporäre ASP.NET-Dateien" ergaben, beklagte der Intellisense-Fehler beim Bewegen über den Konflikttyp tatsächlich DLLs in Ausgabeverzeichnissen. Anscheinend machten "Clean" und "Rebuild" ihre Arbeit nicht. Ich habe die DLLs in den von Intellisense angegebenen Ausgabeverzeichnissen manuell gelöscht, und das Problem wurde behoben.

tl; dr - Stellen Sie sicher, dass Sie alle Ihre web.configs mit der Stapeleinstellung abdecken, und versuchen Sie, Intellisense für weitere Hinweise zu nutzen.

1
Andrew Kvochick

In meinem Fall wurde das Problem behoben, als ich eine Designer.cs-Datei mit dem duplizierten Klassennamen bearbeitet hatte. Wenn ich die Klasse "logout" in "logout2" umbenannte, wurde sie in der Designer-Datei aus irgendeinem Grund nicht automatisch geändert und war immer noch "logout", und dieser Klassenname war bereits in einer vorkompilierten DLL in meinem Projekt vorhanden zu einer Web-App eines Drittanbieters, mit der ich arbeite und um sie herum arbeite).

1
user960123

Ich hatte eine Teilklasse mit dem gleichen Namen in zwei verschiedenen Projekten.

1
Cosmin

Dieses Problem wurde behoben, wenn ein Teil einer Aspx-Seite in das separate Benutzersteuerelement eingefügt wurde. Auf meinem Rechner war alles in Ordnung, auf dem Server wurde ein Fehler angezeigt.

Problemklasse und Datei umbenannt.

http://support.Microsoft.com/kb/919284 Methode 2: Ordnen Sie die Ordner in der Anwendung neu, um mögliche Zirkelverweise zu schreiben

1

Mein Problem war mit einer DLL verknüpft, die in meinem Projektordner generiert wurde. 

Wenn Sie auf eine andere Datei verweisen, anstatt alles zu tun, was Sie oben sehen, löste ich das Problem, indem ich die .dll löschte, die sich in meinem/bin-Verzeichnis für mein Projekt befand. 

Das Problem ist nicht unbedingt ein Fix für web.config - es ist eine Zirkelreferenz, die gelöst werden muss. Mir wurde klar, dass ich die alte .dll in meiner ursprünglichen Projektdatei gelöscht habe, aber nicht in dem Projekt, das sie referenzierte. 

Ich empfehle Ihnen nicht, die Datei "web.config" zu ändern, da dies nur eine Problembehebung ist, die das eigentliche Problem nicht wirklich angeht. Tun Sie dies, wenn Sie das Problem nicht lösen möchten, aber wenn Sie zukünftige Kopfschmerzen vermeiden möchten, entfernen Sie einfach die .dll von beiden Stellen.

1
cloudstrifebro

Meine Lösung bestand darin, CodePage = "...." durch CodeBehind = "..." in der ASPX-Datei zu ersetzen. Irgendwie wurde es während einer Migration von früheren .NET-Versionen als CodePage beibehalten .. Diese Seitenanweisung erstellt eine weitere DLL-Datei, die mit der Projekt-DLL-Datei in Konflikt steht.

0
mtkale

Ich hatte das gleiche Problem, als ich die Anwendung auf einem Kompilierungsserver kompilierte.

Mein Controller hatte einen einfachen statischen Code, also habe ich meinen ascx geändert:

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

Zu

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

Außerdem wurde das partielle Schlüsselwort aus dem Codebehind entfernt und dem Codebehind ein Namespace hinzugefügt.

Diese:

using System;
using System.Web.UI;

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

Zu diesem:

using System;
using System.Web.UI;

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

Und das hat für mich funktioniert.

0
Saliba

Keine dieser Lösungen hat für mich funktioniert. Das Kompilieren im "Release" -Modus hat funktioniert, aber als ich zu "Debug" gewechselt bin, habe ich unzählige dieser Fehlermeldungen erhalten.

Ich verstehe nicht warum, aber ein einfacher Neustart von Visual Studio war meine Lösung.

0
Beetee

Manchmal kann es hilfreich sein, die Lösung zu entfernen und erneut zu erstellen .. Da dies bei der Konvertierung von VS2005 in vs2010 geschieht, bleiben einige Verweise auf Framework 4.0 (nach dem Upgrade) in der Lösung, selbst wenn alle Projekte als 3.5 definiert sind.

Normalerweise sollten die Probleme durch das erneute Erstellen der Lösung behoben werden.

0

App_Code-Ordner verursacht das Problem, platzieren Sie die Klasse außerhalb des Ordners (Works fine)

Der App_Code-Ordner ist nicht für Webanwendungsprojekte konzipiert 

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

0
Arun Prasad E S

Für mich war dies der Fall, als mein PrecompiledWeb/Publish-Verzeichnis auf das aktuelle Verzeichnis gesetzt wurde, in dem sich auch der Stammordner der Site befand.

Meine Website sah dann den Veröffentlichungsordner als Teil des Projekts beim Kompilieren/Erstellen und fand auf diese Weise Duplikate.

fügen Sie die veröffentlichte/vorkompilierte Version Ihrer Site nicht in die Code-Ordner Ihrer Site ein.

0

Wenn die DLLs in einem temporären Ordner angezeigt werden, sollten Sie versuchen, Ihre Lösung zu reinigen. 

0
Hugo Nava Kopp

Gehen Sie zu Referenz hinzufügen und suchen Sie nach beiden DLLs Beide DLLs hätten geprüft, deaktivieren Sie eine der DLLs, da Verweise auf dieselbe DLL mit unterschiedlichen Versionsmehrdeutigkeiten generiert werden.

0
RkHirpara

Ich hatte das gleiche Problem, als ich die Anwendung auf einem Kompilierungsserver kompilierte.

Ich stimme mit den Attributen batch = "true" überein, aber der Fehler besagt, dass im Projektkontext 2 Assembly und Objekt vorhanden sind. Die Lösung sollte sein, eine davon zu löschen, die veraltet ist. In dem obigen Fall ist das Projekt asp.net und ich denke, Framework 2.0 dort sollte die Ziel-Assembly in App_Code sein

0
dewelloper

Meine Lösung posten: 

Das Problem betraf den "On-Access-Scan" von McAfee Antivirus. Das Deaktivieren dieses Problems hat das Problem gelöst. Irgendwie wurde der temporäre Ordner ASP nicht ordnungsgemäß von ASP verwendet, als der Virenschutz aktiviert war.

Hoffe das hilft jemandem. 

0
Adrian Nasui