Znaleziono wiele typów pasujących do kontrolera o nazwie „Strona główna”

Obecnie prowadzę online dwa niepowiązane projekty MVC3.

Jeden działa dobrze, drugi nie działa, co powoduje błąd:

Znaleziono wiele typów pasujących do kontrolera o nazwie „Dom”. Może się to zdarzyć, jeśli trasa obsługująca to żądanie („{kontroler} / {akcja} / {id}”) nie określi przestrzeni nazw w celu wyszukania kontrolera pasującego do żądania.

W takim przypadku zarejestruj tę trasę, wywołując przeciążenie metody „MapRoute”, która przyjmuje parametr „przestrzeni nazw”.

Mój hoster działa w ten sposób, że daje mi dostęp FTP, aw tym folderze mam dwa inne foldery, po jednym dla każdej z moich aplikacji.

ftpFolderA2 / foo.com

ftpFolderA2 / bar.com

foo.com działa dobrze, publikuję aplikację w lokalnym systemie plików, a następnie przesyłam zawartość FTP i działa.

Gdy przesyłam i próbuję uruchomić bar.com, powyższy problem się uruchamia i uniemożliwia mi korzystanie z mojej witryny. Przez cały czas foo.com nadal działa .

Czy bar.com przeszukuje WSZYSTKIE sterowniki w ftpFolderA2 i dlatego szuka innego HomeController? Jak mogę nakazać, aby wyglądał w folderze Controller tak, jak powinien?

Fakty:

1. Nie korzystam z obszarów. Są to dwa całkowicie niepowiązane projekty. Każdy opublikowany projekt umieszczam w każdym folderze. Nic fajnego.
2. Każdy projekt ma tylko 1 HomeController.

Czy ktoś może potwierdzić, że to jest problem?

Ten komunikat o błędzie często występuje, gdy korzystasz z obszarów i masz tę samą nazwę kontrolera w obszarze i katalogu głównym. Na przykład masz dwa:

• ~/Controllers/HomeController.cs
• ~/Areas/Admin/Controllers/HomeController.cs

Aby rozwiązać ten problem (jak sugeruje komunikat o błędzie), podczas deklarowania tras można użyć przestrzeni nazw. Tak więc w głównej definicji trasy w Global.asax:

routes.MapRoute(
    "Default",
    "{controller}/{action}/{id}",
    new { controller = "Home", action = "Index", id = UrlParameter.Optional },
    new[] { "AppName.Controllers" }
);

i w ~/Areas/Admin/AdminAreaRegistration.cs:

context.MapRoute(
    "Admin_default",
    "Admin/{controller}/{action}/{id}",
    new { action = "Index", id = UrlParameter.Optional },
    new[] { "AppName.Areas.Admin.Controllers" }
);

Jeśli nie używasz obszarów, wydaje się, że obie aplikacje są hostowane w tej samej aplikacji ASP.NET i występują konflikty, ponieważ masz te same kontrolery zdefiniowane w różnych przestrzeniach nazw. Będziesz musiał skonfigurować IIS do hostowania tych dwóch jako osobnych aplikacji ASP.NET, jeśli chcesz uniknąć tego rodzaju konfliktów. Poproś o to dostawcę usług hostingowych, jeśli nie masz dostępu do serwera.

Oto kolejny scenariusz, w którym możesz zmierzyć się z tym błędem. Jeśli zmienisz nazwę projektu, aby zmienić nazwę pliku zestawu, możliwe jest posiadanie dwóch wersji zestawu ASP.NET, które będą odtwarzać ten błąd.

Rozwiązaniem jest przejście do binfolderu i usunięcie starych bibliotek dll. (Próbowałem „Przebuduj projekt”, ale to ich nie usunęło, więc upewnij się, że binich nie ma)

W MVC4 i MVC5 Jest trochę inaczej, użyj następujących

/App_Start/RouteConfig.cs

namespace MyNamespace
{
    public class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
                namespaces:  new[] {"MyNamespace.Controllers"}
            );
        }
    }
}

i na obszarach

