Po zaktualizowaniu rozwiązania do platformy .NET 4.5, codzienne wdrażanie przestało działać

Question

Z sukcesem aktualizujemy naszą stronę internetową poświęconą rozwojowi codziennie, używając msdeploy z TFS2010.

To działało bez zarzutu, dopóki nie zaktualizowaliśmy VS2012, naszej aplikacji z .NET Framework 4.0 na 4.5 i ASP.NET MVC z wersji 3.0 na 4.0. Wygląda na to, że wszystko jest dobrze, a złożenia są rozmieszczone, ale nic nie zostało faktycznie wdrożone.

Zajmuję się tym od dwóch dni i nie mogę zrozumieć, dlaczego tak się dzieje, a teraz brakuje mi pomysłów.

Poniżej znajduje się część mojego skryptu kompilacji w taki sposób, w jaki działała przed aktualizacją.

<MSBuild 
       Projects="$(SolutionRoot)\My.Web\My.Web.csproj" 
       Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True" 
       ContinueOnError="False" 
       /> 

Po zakończeniu aktualizacji został zainicjowany i mój problem odkrył używaliśmy Web Deploy 2.0 ale teraz mamy przeniesieni do Web Deploy 3.0. Upewniłem się także, że budujemy z ToolsVersion="4.0".

AKTUALIZACJA -

msbuild.exe/p: AllowUntrustedCertificate = True /p: AuthType = Podstawowe /p: Konfiguracja = Dev /p: CreatePackageOnPublish = True /p: DeployIisAppPath = dev .myweb /p: DeployOnBuild = True /p: DeployTarget = MsDeployPublish /p: MSDeployPublishMethod = WMSvc /p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd /p: Nazwa użytkownika = Nazwa użytkownika /p: Hasło = hasło /p: UseMsdeployExe = True E: \ \ 1 \ Buduje cokolwiek \ Daily_Build \ Sources \ My.Web \ My.Web.csproj

Teraz Próbowałem też uruchomić powyższego polecenia msbuild z naszych TFS i bez odpowiedzi co całkowicie mnie frustruje. Nic w dzienniku zdarzeń TFS, nic w pliku dziennika bez względu na gadatliwość ... Jakieś pomysły?

To działa przy użyciu msdeploy directy jak poniżej;

<Exec Command="&quot;C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe&quot; -verb:sync -source:contentPath=&quot;E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj&quot; -dest:contentPath=&quot;E:\dev.my.web&quot;,computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True" 
       ContinueOnError="false" /> 

-

UPDATE 2 - Wydaje Microsoft dodał czek na jaki rodzaj projektów, które są do publikacji projektów i naszą aplikację internetową nie są, ponieważ Typ wyjścia jest Biblioteka klas. Jest to poprawne w wersji 4.0, ale najwyraźniej nie dla wersji 4.5.

Każdy ma pomysł, co zrobić, aby działał ponownie? Czy muszę zmienić typ projektu? Utwórz pakiet publikacyjny z góry, a następnie rozmieść go? Albo co?

-

Każdy inny, który miał ten sam problem? Czy znalazłeś rozwiązanie do udostępnienia?

Czy może być problem z wersją MSBuild?

Answer 1

Oto, co polecam.W VS2012 ułatwiliśmy automatyzację publikowania projektów internetowych za pomocą profili publikowania tworzonych w oknie dialogowym publikowania. W twoim przypadku utwórz nowy profil MSDeploy. Po utworzeniu tego profilu zapiszemy ustawienia w pliku w obszarze Właściwości \ PublishProfiles (lub My Project \ PublishProfiles for VB). Rozszerzenie tego pliku będzie .pubxml. Te pliki są w rzeczywistości plikami MSBuild, które można dostosować w razie potrzeby. Możesz także nadal korzystać z okna publikowania. Hasło zostanie zapisane w pliku .user i zaszyfrowane tak, że tylko Ty możesz je odszyfrować.

