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.
źródło
Odpowiedzi:
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
Wyjaśnienie
źródło
obj
ibin
foldery, a także wyjaśnić ten błąd.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)
źródło
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
źródło
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
źródło
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.
źródło
Usunięcie plików zajęć z
App_Code
folderu i umieszczenie ich bezpośrednio pod witryną rozwiązało ten problem.źródło
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ło
Ź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.
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ę.
źródło
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.Helpers
Wskazywano 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.
źródło
Może się tak zdarzyć, gdy ta sama nazwa klasy jest określona w wielu
.aspx.cs
plikach, 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.
źródło
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.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 zSystem.Web.UI.MasterPage
klasą.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.
źródło
Wydaje się, że „czyste rozwiązanie”, po którym następuje „Odbuduj rozwiązanie”, również to naprawia.
źródło
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.
źródło
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.
źródło
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.
źródło
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_Code
podobny,Application_Code
ponieważApp_Code
folder zostanie skompilowany jako oddzielny zestaw, mający tę samą klasę skompilowaną w 2 zespołach.źródło
Miałem ten sam problem z dwoma kontrolkami ascx o tej samej nazwie klasy:
Naprawiłem to, po prostu zmieniając nazwę klasy:
źródło
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.
źródło
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:
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ż
bin
katalog 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.źródło
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) {
źródło
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.
źródło
Zostałem przekierowany tutaj, gdy kliknąłem pierwsze trafienie Google po kliknięciu adresu URL błędu
CS0433
, w szczególnościZamiast 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, jakTargetPlatformMinVersion
iTargetPlatformVersion
nowo ustawione10.0.17134.0
Jedyną rzeczą, jaką musiałem zrobić, aby to „naprawić”, była zmiana na
TargetPlatformMinVersion
wyższą wersję niżTargetPlatformMinVersion
dla 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.źródło
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: \
źródło
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 {
źródło