How to Deploy a .Net web app to Azure using Powershell - powershell

I have a "Web app" in Azure to which I deploy/publish a .Net web application using Visual Studio. (Build --> Publish), and it works.
I want to be able to deploy/publish my application using a Powershell script. I got the following script to work for the build portion:
CMD> "c:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe" WebApplication1.sln
To make it also deploy, I need to add a few parameters:
CMD> "c:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe" WebApplication1.sln /p:DeployOnBuild=true /p:PublishProfile="C:\Users\jgodse\Documents\Visual Studio 2015\Projects\WebApplication1\WebApplication1\Properties\PublishProfiles\jg-7-web-app-1 - Web Deploy.pubxml" /p:Configuration=Release
I got an error:
Build FAILED.
"c:\Users\jgodse\Documents\Visual Studio 2015\Projects\WebApplication1\WebApplication1.sln" (default target) (1) ->
"c:\Users\jgodse\Documents\Visual Studio 2015\Projects\WebApplication1\WebApplication1\WebApplication1.csproj" (default target) (2) ->
(MSDeployPublish target) ->
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4295,5): msdeploy error ERROR_USER_UNAUTHORIZED: Web deployment task failed. (Connected to the remote computer ("jg-7-web-app-1.scm.azurewebsites.net") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.) [c:\Users\jgodse\Documents\Visual Studio 2015\Projects\WebApplication1\WebApplication1\WebApplication1.csproj]
0 Warning(s)
1 Error(s)
I am obviously missing my Azure credentials (seeing as Visual Studio was able to capture them), and I am also not running in Powershell.
So I took the entire command and put it into a file called deploy.bat, opened up a Powershell window and did the following:
PS> Login-AzureRmAccount
(I typed in my user/password in the GUI popup).
PS> cmd /c .\deploy.bat
The build was fine, but I got the same error when trying to publish. I guess that the Azure credentials did not carry through when shelling out to the CMD program.
How do I use Powershell to call MSBuild on my .Net project to publish to an Azure web app?

You can use your existing .pubxml file but you need the password in order to be able to deploy. There are several ways to get it. The most obvious one is to get it from the portal by navigating to the blade of you Web app and then clicking on "More" and finally on "Get publish profile"
This file contains all sorts of data but the one that you need is called userPWD - this is the password that you need to use. Copy the password and add it to your MsBuild command:
CMD> "c:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe" WebApplication1.sln /p:DeployOnBuild=true /p:PublishProfile="C:\Users\jgodse\Documents\Visual Studio 2015\Projects\WebApplication1\WebApplication1\Properties\PublishProfiles\jg-7-web-app-1 - Web Deploy.pubxml" /p:Configuration=Release /p:Password="Value of userPWD"
Obviously storing this value in your build scripts is not recommended. What you could do is download the publish settings using Powershell (Get-AzurePublishSettingsFile), extract the userPWD value, pass it to MsBuild to publish your app, and finally clean everything up.
There are various ways to implement you build infrastructure and what I have proposed might not be the best solution for you but it is up to you to experiment and decide what works best for you.
Some resources:
Automate Everything (Building Real-World Cloud Apps with Azure) - This one uses ASM instead of Resource Manager but you can easily tweak it to use ARM
Using Windows PowerShell scripts to publish to dev and test environments
Hope this helps.

Related

Batch build fails with vsts

I am trying to build IAR Embedded workbench code using VSTS batch script. The .bat file is located in TVFC repository hosted by Microsoft.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\common\bin\IarBuild.exe" "C:\embedded_programming\lesson2\project.ewp" -build Debug -log all
The builds terminates with an error "The system cannot find the path specified" as shown in linked image:
It don't know what I am doing wrong since I am new to VSTS but it works fine with Command Line Interface.
Please help!
Thanks a lot :)
If you're using the hosted agent, that's the problem. Your software isn't installed on the hosted agent, and there's no way for you to install it since the hosted agent is provided by Microsoft.
You'll need to set up a private agent that runs on a machine that has the appropriate software installed.

Deploy with New-AzureWebsiteJob and dotnet core?

