Azure AppService deploy.cmd mit der falschen Datei

Question

Ich versuche, die kontinuierliche Bereitstellung auf einem Testserver in Azure zu konfigurieren. Die App ist eine ASP.Net-Anwendung, aber in diesem Fall sollte das eigentlich keine Rolle spielen.

Mein Build-Prozess (Team-Stadt) erzeugt einen Ordner, der alles zur Bereitstellung benötigt (abzüglich einiger Verbindungs-String-Informationen). Wenn Sie IIS auf dieses Verzeichnis verweisen, funktioniert es großartig. Wenn Sie dieses Verzeichnis mit FTP bis Azure verbinden, funktioniert es auch.

Ich verfolge jeden dieser Builds in Git und schiebe sie auf Github. Daher versuche ich, die Bereitstellungsoption Azure für die Bereitstellung über GitHub zu verwenden. Alles ist in git. Der Ordner/bin ist enthalten.

Kudu sollte nichts anderes tun als einen Pull von Git und alle Dateien auf wwwroot kopieren.

Also habe ich meine .deployment Datei gesetzt, dies zu sein: obwohl

[config] 
project = . 

Jedes Mal, wenn ich das tun, wird die Bereitstellung mir die Nachricht gibt:

Using cached version of deployment script (command: 'azure -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --aspWAP "D:\home\site\repository\MyProj.csproj" --no-solution'). 

Und es läuft einige generische automatisch generierte deploy.cmd.

Wenn ich die deploy.cmd aus dem Cache lösche, erzeugt es einige generische.

Und am wichtigsten ist dabei, dass die FALSCHE MONTAGE VERTEILT WIRD !!

Meine App hängt von System.Web.Helpers.dll ab. Die richtige Version dieser DLL befindet sich in GitHub. Ich habe das mehrmals verifiziert.

Kudu greift jedoch ein ÄLTERES von NuGet auf und stellt es bereit. Und natürlich bekomme ich den gefürchteten YSOD-Fehler, dass ich diese Datei nicht laden kann.

Was muss ich tun, damit Kudu einfach die Dateien aus meinem Github-Repository in wwwroot kopiert und sonst nichts?

Answer 1

Ich beendete es von Hand zu bearbeiten, um die automatisch generierte deploy.cmd-Datei zu bearbeiten, die unter \home\site\deployments\tools\deploy.cmd in Kudu lebt.

bemerkte ich aus den 2 automatisch generierte Zeilen:

:: 1. Restore NuGet packages 
:: 2. Build to the temporary path 

(kommentiert aus all dem Code unter ihnen auch)

Und dann den dritten Abschnitt von Hand bearbeitet läuft Kudu sync aus der DEPLOYMENT_SOURCE anstelle der Temp-Datei wie folgt:

:: 3. KuduSync 
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
    call :ExecuteCmd "%KUDU_SYNC_CMD%" -v 50 -f "%DEPLOYMENT_SOURCE%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd" 
    IF !ERRORLEVEL! NEQ 0 goto error 
)