context.MapRoute(
                "Admin_default",
                "Admin/{controller}/{action}/{id}",
                new { action = "Index", id = UrlParameter.Optional },
                new[] { "MyNamespace.Areas.Admin.Controllers" }
            );

Obejrzyj to ... http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas

To zdjęcie (mam nadzieję, że lubisz moje rysunki)

To, co powiedzieli inni, jest poprawne, ale dla tych, którzy wciąż napotykają ten sam problem: w
moim przypadku stało się tak, ponieważ skopiowałem inny projekt i przemianowałem go na coś innego, ALE poprzednie pliki wyjściowe w binfolderze wciąż tam były ... I niestety uderzenie Build -> Clean Solutionpo zmianie nazwy projekt i Namespaces nie usuwa ich ... więc ich ręczne usunięcie rozwiązało mój problem!

w bin/folderze projektu

upewnij się, że masz tylko PROJECT_PACKAGENAME.DLL

i usuń ANOTHER_PROJECT_PACKAGENAME.DLL

które mogą pojawić się tutaj przez pomyłkę lub po prostu zmienisz nazwę swojego projektu

Sprawdź folder bin, jeśli istnieje inny plik dll, który może powodować konflikt z klasą homeController.

Innym rozwiązaniem jest zarejestrowanie domyślnej przestrzeni nazw w ControllerBuilder. Ponieważ w naszej głównej aplikacji mieliśmy wiele tras i tylko jedną ogólną trasę w naszych obszarach (gdzie już określaliśmy przestrzeń nazw), stwierdziliśmy, że jest to najłatwiejsze rozwiązanie:

ControllerBuilder.Current
     .DefaultNamespaces.Add("YourApp.Controllers");

Nawet jeśli nie korzystasz z obszarów, nadal możesz określić w mapie trasy, której przestrzeni nazw użyć

routes.MapRoute(
    "Default",
    "{controller}/{action}",
    new { controller = "Home", action = "Index" },
    new[] { "NameSpace.OfYour.Controllers" }
);

Wygląda jednak na to, że faktycznym problemem jest sposób skonfigurowania dwóch aplikacji w usługach IIS

Właśnie miałem ten problem, ale tylko kiedy opublikowałem na mojej stronie, w moim lokalnym debugowaniu zadziałało dobrze. Odkryłem, że musiałem użyć FTP z mojego hosta internetowego i przejść do mojego katalogu publikowania i usunąć pliki z folderu BIN, usuwając je lokalnie, nic nie zrobiłem po opublikowaniu.

Może istnieć inny przypadek z Obszarem, nawet jeśli wykonałeś wszystkie kroki w routingu w Obszarach (np. Dając Przestrzenie nazw w globalnej tabeli routingu), a mianowicie:

Być może nie umieściłeś globalnego kontrolera w „przestrzeni nazw” podanej podczas routingu.

Na przykład:

Zrobił to:

public class HomeController : Controller
{

Zamiast:

namespace GivenNamespace.Controllers
{
   public class HomeController : Controller
   {

Błąd 500 można również uzyskać, jeśli dodasz własny zestaw, który zawiera ApiController, zastępując GetAssemblies DefaultAssembliesResolver i jest już w tablicy z base.GetAssemblies ()

Przykładem:

public class MyAssembliesResolver : DefaultAssembliesResolver
{
    public override ICollection<Assembly> GetAssemblies()
    {
        var baseAssemblies = base.GetAssemblies();

        var assemblies = new List<Assembly>(baseAssemblies);

        assemblies.Add(Assembly.GetAssembly(typeof(MyAssembliesResolver)));

        return new List<Assembly>(assemblies);
    }
}

jeśli powyższy kod znajduje się w tym samym zestawie co kontroler, ten zespół będzie dwa razy na liście i wygeneruje błąd 500, ponieważ interfejs API sieci Web nie wie, którego użyć.

jeśli chcesz rozwiązać to automatycznie .. możesz użyć aplikacji assamly po prostu dodaj następujący kod:

 routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
            namespaces: new[] { string.Format("{0}.Controllers", BuildManager.GetGlobalAsaxType().BaseType.Assembly.GetName().Name) }
        );

Mam takie same problemy i nic nie pomogło. Problem polega na tym, że tak naprawdę nie mam żadnych duplikatów, ten błąd pojawia się po zmianie przestrzeni nazw projektu z MyCuteProjectna MyCuteProject.Web.

W końcu zdałem sobie sprawę, że źródłem błędu jest global.asaxplik - znaczniki XML, a nie .cs-codebehind. Sprawdź w nim przestrzeń nazw - to mi pomogło.

właśnie usunąłem folder „Bin” z serwera i skopiowałem mój bin na serwer, a mój problem rozwiązany.

W Route.config

przestrzenie nazw: new [] {„Appname.Controllers”}

Odkryliśmy, że wystąpił ten błąd, gdy w naszej kompilacji wystąpił konflikt, który pojawił się jako ostrzeżenie.

Nie otrzymaliśmy szczegółów, dopóki nie zwiększyliśmy Visual Studio -> Narzędzia -> Opcje -> Projekty i rozwiązania -> Kompiluj i uruchamiaj -> Szczegółowość wyników budowania projektu MSBuild do Szczegółowa.

Nasz projekt jest aplikacją sieciową .net v4 i wystąpił konflikt między System.Net.Http (v2.0.0.0) i System.Net.Http (v4.0.0.0). Nasz projekt odwoływał się do wersji v2 pliku z pakietu (dołączonego za pomocą nuget). Kiedy usunęliśmy referencję i dodaliśmy referencję do wersji v4, kompilacja działała (bez ostrzeżeń) i błąd został naprawiony.

Inną odmianą tego błędu jest użycie opcji resharper i niektórych opcji „automatycznego” refaktora, które obejmują zmianę nazwy przestrzeni nazw. Oto co mi się przydarzyło. Aby rozwiązać problem z tego rodzaju folderem usuwania scenariuszybin

Kliknij projekt prawym przyciskiem myszy i wybierz opcję wyczyść projekt. Albo całkowicie opróżnij katalog bin, a następnie ponownie go skompiluj. To powinno usunąć wszelkie resztki zespołów z poprzednich kompilacji

Problem pojawia się także w jednej aplikacji. W takim przypadku zaznacz to pole wyboru podczas publikowania aplikacji

Jeśli to mogłoby pomóc innym, napotykam również ten błąd. Problem został spowodowany przez niepoprawne odniesienie na mojej stronie internetowej. Z nieznanego powodu moja strona odsyłała do innej witryny w tym samym rozwiązaniu. A kiedy usunę to złe odniesienie, wszystko zaczęło działać poprawnie.

Jeśli pracujesz w Episerver lub innym CMS-ie opartym na MVC, możesz stwierdzić, że ta konkretna nazwa kontrolera została już zgłoszona.

Zdarzyło mi się to podczas próby utworzenia kontrolera o nazwie FileUpload.

miałem do czynienia z podobnym problemem. a głównym powodem było to, że miałem tego samego kontrolera w dwóch różnych obszarach. po usunięciu jednego z nich działa dobrze.

mam to dla ciebie pomocne.

Mam dwa projekty w jednym rozwiązaniu o tej samej nazwie kontrolera. Usunąłem drugie odniesienie do projektu w pierwszym projekcie i problem został rozwiązany

Odkryłem, że ten błąd może wystąpić w tradycyjnej witrynie ASP.NET podczas tworzenia kontrolera w katalogu innym niż App_Code (czasami Visual Studio temu zapobiega).

Ustawia typ pliku na „Kompiluj”, podczas gdy każdy kod dodany do „App_Code” jest ustawiony na „Treść”. Jeśli plik zostanie skopiowany lub przeniesiony do kodu App_Code, wówczas będzie on nadal ustawiony jako „Kompiluj”.

Podejrzewam, że ma to coś wspólnego z działaniem projektu witryny, ponieważ projekty strony internetowej nie mają żadnej operacji kompilacji. Oczyszczenie folderu bin i przejście do „treści” wydaje się naprawiać.