Skąd pochodzi błąd CS0433 „Typ„ X ”już istnieje w plikach A.dll i B.dll”?

Kiedy uruchamiam aplikację internetową z programu Visual Studio 2008 SP1 przy użyciu wewnętrznego serwera internetowego (nie IIS), otrzymuję wspomniany powyżej błąd.

Pełny błąd (plik źródłowy Default.aspx.cs ):

Komunikat o błędzie kompilatora: CS0433: typ „WebApplication3.Site1” istnieje w obu „c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll 'i' c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL '

Poprzednie pełne ostrzeżenie:

Ostrzeżenie: CS0436: typ „WebApplication3._Default” w katalogu „c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs 'powoduje konflikt z importowanym typem „WebApplication3._Default” w „c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication .DLL ”. Używając typu zdefiniowanego w „c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET Files \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs”.

Źródło punktów ostrzegawczych do pliku pośredniego 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;

i moje pytanie: skąd to się bierze?

Aplikacja internetowa (nie witryna internetowa!) Ma jeden plik Default.aspx i jeden Site1.Master , bez zależności. Są prawie puste, z rozszerzeniemasp:Label na stronie. Wcześniej ta aplikacja internetowa działała dobrze. Kiedy usuwam wszelkie odniesienia w Default.aspx.cs do wzorca, wszystko idzie dobrze. Mistrz ma tylko jakiś kod.

W rzeczywistości jest to jedna z wielu aplikacji testowych typu „uruchom i zapomnij”, więc nie obchodzi mnie to. Ale nie widziałem tego wcześniej i teraz jestem ciekawy, co robić, poza skopiowaniem kodu do nowego projektu (rozwiązanie czyszczące nie pomaga).

Uwaga: przeczytałem ten post i kilka innych, nie mają zastosowania.

Teoria

Jeśli ten problem nie jest spowodowany błędem w aplikacji (np. Zduplikowana nazwa klasy):

Ten problem wydaje się występować po wprowadzeniu zmiany w projekcie aplikacji, która skutkuje nową kompilacją (np. Kod / odwołanie / zmiana zasobu). Wydaje się, że problem dotyczy danych wyjściowych tej nowej kompilacji: z różnych powodów program Visual Studio nie zastępuje całej zawartości folderów obj / bin aplikacji. Powoduje to, że przynajmniej część zawartości folderu bin aplikacji jest nieaktualna.

Gdy wystąpi ten problem, samo wyczyszczenie folderu „Temporary ASP.NET Files” nie rozwiązuje problemu. Nie może rozwiązać problemu, ponieważ nieaktualna zawartość folderu bin aplikacji jest kopiowana z powrotem do folderu „Temporary ASP.NET Files” przy następnym dostępie do aplikacji, przez co problem nadal występuje. Kluczem jest usunięcie wszystkich istniejących plików i wymuszenie na programie Visual Studio odbudowania każdego obiektu, tak aby przy następnym dostępie do aplikacji nowe pliki bin zostały skopiowane do folderu „Temporary ASP.NET Files”.

Rozwiązanie

1. Zamknij program Visual Studio
2. Wykonaj iisreset
3. Usuń wszystkie foldery i pliki w folderze „Temporary ASP.NET Files” (ścieżka jest wymieniona w komunikacie o błędzie)
4. Usuń foldery „obj” i „bin” szkodliwej aplikacji
5. Uruchom ponownie program Visual Studio i otwórz rozwiązanie
6. Wykonaj „Czyste rozwiązanie”, a następnie „Odbuduj rozwiązanie”

Wyjaśnienie

• Kroki 1-2: usuń blokady zasobów z folderów / plików, które musimy usunąć.
• Kroki 3-4: usuń wszystkie stare pliki kompilacji
• Kroki 5-6: utwórz nowe wersje plików kompilacji

Zamknij w3svc i usuń wszystko z c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

dodany

• w systemie Windows 7

  c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

• na serwerach IIS (64-bitowych) może to również wystąpić. Szukać:

  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

  (Zastąp wersję 4.0.30319 używaną wersją frameworka, jeśli jest nowsza na serwerze)

Może się tak zdarzyć, jeśli umieścisz pliki .cs w App_Code i zmienisz ich akcję kompilacji na kompilację w projekcie aplikacji sieci Web.

Ustaw akcję kompilacji dla plików .cs w App_Code jako zawartość lub zmień nazwę App_Code na coś innego. Zmieniłem nazwę, ponieważ Intellisense nie naprawi plików .cs oznaczonych jako zawartość.

Więcej informacji na http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Spójrz na tag Inherits wszystkich stron aspx i stron wzorcowych. Są szanse, że istnieją dwie klasy częściowe o tej samej nazwie. Zmień jeden i ponownie skompiluj.

