Publikowanie witryn ASP.NET w sieci Web a kopiowanie?

Question

Mam do czynienia z wieloma problemami z Publishing, jak wtedy, gdy trzeba wprowadzić małe zmiany w kodzie, czasami wygenerowany plik DLL (plik dll na przykład z default.aspx.CS po opublikowaniu) nie może zostać rozpoznany przez IIS, mówiąc, że kod jest błędny lub coś. Przepraszamy za nie pamiętanie dokładnego komunikatu o błędzie. Mam nadzieję, że wiesz o co mi chodzi w tym momencie.

Dlatego zwykle wykonuję prostą operację Copy Paste zamiast publikowania.

Czy możesz mi powiedzieć, czego mi brakuje, NIE używając metody Opublikuj? Jak lepiej publikować? Lub który wolisz, dlaczego?

Zasadniczo jest to sytuacja za i przeciw.

Dziękuje

Answer 1

Cóż, to zależy co masz na myśli przez „kopia”:

Z Publishing masz opcje do pre-compile całość lub część swojej aplikacji. Możesz publish umieścić w lokalnym folderze w systemie plików (zamiast docelowego/hosta), a następnie skopiować zaktualizowany plik (i) (tylko). Jeśli zmieniasz kod "za" (C#/vb code), oznacza to, że prawdopodobnie będziesz musiał tylko "skopiować"/zastąpić dlls. Nie trzeba dodawać, że jeśli wprowadziłeś zmiany "treści" (html/razor/script/etc), musisz je również skopiować/zastąpić.

Jeśli dopiero zaczynasz wdrażanie, możesz po prostu skopiować/nadpisać "wszystko" , co jest najbezpieczniejszym sposobem na przejście na. Gdy zdobędziesz więcej doświadczenia, "rozpoznasz" zasoby, które musisz zaktualizować (jeden lub kilka dlls i/lub kod treści, zamiast "wszystko"). Nie ma w tym żadnej magii, zwykle jest to kwestia po prostu spojrzenia na znacznik czasu pliku dll/pliku po tym, jak masz published (lokalnie) lub rebuild swoją aplikację internetową.

Polecam wykonanie local publish, dzięki czemu można zobaczyć, co jest rzeczywiście potrzebne na serwerze. Pliki publikowane w lokalnym systemie plików/folderze muszą znajdować się na twoim hoście/serwerze. Spowoduje to wizualizować i usunąć cokolwiek „tajemnica” nie jest Publishing:

• zobaczysz co jest rzeczywiście potrzebne (na serwerze) w porównaniu do tego, co nie jest
• zobaczysz timesstamps który plików pomóc ci rozpoznać, które pliki zostały faktycznie zmienione w porównaniu z tymi, które nie zostały zmienione (i dlatego nie wymagają aktualizacji).
• Gdy już się go zawiesi, nie będziesz musiał "kopiować"/ftp "wszystkiego" i po prostu aktualizować pliki, które zostały zmodyfikowane (tylko).

So „kopia” może oznaczać wyżej, lub jeśli mówisz można po prostu skopiować cały kod rozwoju (surowe (vb/cs)html/cs/vb) do hosta, to oznacza, że ​​Twoja strona będzie dynamically compiled jak potrzebna jest każdy zasób/requested (nic nie jest pre-compiled). Również "łatwe", ale tracisz pre-compilation, co oznacza, że ​​istnieje opóźnienie, gdy każda twoja strona internetowa jest wymagana/potrzebna (ASP.net musi dynamicznie skompilować). Dodatkowo ujawniasz również kod źródłowy na serwerze. To może nie znaczyć wiele w zależności od twojej sytuacji, ale jest jeszcze jedna rzecz do rozważenia.

Oto więcej info on pre-compilation and options.

Answer 2

Zakładając uważamy strony aspx i jego kod aspx.cs za plik, istnieją trzy alternatywne sposoby wdrażania swojej strony:

1. Można kopiować zarówno do IIS. Plik aspx zostanie skompilowany do pliku .cs po pierwszym żądaniu, a następnie oba pliki .cses zostaną skompilowane do temp .dll
2. Możesz "opublikować" do iis, to skompiluje kod za klasą do .dll, ale skopiuje aspx nietknięty. Plik aspx zostanie przetłumaczony na .cs, a następnie na .dll na pierwsze żądanie.
3. Możesz "opublikować" witrynę, a następnie ręcznie ją skompilować przy pomocy aspnet_compiler. Publishing skompiluje kod do .dll tak jak poprzednio, ale wtedy prekompilacja usunie twoje pliki .aspx, usuwając ich zawartość i przenosząc skompilowany kod do innego .dll.

Wszystkie trzy modele mają swoje wady i zalety.

Pierwsza z nich jest najłatwiejsza do aktualizacji przyrostowo, ale jednocześnie jest najbardziej otwarta na niechciane modyfikacje.

drugie jest również łatwe, mogą być wywoływane z vs, zamyka możliwość pewnych niechcianych modyfikacji na serwerze, ale .aspxses nadal potrzebują czasu, aby skompilować na pierwsze żądanie

trzecie zajmuje czas i pewne czynności manualne ale zapobiega jakimkolwiek zmianom, a także przyspiesza rozgrzanie witryny, ponieważ kompilacja zasobów nie jest konieczna. Świetnie nadaje się do współdzielonych środowisk.