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

81

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.

Abel
źródło
PS: moja główna myśl to: coś wkręciło temp dir, a moim głównym wyjściem jest po prostu ręczne usunięcie temp dir i odbudowanie. Jeszcze nie próbował (usunąłby „dowód”), na wypadek gdyby ktoś miał tu głębszy wgląd.
Abel

Odpowiedzi:

120

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
2 Ropucha
źródło
3
Ten post wyraźnie wzmacnia pierwotnie zaakceptowaną odpowiedź. Dobre wyjaśnienie i jasne kroki, dzięki!
Abel
1
@Abel, proszę, rozważ odpowiedź na to pytanie. Ponieważ samo wyczyszczenie folderu tymczasowego ASP.NET nie pomoże!
Arin Ghazarian
2
Zdarzyło mi się to w przypadku projektu innego niż internetowy. Samo usunięcie folderów bin i obj naprawiło to.
Matt H,
1
@ArinGhazarian, dokładnie! Musiałem usunąć obji binfoldery, a także wyjaśnić ten błąd.
Santosh
Świetna odpowiedź ze świetnym wyjaśnieniem. Dziękuję Ci!
Carlos Rodriguez
39

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)

Alex Polkhovsky
źródło
2
Tak, to prawdopodobnie zadziała (zobacz mój własny komentarz powyżej), ale miałem nadzieję, że uzyskam trochę więcej wglądu w to, skąd to pochodzi i co zrobić, aby temu zapobiec (lub nawet sprawić, by było to powtarzalne). Nie jestem przeciwny rozwiązaniu brutalnej siły, ale zanim to zrobię, chciałbym zrozumieć, co się dzieje.
Abel
Przydarzyło mi się to w przeszłości. Uważam, że jest to problem z VS, który nie usuwa się po sesji debugowania lub przed rozpoczęciem nowej. Ostatni raz zdarzyło mi się to z VS2005 kilka lat temu.
Alex Polkhovsky
3
Przyjąłem to jako odpowiedź, ponieważ jest to rozwiązanie. Jednak nie wyjaśnia „dlaczego”. Jeśli znajdę lepsze rozwiązanie lub prawdziwy powód, zaktualizuję odpowiedź Lymana lub dodam własną.
Abel
Właściwie ta odpowiedź nie działa dla mnie. Mój projekt działał dobrze kilka tygodni temu, ale wypróbowałem dzisiaj i pokazuje powyższy problem. Usunąłem pliki tymczasowe, jak wspomniano powyżej (dla systemu Windows 7) i ten sam problem nadal występuje. Nadal się zastanawiam, dlaczego ...
Venugopal M
@VenugopalM czy znalazłeś jakieś inne rozwiązanie, powyższe rozwiązanie nie zadziałało dla mnie
Vbp
11

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

Lilja
źródło
Podany przez Ciebie link był dla mnie rozwiązaniem. Przeniosłem wszystkie moje klasy z folderu App_Code i umieściłem je w nowym folderze o nazwie Classes. Następnie zmieniono nazwy przestrzeni nazw klas (koniec namespace = .Classes zamiast .App_Code). I oczywiście zaktualizuj wszystkie instrukcje using i odniesienia do folderu App_Code.
krlzlx
Dziękuję Ci bardzo. To doprowadzało mnie do szału
Sperick
To również naprawiło to dla mnie. Dzięki.
JonH,
9

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

NitroxDM
źródło
Słuszna uwaga. Kod z tamtego dnia został przepisany, więc nie mogę sprawdzić, czy pomógłby, ale dla każdego, kto ma ten błąd, może to być z pewnością świetny wskaźnik, dzięki za udostępnienie.
Abel
5

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.

tggm
źródło
4

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

