Dlaczego komponenty altanowe są zainstalowane na wwwroot

Question

Minęło trochę czasu odkąd bawiłem się programem ASP.NET 5, więc zaskoczyło mnie, że komponenty altanowe są teraz domyślnie umieszczane w folderze wwwroot\lib. Jest to przypadek, ponieważ pliku .bowerrc:

{ 
    "directory": "wwwroot/lib" 
} 

We wcześniejszych wersjach składniki altana są przechowywane w folderze ./bower_components, który nadal ma większy sens dla mnie.

Spodziewałbym się, że potrzebuję zadania gulp/grunt (z wiredep na przykład) do budowania i kopiowania moich plików JavaScript i CSS do folderu wwwroot.

Najwyraźniej coś mi brakuje, ale nie mogę się z tym pogodzić ani znaleźć odpowiednich informacji na ten temat.

Dlaczego chcę, aby wszystkie moje komponenty altanowe (w tym źródła) w folderze `wwwroot \ lib ', szczególnie podczas wdrażania i jaki jest pożądany przepływ pracy podczas wdrażania mojej aplikacji sieci Web Asp.NET 5?

Answer 1

Myślę, że powodem, dla którego folder bower_components został porzucony i teraz korzysta z wwwroot/lib, jest to, że bez względu na to, czy w statycznych plikach deweloperskich, czy też produkcyjnych muszą żyć poniżej wwwroot, w przeciwnym razie po każdej edycji pliku należy ponownie uruchomić Taskrunner, aby skopiować plik poniżej wwwroot. Jest to bardziej wydajny przepływ pracy, jeśli zarówno wersja deweloperska, jak i wersja produkcyjna, znajdują się gdzieś poniżej wwwroot. w ten sposób można edytować i odświeżać stronę, zamiast edytować uruchom taskrunner, a następnie odświeżyć stronę.

Proponuję, aby pliki z procesem chciały przejść do innego folderu, na przykład wwwroot/js, podczas tworzenia minifikowanych/przetworzonych wersji produkcyjnych plików.

Następnie folder wwwroot/lib może nawet zostać wykluczony z publikowania, ponieważ tam będą istniały tylko wersje skryptów biblioteki.

Myślę, że moje własne niestandardowe skrypty, które nie są komponentami altankowymi, prawdopodobnie nie powinny znajdować się pod wwwroot/lib, więc może umieszczę te niemineralizowane pod wwwroot/dev i przetworzę wszystkie elementy produkcji pod wwwroot/js tak, że w produkcji I instaluj tylko folder wwwroot/js, który ma wersję produkcyjną minified/combined files. Więc w zasadzie tworzymy własne pakiety w ten sposób.

Nowe znaczniki środowiskowe i i skrypt taghelper pozwalają łatwo wskazać na różne lokalizacje plików dla dev i produkcji, jak widać na tym przykładzie:

<environment names="Development"> 
    <script src="~/lib/jquery-validation/jquery.validate.js"></script> 
    <script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.js"></script> 
</environment> 
<environment names="Staging,Production"> 
    <script src="//ajax.aspnetcdn.com/ajax/jquery.validation/1.11.1/jquery.validate.min.js" 
      asp-fallback-src="~/js/lib/jquery-validation/jquery.validate.js" 
      asp-fallback-test="window.jquery && window.jquery.validator"> 
    </script> 
    <script src="//ajax.aspnetcdn.com/ajax/mvc/5.2.3/jquery.validate.unobtrusive.min.js" 
      asp-fallback-src="~/js/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js" 
      asp-fallback-test="window.jquery && window.jquery.validator && window.jquery.validator.unobtrusive"> 
    </script> 
</environment> 

Więc trzeba łatwe sposoby wykorzystania CDN w produkcja. Zauważ, że w przypadku plików non cdn nie możesz wskazać nigdzie innego niż wwwroot lub jakiegoś folderu poniżej, tak więc posiadanie plików w folderze bower_components poza wwwroot nie jest miejscem, w którym możesz wskazywać skrypty, więc nie ma sensu umieszczać tam plików.

Podczas tworzenia skryptu linków do wersji deweloperskiej moich własnych skryptów chciałbym użyć nowego atrybutu taghelpera asp-append-version = "true", który dołącza skrót adresu pliku do adresu URL, zapewniając, że poprzednia pamięć podręczna przeglądarki jest ominięty za każdym razem, gdy plik jest edytowany lub zmieniany. I dzieje się to bez potrzeby uruchamiania taskrunner, po prostu edytuję i odświeżam stronę.

Podsumowując, wszystkie skrypty poniżej wwwroot to lepszy przepływ pracy niż posiadanie ich gdzie indziej i konieczność uruchomienia Taskrunnera, aby przenieść je po każdej edycji.Jeśli nie chcesz instalować wszystkich dodatkowych elementów z poziomu poniższego pliku wwwroot/lib, musisz przetworzyć to, co chcesz, do innego folderu za pomocą narzędzia taskrunner, tak samo, jak byś zrobił, gdyby znajdował się poza wwwroot w folderze bower_components, ponieważ użyli być na początku betas. I wyklucz wwwroot/lib z publikowania z publishExclude w project.json swojej aplikacji internetowej.

Answer 2

Zostały one przeniesione tam, ponieważ Microsoft był świadkiem wielu zamieszania przez programistów .NET, którzy nie byli przyzwyczajeni do nowego oprzyrządowania. Uprościli to dla programistów .NET, wstawiając te komponenty do wwwroot, zamiast uruchamiać zadanie, aby je przenieść. Moje źródło tego (i wyjaśnienie, aby zmienić to na poprzednie zachowanie) pochodzi od (pracownik MS) - od Scotta Hanselmana blog post.