I have an azure webjob that I can deploy fine through visual studio, right click publish etc. all that is fine. I am using Microsoft.Azure.Webjobs beta 3.0 against .NET Core 2.0. Of course when that project is built it creates a set of .dlls and no direct executable as is normal for .net core.
Now I want to create an integration test suite which will deploy my webjob to azure with Powershell, using New-AzureWebsiteJob. When I publish this way I get
New-AzureWebsiteJob : No runnable script file was found.
As far as I can gather my job file should have either: batch (.exe/.cmd/.bat), bash (.sh), javascript (.js as node.js), php (.php) or python (.py). If so what magic does VS do, and how should I go about scripting this?
Ok, found the solution. It is, however, inelegant. Create a file run.bat or similar containing
#ECHO OFF
dotnet YourLibraryName.dll
and include that in any zip file uploading with the cmdlet. More here

Visual Studio Online / Azure stopping and starting web applications using Powershell

I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.

Invalid file names when trying to deploy SSDT project with TeamCity 8

I am trying to deploy Visual Studio 2012 SSDT project to Sql Server using TeamCity 8 and MSBuild Publish task but the deployment fails.
When I look at TeamCity logs and use /v:diag switch in my build configuration I see that for unknown reason MSBuild searches for MyProject.sqlproj.publish.sql and for MyProject.sqlproj.dacpac files.
The exact error:
[SqlPublishTask] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(1233, 5): File "C:\Program Files\TeamCity\buildAgent\work\abf8bc05a2cfe7f\*MyProject*\bin\Debug\*MyProject*.sqlproj.dacpac" does not exist.
The correct .sql and .dacpac files get generated (without the .sqlproj in the middel) in buildAgent/work/identificator/*MySolution*/MyProject/bin/Debug folder.
My TeamCity build step is configured as follows:
Runner type: MSbuild
Build file path: MyProject/*MyProject*.sqlproj
MSBuild version: 4.5
MsBuild ToolsVersion: 4.0
Run platform: 4.0
Targets: Publish
Command line parameters: /p:SqlPublishProfilePath="Debug.publish.xml" /p:Configuration=Debug
If I execute this from commandline I get no errors.
Any ideas on how can I configure TeamCity to search for correct files or configure my project to generate the files that TeamCity is searching for.
Or is my plan to use MSBuild's Publish task futile and I should utilise sqlpackage.exe instead?
UPDATE
After spending almost three days trying to figure this out I gave up and used sqlpackage.exe which works like a charm.
But I would still be interested in an answer though, passing paths to executables in build servers seems a bit crude way to accomplish things.
I had a similar issue and came to the conclusion that the way TeamCity produces "pseudo-project" files with *.teamcity suffixes is confusing something in the MSBuild/SSDT target chain.
I simply replaced the MSBuild runner build step with a pure Command Line step and the problem went away.
We lose the user friendliness of the TeamCity MSBuild runner configuration, but if it works, it's a compromise I'm willing to make.
Note - we are running TeamCity 7 - I am not sure if this has been addressed in later versions.
I found out you can set a System Property named "system.SqlTargetName" on the build configuration to override the default value.
Setting this to your project name without the ".sqlproj" makes the error go away.

Automatic installer deploy to remote server using TeamCity and MSBuild

I'm having a .net WPF project that compiles to a bunch of dlls. I also have another project that compiles all the dlls and creates an installator exe.
I am also using TeamCity to automatically do those tasks for me with a press of a button.
The problem is that I want to have a separate TeamCity build configuration intended to automatically copy the result installator exe to a number of remote machines, each having specific credentials. But, unfortunately, I don't get how do I do this.
I have found some articles on automatic deploying (like this http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html), but, obviously, they are very specific for web projects.
So, how should I correctly deploy my installator on build?
Your best bet is to research NAnt and make a simple task that will copy the TeamCity artifact (installer) out to the specified location.
All you would need to do is have TeamCity execute the specified NAnt task after the installer has been built.
http://nant.sourceforge.net/release/0.85/help/tasks/copy.html
Update
Also, check out this question for solutions on specifying the credentials for the copy task.
OK, I've found out that it's pretty easy to do this using the FtpUpload MSBuild community task. There, one can set up the credentials and all other stuff needed for uploading a file (or a set of files) via ftp.