Oto więcej informacji:

http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx

Po tych wszystkich sugestiach nadal miałem problem. Pewna klasa wewnątrz App_Code była kompilowana do dwóch bibliotek DLL. Coś takiego (uproszczone):

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'.

Właśnie zmieniłem nazwę folderu „App_Code” na „Code”. To jest projekt MVC5, więc nie powinno być problemu z obsługą plików .cs w katalogu głównym projektu internetowego.

Usunięcie plików zajęć z App_Codefolderu i umieszczenie ich bezpośrednio pod witryną rozwiązało ten problem.

Może się to również zdarzyć, jeśli w pliku ASPX znajduje się zduplikowany element TagPrefix.

Spowodowałoby to ten błąd ...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %>

Możesz to naprawić, po prostu zmieniając drugie „uc1” na „uc2”

Naprawiony...

<%@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %>

<%@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %>

Źródła: https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

Podczas tworzenia projektu ASP.NET przy użyciu programu Visual Studio może losowo zobaczyć komunikat o błędzie podobny do następującego:

Komunikat o błędzie kompilatora: CS0433: Typ „ASP.summary_common_controls_notes_ascx” istnieje zarówno w „c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll” i „ c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporary ASP.NET Files \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Opis: wystąpił błąd podczas kompilowania zasobu wymaganego do obsługi tego żądania. Zapoznaj się z poniższymi szczegółami błędu i odpowiednio zmodyfikuj kod źródłowy.

Błąd źródła: Wiersz 100: Wiersz 101:
Nowe notatki Wiersz 102:
Wiersz 103:
1450 Wiersz 104:

Podsumowanie.

Plik źródłowy: d: \ http \ post \ publisher \ default.aspx Line: 102

Typowe scenariusze, w których może wystąpić ten błąd, omówiono poniżej

Scenariusz 1

Opis: częstą przyczyną jest występowanie dwóch zestawów w tym samym folderze bin aplikacji sieci Web, które zawierają dwie definicje klas, ale mają taką samą nazwę klasy. Może się tak zdarzyć, jeśli więcej niż jeden plik Default.aspx został skompilowany w jeden zestaw. Zwykle ma to miejsce, gdy strona wzorcowa (Default.master) i domyślna strona ASPX (Default.aspx) deklarują klasę _Default. Rozwiązanie: Zmień nazwę klasy strony wzorcowej (w większości przypadków z _Default) i odbuduj projekt. Ważne jest, aby rozwiązać wszelkie konflikty nazewnictwa między klasami.

Scenariusz 2

Opis: ścieżki odwołań w programie Visual Studio służą do określania ścieżki folderu dla odwołań do zestawów używanych przez projekt. Możliwe, że ścieżka zawiera zestaw, który zawiera tę samą nazwę klasy. Może się zdarzyć, że do tego samego zestawu dodano wiele odwołań (prawdopodobnie inna wersja lub nazwa), co powoduje konflikt nazw.
Rozwiązanie: Usuń odwołanie do starej wersji. Aby to zrobić, w programie Visual Studio kliknij witrynę internetową prawym przyciskiem myszy i zaznacz opcję „Odwołania” we właściwościach.

Scenariusz 3

Opis: Domyślnie podczas kompilowania aplikacji sieci Web ASP.NET skompilowany kod jest umieszczany w folderze Temporary ASP.NET Files. Domyślnie uprawnienia dostępu są nadawane lokalnemu kontu użytkownika ASP.NET, które ma uprawnienia wysokiego zaufania potrzebne do uzyskania dostępu do skompilowanego kodu. Możliwe, że wprowadzono pewne zmiany w uprawnieniach domyślnych, powodując konflikty wersji. Inną możliwością może być to, że oprogramowanie antywirusowe może nieumyślnie blokować zestaw. Rozwiązanie: Wyczyść folder tymczasowych plików ASP.NET z całej zawartości.

Scenariusz 4

Opis: ustawienie atrybutu batch w pliku web.config na wartość True eliminuje opóźnienie spowodowane kompilacją wymaganą przy pierwszym dostępie do pliku. ASP.NET prekompiluje wszystkie nieskompilowane pliki w trybie wsadowym, co powoduje opóźnienia przy pierwszej kompilacji plików. Wyłączenie kompilacji wsadowej może ujawnić zamaskowane błędy kompilacji, które mogą istnieć w aplikacji, ale nie są zgłaszane. Jednak co ważniejsze w przypadku tego problemu, informuje ASP.NET, aby dynamicznie kompilował poszczególne pliki .aspx / .ascx w oddzielne zestawy, a nie w jeden zestaw. Rozwiązanie: ustaw batch = false w sekcji pliku web.config. Należy to uznać za rozwiązanie tymczasowe, ponieważ ustawienie batch = false w sekcji kompilacji ma znaczący wpływ na wydajność na czas kompilacji aplikacji w programie Visual Studio.

