MSDeploy wyrzuca dziwny błąd: dane strumieniowe pliku xxxxx.dll nie są jeszcze dostępne

Question

Wdrażam wiele projektów .Net na różnych serwerach. Aby to zrobić, mój zespół używa TFS do budowania, a następnie z szablonu kompilacji wywołującego skrypt ps1, który używa msdeploy do wypychania na wszystkie różne serwery. To wszystko jest bardzo owocne i nie, nie mam teraz możliwości przejścia na coś innego. Ten proces działa od miesięcy bez żadnych problemów.

Dziś wdrożyć powiodło się kilka razy z rzędu z kilku różnych błędów. Że sam mnie dezorientuje (i nie mogą być istotne), ale teraz jestem coraz jeden konsekwentnie jest taka:

Wystąpił błąd, gdy żądanie zostało przetworzone na komputerze zdalnym. Dane strumienia "C: \ Builds \ SomeDirectory \ obj \ Debug \ Package \ PackageTmp \ AReferencedProject.dll" nie są jeszcze dostępne.

Ten błąd się dzieje, gdy mój skrypt uruchamia msdeploy. Plik dll jest używany przez usługę Windows, ale usługa jest zatrzymana (o ile mogę powiedzieć - zatrzymanie usługi nie rzuca żadnych błędów) i biblioteka dll nie jest "tylko do odczytu". Plik DLL istnieje na komputerze, który jest budowany/wdrażany, a także na maszynie, która jest wdrażana.

Odkryłem, że mogę uniknąć tego błędu, jeśli usunę plik DLL, który "nie jest dostępny" z serwera, na którym działam, ale problem pojawia się z powrotem przy każdym kolejnym wdrożeniu, chyba że ręcznie usunę tę bibliotekę przed każdym wdrożeniem .

Widziałem this problem ale nie pcham do Azure, tylko do Windows Server 2008. Czy ktoś wie, dlaczego Microsoft Web Deploy (msdeploy) rzuciłby ten błąd?

Answer 1

Miałem ten sam problem. Wypróbowałem kilka razy wdrożenie z tym samym błędem.

Recykling puli aplikacji na serwerze rozwiązał problem, aby ponownie uruchomić normalne wdrożenie.

Answer 2

mam cierpi na dokładnie tym samym numerze jak ty dzisiaj i po natknąć swoje pytanie bez odpowiedzi, zaczął ciągnąć moje włosy ... Jest tak kilka artykułów lub sugestie w tej kwestii, że prawie poddał się!!

Jednak udało mi się rozwiązać problem dla mnie, więc jestem delegowania moje rozwiązanie, aby pomóc sobie i nikomu, kto cierpi z powodu tego problemu.

Z jakiegoś powodu wydawało się, że moja witryna & AppPool w IIS została nieco zmącona i zaczęła zgłaszać błąd opisany w powyższym pytaniu. Aby rozwiązać ten problem, usunąłem oryginalną witrynę (Zatrzymałem witrynę i AppPool), utworzyłem zupełnie nową witrynę i AppPool z tymi samymi ustawieniami, opublikowanymi za pomocą WebDeploy i teraz wydaje się, że zachowuje się ponownie.

To może nie działać dla innych, ale mam nadzieję, że będzie to dać ludziom coś innego do spróbowania.

Answer 3

Problem ten występuje zgodnie z SQLite.Interop.dll (używane przez ELMAH w naszej aplikacji internetowej). Jak najlepiej mogę powiedzieć, problem związany jest z faktem, że DLL SQLite.Interop.dll jest w użyciu przez nasza aplikacja internetowa poprzez ELMAH iz jakiegoś powodu ta biblioteka DLL nie jest kopiowana w tle. Rozwiązanie, którego używamy, polega na tym, że recommended here odzyskuje pulę aplikacji po każdym wdrożeniu. Nasze polecenie brzmi:

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site/ourApp",computerName="DeployComputer" 

Pozwala to na kolejne msdeploy, które synchronizuje nasz pakiet wdrażania, aby odnieść sukces. Ktoś odpowiedział na to forum, sugerując również użycie "-enableRule: AppOffline", którego nie musieliśmy wypróbowywać.