Naveen Q
źródło
3
Obawiam się, że to nie jest opcja. Umieszczenie bibliotek dll bezpośrednio w katalogu głównym jest uważane przez wielu za zagrożenie bezpieczeństwa (kod aplikacji lub bin są specjalne i niedostępne przez IIS / ASP.NET, podczas gdy dowolną bibliotekę dll w katalogu głównym można po prostu pobrać, a zestawy .NET można łatwo zdemontować).
Abel
Umieściłem klasę w folderze models w projekcie ASP.NET MVC4, aby to naprawić.
DShook
4

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" %>
Jason Geiger
źródło
1
To właściwie nie jest problem, prefiks znacznika może być taki sam dla wszystkich kontrolek
Spyros
@Spyros Nie zgadzam się, ponieważ rozwiązało to problem. Minął już ponad rok i nie przypominam sobie wszystkiego, ale warto zostawić to tutaj, aby inni mogli to przeczytać.
Jason Geiger
Ta odpowiedź rozwiązała mój problem. To było dziwne, ponieważ błąd nie zawsze występował, tylko po kilku wdrożeniach. Podobnie jak Spyros, nie wierzyłem, że to rozwiąże problem, nie widziałem połączenia. Dzięki Jasonowi Geigerowi za opublikowanie tego.
VFein
Tyle ile jest warte. Kontrolki, które to powodowały, znajdowały się w tym samym folderze, do którego odwoływały się wiele aplikacji wirtualnych jako katalog wirtualny.
VFein
Podrap mój komentarz. Błąd ponownie pokazał swoją brzydką głowę. Wracając do deski kreślarskiej.
VFein
4

Ź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ę.

Sandeep Kumar Narware
źródło
Z reguły zaczynam od najprostszych oferowanych rozwiązań. Następujące rozwiązania ze scenariusza 6 powyżej rozwiązały problem: „Rozwiązanie: dotknij pliku w folderach Bin lub App_Code, aby uruchomić pełną rekompilację”.
cjo30080
2

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.

mlapaglia
źródło
2

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.

Deepak
źródło
Tx za przyjrzenie się temu. Ale w naszym przykładzie używasz partial class, co jest w rzeczywistości powszechnym sposobem (jedynym sposobem) na podzielenie jednej klasy na kilka plików, w którym to przypadku musisz użyć tej samej nazwy.
Abel
Skończyło się na tym, że był blisko mojego problemu w witrynie sieci Web (nie w aplikacji). Czyszczenie folderów Temp, przenoszenie rzeczy z App_Code i inne sugestie nie działały. Dopiero gdy spojrzałem na plik związany z kodem .cs dla mojej strony wzorcowej, zauważyłem, że nazwa pliku nie pasuje do nazwy klasy, która nadal była domyślna MasterPage. Kiedy zmieniłem nazwę klasy w menu prawym przyciskiem myszy (aby zaktualizować wszystkie odniesienia), błąd w końcu zniknął. Mogę tylko zgadywać, że moja strona wzorcowa była w konflikcie z System.Web.UI.MasterPageklasą.
Andrew S,
2

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.

Rogério Silva
źródło
1

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

rzymski
źródło
Jak wyjaśniłem w pytaniu, przynajmniej w mojej sytuacji czyszczenie roztworu nie pomogło. Powodem, dla którego to nie pomaga, jest to, że błąd jest spowodowany przez tymczasowe pliki ASP.NET (jak wyjaśniono w odpowiedziach 1 i 2), które nie są czyszczone podczas wykonywania „czystego rozwiązania”.
Abel
0

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.

Chris
źródło
0

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.

Guillermo Gutiérrez
źródło
0

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.

Christian Haaland
źródło
0

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.

Ali Mahmoodi
źródło
0

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

kunalbabre
źródło
0

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

wprowadź opis obrazu tutaj

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.

Jeremy Thompson
źródło
0

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.

WonderWorker
źródło
0

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)
    {
marcel_g
źródło
0

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.

Chagbert
źródło
0

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.

kayleeFrye_onDeck
źródło
0

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: \

Nate
źródło
0

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
{
anandd360
źródło