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
Related
I'm trying to build a .net core 1.1 project on vsts. The project is developed in vs2017 and it uses the csproj instead of project.json. I have tried multiple options to build id on vsts with the hosted agents (windows and linux).
i have tried the following build steps
Visual studio build
Set to use vs 2017 but i get a warning "Visual Studio version '15.0' not found. Looking for the latest version." And then i get errors because it cant include .net core packages.
.NET Core (PREVIEW)
Cant find project.json. When i set it to use csproj file it gives an error "The file type was not recognized"
Command build step
I tried to run the commands with command build steps. "dotnet build" gives the error that it cant find the project.json file.
Anyone building dotnet 1.1 with csproj on vsts that can help me how to do it?
In Visual Studio Team Services, go to Build & Release > Builds and click Edit for the build definition you want to update
Navigate to the Options tab, change Default agent queue to Hosted VS2017, and save.
You can download dotnet SDK manually and run dotnet build from command line.
So it could be something like this:
Inline PowerShell step (I've used Inline Powershell extension by Peter Groenwegen):
Invoke-WebRequest https://go.microsoft.com/fwlink/?linkid=837977 -OutFile $(System.DefaultWorkingDirectory)\dotnet.zip
Extract files step:
From: $(System.DefaultWorkingDirectory)\dotnet.zip
To: $(System.DefaultWorkingDirectory)\dotnet
Restore packages:
$(System.DefaultWorkingDirectory)\dotnet\dotnet.exe restore
... and so on
But there is some limitation — you still haven't had .Net Core 1.1 installed at build agent machine so some features may not work. At least dotnet test will fail because it requires appropriate .Net Core runtime. Maybe some other features as well.
extending on #Nikolay Balakin's answer, it's true the .NET Core projects using *.csproj are not supported yet.
You can work around this by installing the latest .NET core on the hosted build environment yourself.
This will allow running dotnet restore, dotnet build, dotnet publish, and dotnet test.
Use the Inline powershell extension to run a script. You can link to a script, or paste the text in inline. I am running a script which is checked in to the project.
It seems each powershell script will be run in it's own environment, so paths etc. will not persist between scripts, so the installation steps and the build steps need to be combined into one script.
You need to copy the dotnet installation script from github and add your own build commands to the end.
I know this is not a long term solution, but we justified it by assuming the VSTS will in the near future support the *.csproj files, and we will convert to use the official build task.
Here is an example powershell script, showing the last line of the installation script, and the custom build commands on the end.
...
...
Say "Installation finished"
# this is the end of the downloaded script, add your steps after here.
Say "Running dotnet restore AdminPortal\AdminPortal.csproj"
dotnet restore AdminPortal\AdminPortal.csproj
Say "dotnet publish AdminPortal\AdminPortal.csproj --configuration Release"
dotnet publish AdminPortal\AdminPortal.csproj --configuration Release
Say 'Zipping publish file'
$source = $env:BUILD_REPOSITORY_LOCALPATH
$source = $source + '\AdminPortal\bin\Release\net461\publish'
$destination = $env:BUILD_REPOSITORY_LOCALPATH
$destination = $destination + '\AdminPortal\bin\Release\net461\publish.zip'
Add-Type -assembly "system.io.compression.filesystem"
[io.compression.zipfile]::CreateFromDirectory($source, $destination)
Say "Publish finished"
dotnet test "AdminPortal.Tests\AdminPortal.Tests.csproj"
Say "Test finished"
exit 0
According to this issue .NET Core projects using *.csproj files are not supported yet:
https://github.com/Microsoft/vsts-tasks/issues/3311
"if you are using hosted agent - then the tooling there works only
with project.json files"
I've tried the tutorials here, but they also seem to be outdated (I couldn't even get tfx-cli installed on my machine):
http://mattvsts.blogspot.nl/2016/11/start-building-aspnet-core-11-with-tfs.html
In my case, I have a .NET Core web app and four library projects, all targeting the full framework since I'm using EF 6.
I tried all of the suggestions here and none of them worked. Building with Visual Studio Build on Hosted Agent 2017 does build the project, but doesn't output any binaries. And all the options above did build as well but didn't generate the output files.
Reading around I found the only way to get the output files was by running dotnet publishbut this generates a build error because nuget isn't restoring well the packages and msbuild can't find them. After being tired of trying to make it work during a whole day, casually I enabled the "Restore Nuget Packages" on the VS Buid task, and though it says it's deprecated, that seems to have solved my isse.
In VSTS you need to add netcore exists as a demand.
Go to your build definition
Click on the options tab
Add the demand netcore exists
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.
I am deploying web application to azure using TFS CI automated build deployment.
In our config maintain build version like 2014.05.19.1 which is $(Date).$(rev) format.
All I want to update config each time build is deployed.For that I am passing value to 'BuildVersion' parameter in template to powershell script which actually performs publishing to azure.
I tried using $(Date:yyyyMMdd)$(Rev:.r) but it is considered string as it is.
I want to get current build version just like IBuildDetail.BuildNumber
within template.
My question is how to get the build version?
If you are using Invoke Process, instead of passing value for BuildVersion parameter you can directly use 'BuildDetail.BuildNumber' in parameters for process like
String.Format("-BuildNumber ""{0}""",BuildDetail.BuildNumber)
This would give the required build number.
If your PowerShell script is being executed from your TFS build, it should have access to the environment variables specific to the TFS context of the build. If that is the case, you actually don't need to pass the $(BuildVersion) parameter to the script, as it already is accessible to the PS script in the $env:TF_BUILD_BUILDNUMBER environment variable. Try testing something like $env:TF_BUILD_BUILDNUMBER | Out-File "D:\Dev\BuildNumber.txt" in your script. You should hopefully see the file containing your build number after running your build.
(I am assuming you are using a relatively new build process template...one that contains the "Post-Build script path" parameter, such as TfvcTemplate.12.xaml)
Hope this is helpful.
I would recommend that you use the right tool for the right job. The build system, is really only for building (compile & test). We have been using it for other things for years coz we did not have another integrated solution. However Microsoft recently bought InRelease and rebranded as Release Management for Visual Studio 2013. I have successfully integrated this with TFS 2012 as well.
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.
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.