Scenariusz 5

Opis: modyfikacja pliku web.config aplikacji ASP.NET lub zmiana pliku w folderze bin (na przykład dodanie, usunięcie lub zmiana nazwy) powoduje ponowne uruchomienie AppDomain. W takim przypadku cały stan sesji jest tracony, a elementy z pamięci podręcznej są usuwane z pamięci podręcznej po ponownym uruchomieniu witryny internetowej. Możliwe, że przyczyną problemu jest niespójny stan aplikacji internetowej. Rozwiązanie: uruchom ponowne uruchomienie domeny AppDomain, dotykając (edytując) plik web.config.

Scenariusz 6

Opis: kod źródłowy można przechowywać w folderze App_Code, który zostanie automatycznie skompilowany w czasie wykonywania. Wynikowy zestaw jest dostępny dla dowolnego innego kodu w aplikacji sieci Web. Dlatego folder App_Code działa podobnie jak folder Bin, z tą różnicą, że można w nim przechowywać kod źródłowy zamiast skompilowanego kodu. Klasa zostanie ponownie skompilowana, gdy nastąpi zmiana w pliku źródłowym. Jeśli występuje konflikt z powodu przestarzałego zestawu, wymuszenie ponownej kompilacji może rozwiązać problem. Rozwiązanie: dotknij pliku w folderach Bin lub App_Code, aby wywołać pełną rekompilację.

Zdarzyło mi się to z powodu błędu w moim pliku 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"/>

Plik Sytem.Web.HelpersWskazywano na 1.0.0.0 zamiast 3.0.0.0 (MVC 3 jest używany w tym projekcie).

Ponieważ usługi IIS nie mogły znaleźć odniesienia w folderze lokalnym, wyszukały w GAC i znalazły dwie różne wersje. Po wskazaniu go na prawidłowe odniesienie, usługi IIS znalazły lokalną bibliotekę DLL i użyły jej zamiast przeszukiwać GAC.

Może się tak zdarzyć, gdy ta sama nazwa klasy jest określona w wielu .aspx.csplikach, tj. Gdy tworzone są dwie strony z różnymi nazwami plików, ale przez pomyłkę mają tę samą nazwę klasy.

// file a.aspx
public partial class Test1: System.Web.UI.Page

// file b.aspx
public partial class Test1: System.Web.UI.Page

Podczas budowania aplikacji internetowej daje to ostrzeżenie, ale aplikacja działa, jednak po opublikowaniu aplikacja już nie działa i zgłasza wyjątek, o którym mowa w pytaniu OP.

Upewnienie się, że nazwy dwóch klas nie pokrywają się, rozwiązuje problem.

Znalazłem inny powód: różne wersje ikon w przyborniku i referencje w projekcie. Po wstawieniu obiektów w jakiejś formie zaczął się błąd.

Wydaje się, że „czyste rozwiązanie”, po którym następuje „Odbuduj rozwiązanie”, również to naprawia.

Skończyło się na zmianie sposobu odniesienia do MasterType w znaczniku strony.

Zmieniłem: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> na<%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Zobacz tutaj po szczegóły.

Mam nadzieję, że to komuś pomoże.

Przynajmniej dla mnie stało się to, gdy usunąłem odwołanie do zestawu i dodałem odwołanie do nowszej jego wersji, która miała inną nazwę. W tym przypadku wydaje się, że stary zespół pozostał w folderze bin i obj i nie został usunięty za pomocą operacji czyszczenia rozwiązania z programu Visual Studio (może dlatego, że nie jest już częścią projektu). W tym przypadku wystarczyło usunąć zawartość folderów bin i obj projektu, w którym wystąpił błąd, z Eksploratora Windows (lub narzędzia do zarządzania plikami). Następnie w programie Visual Studio wyczyść rozwiązanie i skompiluj je ponownie.

W naszym przypadku przyczyną była różnica między wersjami .dll witryn w usługach IIS. Są one umieszczane jeden pod drugim w usługach IIS, umożliwiając dostęp do drugiego za pośrednictwem subdomeny. Dziedziczy on z pierwszego pliku web.config i łącząc go z następnym plikiem web.config, nie powiódł się, mając różne wersje mvc.dll.

Miałem podobny problem. Oto moje rozwiązanie: Umieść izolowane klasy, które wymagają [Build Action]ustawienia właściwości jako [Compile]dowolnego folderu innego niż App_Codepodobny, Application_Codeponieważ App_Codefolder zostanie skompilowany jako oddzielny zestaw, mający tę samą klasę skompilowaną w 2 zespołach.

