[singollo]

Czasami to trudno zdefiniować problem tak, żeby się zmieścił w okienku googla ;)
Mam dwa projekty w jednym rozwiązaniu. Jeden z nich to główny projekt (niech będzie Product.Web - utworzony jako Web App MVC), drugi w zasadzie wyłącznie obsługuje pewnego rodzaju API (nazwijmy go Product.API - utworzony jako Web API). "W zasadzie", ponieważ mam w tym projekcie akcję, która powinna zwrócić normalny kod html. Wynika to z logiki aplikacji - Product.API nie tyle obsługuje API, co pewien proces biznesowy, który zazwyczaj używa JSON zamiast kodu HTML.
Problem w tym, że aplikacja szuka widoku przypisanego do tej akcji w katalogu Views projektu głównego Product.Web - zamiast przeszukać katalog Views projektu Product.API
To się na pewno gdzieś ustawia, ale nie mam pojęcia gdzie :) Framework Net Core 2.0
#csharp #netcore #aspnetcore

[h.....u]

@singollo: ciężko zrozumiec o co chodzi ( ͡° ͜ʖ ͡°)

MVC od WebApi różni się tym, że zwraca kod HTML zamiast plain jsona.

Wygląda na to, że routing źle kieruje, albo strzelasz nie do tego kontrolera, który byś chciał, albo masz w nim bład, albo tysiąc innych rzeczy. Z fusów się ciężko wróży :)

[singollo]

@hauhauu: kontroler jest prawidłowy.
Mam coś takiego:
/Project.API/Controller/HtmlController.cs (a w nim akcja CosTam i ustawiony Route("/html/costam"))

/Project.API/Views/Html/Index.cshtml

Przy wywołaniu http://localhost:5000/html/costam dostaję:

InvalidOperationException: The view 'CosTam' was not found. The following locations were searched:

/Views/Html/CosTam.cshtml

/Views/Shared/CosTam.cshtml

Ale jeśli utworzę widok w lokalizacji:

/Project.Web/Views/Shared/CosTam.cshtml

To wszystko działa.

Acha - projekt główny to oczywiście Project.Web, pozostałe projekty są w zależnościach tego projektu. Dla wywołań API nie stanowiło to dotychczas problemu.

[h.....u]

@singollo: jak Ci nikt nie pomoże gdzieś do 20, to się odezwę, ale muszę znikać teraz ;]

[singollo]

@Priya: nie, chciałbym, żeby akcja z projektu Product.API szukała widoku we własnym projekcie. Route jest przypisane do akcji, więc wydaje mi się to logiczne.

[Priya]

@singollo: Już rozumiem. Może podaj całą ścieżkę do widoku. Routing dotyczy konfiguracji controllerów i akcji, a nie widoków.

[meetom]

@singollo: Mechanizm działa tak, że szuka w katalogu głównym aktualnie działającej aplikacji. "Katalogi" o których mówisz funkcjonują bardziej dla Visual Studio niż dla samej apki.
Miałem raz podobny "problem" - rozwiązaniem było tworzenie widoków w aplikacji głównej (w sumie powstało przez przypadek, ale okazało się, że bez problemu działa - nawet jeżeli nie mają do siebie referencji). Druga opcja - w jakimś PostBuildEvent możesz skopiować cały zawartość Views z jednego projektu

[singollo]

@meetom: do dupy strasznie :( podział na projekty odpowiada u nas mniej-więcej podziałowi na odpowiedzialność, nie tylko od strony technicznej ale i ludzkiej. Żebyśmy sobie wzajemnie po projektach nie grzebali ;)
A tu się okazuje, że musimy mieć projekt-śmietnik, w którym w widokach będzie trzeba dorabiać jakieś wewnętrzne podziały, żeby ludzie sobie nie nadpisali plików :(

[meetom]

@singollo: Popatrz na to tak, że po publikacji na jakimś IIS, projekt "Project.API" trafi po prostu do jednej dllki w podkatalogu "bin". Dlatego jeżeli będzie szukał czegoś w ../Views/xxx to będzie to podkatalog z głównego projektu "Product.Web"