Po utworzeniu tego profilu można opublikować za pomocą poniższego polecenia, jeśli budujesz plik .sln.

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> 

Jeśli budujemy .csproj/.vbproj to trzeba podkręcić ten kawałek w następujący sposób

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0 

Więcej na temat dlaczego VisualStudioVersion jest wymagane w http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.

Gdy to zrobisz, będziesz w stanie budować + publikować tak jak wcześniej. Do tej pory dostarczyliśmy wszystkie nowe funkcje publikowania w Internecie dla VS2010 w pakiecie Azure SDK https://www.windowsazure.com/en-us/develop/net/#.

Również w pytaniu zauważyłem, że określasz pewne niestandardowe właściwości, takie jak MvcBuildViews. Możesz teraz umieścić te właściwości bezpośrednio w profilu publikowania (pliku .pubxml), jeśli chcesz. Oczywiście nadal możesz przekazać je w wierszu poleceń, jeśli ma to więcej sensu dla twojego scenariusza.

Więcej informacji na ten temat pod adresem http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.

Jeśli spojrzeć na podejście, które mieliśmy dla programistów do automatyzacji publikacji, to określenie właściwości i celów do wykonania podczas kompilacji. Problem z tym podejściem polega na tym, że ogranicza to naszą zdolność do ulepszania korzystania z publikacji internetowych. W nowym wydaniu wprowadziliśmy abstrakcję, profil publikowania, który pozwala nam zmienić podstawowe cele potoku publikowania w Internecie, a twoje skrypty automatyzacji będą nadal działać. Mam nadzieję, że od tego momentu nie będziesz musiał ponownie odwiedzać tego problemu.

Answer 2

Miałem dzisiaj ten sam problem. Próbowałem też automatycznie wdrożyć aplikację internetową .NET 4.5 na komputerze, na którym nie zainstalowano programu Visual Studio 2012. Było jednak kilka drobnych różnic w mojej sytuacji: używałam TeamCity zamiast TFS, a nasze rozwiązanie zostało stworzone z .NET 4.5, a nie tym, które zostało uaktualnione z .NET 4.0.

Mimo to miałem ten sam problem opisany. Użyłbym MSBuild do zbudowania aplikacji internetowej i wdrożenia jej do IIS, w bardzo podobny sposób. To podejście działało dobrze na mojej maszynie dev. Jednak, gdy uruchomiłem MSBuild na serwerze CI, to całkiem szczęśliwie zbudowałem aplikację internetową, ale zatrzymało się po tym: brak błędów, brak ostrzeżeń, nic, tylko komunikat, że kompilacja się powiodła. Nie było najmniejszej wzmianki o próbie wdrożenia aplikacji w usługach IIS.

Wygląda na to, że MSBuild nie ma odpowiednich celów do wykonania wdrożenia WWW. Poprawka polegała na skopiowaniu folderu C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web z mojego urządzenia dev do serwera CI, skopiowanie go do tego samego miejsca na serwerze CI, co na moim komputerze.

Kiedy to zrobiłem, MSBuild zaczął narzekać, że potrzebuje aplikacji Web Deploy 3.0, ale zostało to naprawione dość łatwo. Po zainstalowaniu go również na serwerze CI, MSBuild z powodzeniem wdrożył aplikację internetową.

Answer 3

Aby przedłużyć Luke Woodward's answer:

Ja również okazało się, że wdrożenie C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ z mojego komputera lokalnego do serwera kompilacji było naprawić.

Jednak prawdziwą poprawką jest zainstalowanie Microsoft Web Developer Tools w ramach instalacji VS 2012, która utworzy ten folder, między innymi. To odnosi się do sprzeciwu licencyjnego Ieppie.

testowałem to przez ...

1. Usuwanie C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
2. Uruchamianie instalatora VS 2012 i dodawanie narzędzi MS Web Dev.
3. Sprawdzanie, czy po instalacji ponownie się pojawił C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\.