Miałem ten sam problem z dwoma kontrolkami ascx o tej samej nazwie klasy:

Control1: <% @ Control Language = "C #" ClassName = " myClassName " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName "AutoEventWireup =" true ...>

Naprawiłem to, po prostu zmieniając nazwę klasy:

Control1: <% @ Control Language = "C #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>

Zamknij rozwiązanie i otwórz je ponownie, a następnie sprawdź referencje projektów pod kątem podwojenia :

Może się tak zdarzyć, jeśli używasz NuGet i zmieniono lokalizację odniesienia bibliotek DLL. Aby to naprawić, musisz ręcznie edytować plik proj usuwając wpisy, np:

  <Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />

Uważaj, ponieważ te odniesienia „<Import” mogą pojawiać się w różnych miejscach w pliku proj.

Super szybkim i wygodnym rozwiązaniem jest wykorzystanie niesamowitej inteligencji programu Visual Studio poprzez tymczasowe odwołanie się do klasy.

Przykład:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Podczas budowania lub najechania kursorem na linię możesz zobaczyć następujący błąd:

„System.Runtime.CompilerServices.ExtensionAttribute” istnieje w obu „C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll”

To natychmiast informuje o dwóch źródłach powodujących konflikt.

System.Core.dll to plik .dll, który chcesz zachować, więc usuń drugi.

Znalazłem moje siedzące w bin katalogu, ale może być w innym miejscu projektu.

W rzeczywistości warto o tym pamiętać, ponieważ binkatalog może nie być uwzględniony jako część zestawu zmian TFS, może to wyjaśnić, dlaczego sprawdzenie zmian nie rozwiązuje problemu dla innych członków zespołu.

Konwertuję starą witrynę sieci Web asp.net (v 1 lub 2) tak, aby działała pod .net 4.5 jako aplikacja internetowa.

Moim rozwiązaniem było przeniesienie delegatów obsługi zdarzeń kontroli użytkownika, które powodowały problem, do oddzielnego pliku fizycznego:

//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)
    {

Przyczyn tego jest wiele. Większość z wymienionych powyżej dotyczy różnych scenariuszy. Zauważyłem, że błąd występuje TYLKO wtedy, gdy uwierzytelnianie jest ustawione na coś innego niż „Brak”. Dla celów testowych włączę to i działa.

Zostałem przekierowany tutaj, gdy kliknąłem pierwsze trafienie Google po kliknięciu adresu URL błędu CS0433, w szczególności

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...'

Zamiast opisywać wszystkie rzeczy, które zrobiłem, aby to naprawić, powiem ci, co zrobiłem, co go zepsuło. Poszedłem zaktualizować pakiety NuGet dla repozytorium, które wymagało aktualizacji kodu. Pakiety były dość stare (około 1 roku) i wszystko, co początkowo próbowałem zrobić, to zaktualizować je dla projektu C #.

W pewnym momencie pomiędzy rozpoczęciem tego procesu a napotkaniem tego błędu w jakiś sposób obniżyłem wersję projektów C ++ w tym SLN do wersji docelowej 15063. Zauważyłem również, że projekt C # miał zarówno, jak TargetPlatformMinVersioni TargetPlatformVersionnowo ustawione10.0.17134.0

Jedyną rzeczą, jaką musiałem zrobić, aby to „naprawić”, była zmiana na TargetPlatformMinVersionwyższą wersję niż TargetPlatformMinVersiondla projektu C #. Modyfikowanie projektu C ++ do dowolnej wersji nie zmieniło zachowania. Nie jestem pewien, dlaczego to nagle przestało działać, ale mam nadzieję, że ktoś podobnie zablokowany może wydostać się z marynaty przy użyciu podobnych strategii.

Oprócz wypróbowania odpowiedzi 2Toad, musiałem również zamknąć program Visual Studio i usunąć mój folder .vs. Potem wszystko zostało poprawnie zbudowane.

Nawiasem mówiąc, napotkany błąd w ogóle nie określał mojego folderu Temp, ale odnosił się do czegoś innego, co oczywiście zostało wygenerowane przez system. Zaniedbałem zapisanie konkretnego błędu: \

jeśli żadne inne rozwiązanie nie zadziałało, po prostu zmień nazwę klasy dziedziczącej ten problem, powodując plik aspx i plik aspx.cs na nową nazwę, a następnie ponownie skompiluj rozwiązanie. wtedy na pewno problem zostanie rozwiązany. to działało tylko dla mnie.

np .:

w pliku aspx wykonaj następujące czynności Zmień dziedziczoną nazwę klasy na Defaultnew

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

w pliku aspx.cs zmień nazwę klasy na taką samą, jak jest używana w pliku aspx

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{