I am trying to use AutoIT in my automated tests for the project. Locally I am able to register the COM Library using regsvr32 but when I try to do the same from my azure pipeline, the script runs continuously.
I have my azure pipeline yml as following:
- job: Tests
displayName: Automated Tests
pool:
vmImage: "windows-latest"
steps:
- task: NuGetToolInstaller#1
- task: DotNetCoreCLI#2
displayName: Restore Packages
inputs:
command: 'restore'
projects: 'Free.Automation/Free.Automation.csproj'
feedsToUse: 'config'
nugetConfigPath: 'Free.Automation/nuget.config'
- task: BatchScript#1
displayName: Register AutoIT
inputs:
filename: 'Free.Automation/autoit.bat'
- task: MSBuild#1
inputs:
solution: "Free.Automation/Free.Automation.sln"
And this is the bat file I am using:
cd c:\windows\system32
regsvr32 C:\Users\%USERNAME%\.nuget\packages\autoitx.dotnet\3.3.14.5\build\AutoItX3.dll
I verified that the path of azure pipeline space is something D:\1\a\s but not sure how the directory works.
Could anyone help me registering the COM lib on azure hosted pipeline space?
With Azure DevOps Microsoft-hosted agent, you can't get your local files directly. So if you want to use COM DLLs, you need to include them in your source code files.
I recommend that you have a lib folder to store your DLLs in. Please make sure that your DLLs are referenced correctly as a relative path in .csproj.
I verified that the path of azure pipeline space is something D:\1\a\s but not sure how the directory works.
In Azure DevOps, you can use the predefined variable $(System.DefaultWorkingDirectory) to get the local path on the agent where your source code files are downloaded. That's the "azure pipeline space D:\1\a\s" you mentioned.
Related
I am getting the following error when trying to run my pipeline
Job Job: Step task reference is invalid. The task name NuGetCommand is ambiguous.
Specify one of the following identifiers to resolve the ambiguity:
.NuGetCommand, .NuGetCommand
Below is my .yml file for my .Net Standard library
trigger:
- main
pool:
vmImage: 'windows-latest'
variables:
solution: '**/MyLibrary.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/MyLibrary.sln'
feedsToUse: 'config'
nugetConfigPath: './nuget.config'
- task: VSBuild#1
inputs:
solution: '**\MyLibrary.sln'
vsVersion: '15.0'
restoreNugetPackages: true
It seems to be complaining about NugetCommand#2 which doesn't make sense when it comes built in?
Edit
Have also tried using - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b#2 instead of - task: NuGetCommand#2
One may have been pushed straight into the account using tfx build tasks upload, run tfx build tasks list to find out which ones are installed and if needed delete the non-official one using tfx build tasks delete.
C:\Users\jesse>npm install tfx-cli -g
C:\Users\jesse>tfx build tasks list
TFS Cross Platform Command Line Interface v0.8.3
Copyright Microsoft Corporation
> Service URL: https://dev.azure.com/jessehouwing-dev
> Personal access token:
The one you want to keep is:
id : 333b11bd-d341-40d9-afcf-b32d5ce6f23b
name : NuGetCommand
friendly name : NuGet
visibility :
description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Azure Artifacts and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
version : 2.179.0
If there is one with a different guid, delete is with:
C:\Users\jesse>tfx build tasks delete --task-id the-task-id-guid-to-delete
It may also have been pushed as part of a privately shared custom extension. The marketplace will block tasks with the rame GUID, but it will allow installing a task with the same name just fine through an extension. Check your installed extensions, especially privately shared ones.
AzureDevops Task name NuGetCommand is ambiguous
According to the error message, it seems that error can happen when two tasks\extensions exist in your Azure DevOps organization with the same name.
You could use this REST API:
https://dev.azure.com/{organisationName}/_apis/distributedtask/tasks?visibility%5B%5D=Build
to check here for possible duplicates.
To resolve this issue, you could use command line to invoke nuget.exe to restore the solution:
nuget.exe restore a.sln -source "xx" -PackagesDirectory
I recently moved my sources to azure devOps to use cd/ci and all the other cool stuff.
Now i created my first build pipeline to build the android part of my Xamarin project. But I end up getting an error message, that a resource of a referenced project could not be found and i shall do a package restore and try again.
Now, since i have azure hosted build agents and not self hosted, i have no ways of setting the agent up properly before doing the build.
But i guess there should be some way to properly configure the build pipeline to do all the necessary stuff.
Its just that i have no clue what i should add to my yaml file in order to fix this stuff.
This is the error message i got:
##[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): Error NETSDK1004: Assets file 'd:\a\1\s\*****\*****\*****\*****\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
The problem is, that this file should be generated by compiling a referenced project and is not part of a nuget package.
Here is my build pipeline as far as i figured it out by myself.
# Xamarin.Android
# Build a Xamarin.Android project.
# Add steps that test, sign, and distribute an app, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/xamarin
trigger:
- Share/main
pool:
vmImage: 'VS2017-Win2016'
variables:
buildConfiguration: 'Debug'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:
- task: NuGetToolInstaller#1
inputs:
versionSpec: 5.1.0
- task: NuGetCommand#2
displayName: 'Restore NuGet Packages'
inputs:
command: restore
restoreSolution: '**/*.sln'
- task: XamarinAndroid#1
inputs:
projectFile: 'Mobile4/Droid/Mobile4.Droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'
- task: AndroidSigning#3
inputs:
apksign: false
zipalign: false
apkFiles: '$(outputDirectory)/*.apk'
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(outputDirectory)'
The build always breaks on step XamarinAndroid
I hope you can help me.
The solution must be out there somewhere, i just cannot see it right now.
Thx in Advance.
Mav
[error]C:\Program Files\dotnet\sdk\2.2.105\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5):
Error NETSDK1004: Assets file
'd:\a\1\s********************\obj\project.assets.json' not found.
Run a NuGet package restore to generate this file.
According to this error message, the project is .NetCore and its SDK used is 2.2.105. For the file "....\obj\project.assets.json", whether the project.assets.json exists is determined by package restore step. Now, it prompt this could not be found, it means the package restore does not restore this file successfully.
As I mentioned previously, it is a .NetCore project. So you should use dotnet restore instead of nuget restore. For .NetCore project, the obj folder restored by nuget restore does not contain project.assets.json in it.
So, to solve the issue you meet, you should replace the task Nuget restore as dotnet restore: dotnet.
- task: DotNetCoreCLI#2
displayName: 'dotnet restore'
inputs:
command: restore
projects: '**/*.csproj'
vstsFeed: 'e157d03d-******-fc06f9e13177'
Today we experienced the following message in Azure Portal
WebJob cannot be added from portal if deployment form source control is configured.
We assume that this is a new feature hence the spelling is incorrect: 'deployment form source control' should be 'deployment from source control'.
I have no clue where to set a setting that solved this.
It has to be somewhere in DevOps we assume.
We solved it by not disconnecting a pipeline.
We solved it by implementing a seperate WebJob Build/Release Pipeline.
Here are the steps that worked for us:
In Azure Portal
Create a virtual application in your app service
In DevOps
In your build pipeline
Important Notice: add the following Argument: --output $(build.artifactstagingdirectory) to the build step.
In your release pipeline
This deploys the WebJob to the correct directory. In our case: $(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop
Having a look at the Kudo Console in our App Service the file location for our WebJob is:
Kudu Console
The workaround that worked for me was uploading the webjob directly via the Kudu Console.
Open the Kudu Console by selecting "Advanced Tool" --> "Go" in Your App Service on the Azure Portal.
Once on the Kudu portal open a "Debug Console" --> "CMD"
Go to the directory for your webjobs: "d:\home\site\wwwroot\app_data\jobs\continuous\{job name}" (https://github.com/projectkudu/kudu/wiki/WebJobs)
Then drag and drop the .zip file you prepared to upload your webjob (https://github.com/projectkudu/kudu/wiki/Kudu-console)
The job will now be listed on the Azure Portal and be started.
I used the following physical path in the Virtual Application and it solved it for us
site\wwwroot\App_Data\jobs\triggered\jobname
We had the same issue and noticed there was an old deployment pipeline connected to our web job in the Deployment Center blade. Disconnecting this solved the problem for us and we were able to manually deploy.
I used Kudu console to upload the webjobs
You can go to the path D:\home\site\wwwroot\App_Data\jobs\ and then upload the webjob folder here and then this shows up in your Webjobs portal as well
Don't go for the new CICD pipeline creation of this issue. Don't use chrome/safer while disconnecting the deployment center. Please use the latest IE or Microsoft Edge. it will allow the disconnect of the deployment center. I am able to do that in Microsoft Edge.
We had the same issue, and there was default configuration in deployment center for my web application, but we are not deploying the code from reposiotry, so we disabled that option. We are deploying web application from visual studio.
Currently the image showing disabled repository options in deployment center of the web application.
Probably because You set CI/CD for your web app deployment.
If you set your deployment with Azure Devops pipelines, and you are doing the yaml file approach, then maybe this is what you are looking for.
firstly you need to set the branch that you want to be triggred when a new commit has been pushed to it.
trigger:
branches:
include:
- refs/heads/staging
variables:
BuildConfiguration: 'Release'
pr: none # Disable pull request triggers.
To make our pipeline a little bit organized, We will work with stages, let's create our Build stage, here I am building a .Net app, you can replace the build task with the build you want.
stages:
- stage: 'Build'
jobs:
- job: 'Build'
pool:
vmImage: 'windows-latest' #The agent that will be used to start this stage
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: build
projects: 'MySuperApp/BackgroundService.csproj'
arguments: '--configuration $(BuildConfiguration)'
then I will run dotnet publish, that publishes the application and its dependencies to a folder for deployment to a hosting system.
and here comes the important part, when you create a webjob from azure portal, its files are stored under specific folder.
for Continuous webjobs, it will be stored under \site\wwwroot\app_data\Jobs\Continuous
and for Triggered webjobs it will be under \site\wwwroot\app_data\Jobs\Triggered
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: 'publish'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
projects: 'MySuperApp/BackgroundService.csproj'
publishWebProjects: false
zipAfterPublish: false
modifyOutputPath: false
for me I need to deploy a continuous webjob, as you can see in the arguments within inputs:
--output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
the dotnet publish will put the generated files under $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS
then I will zip the content of $(Build.ArtifactStagingDirectory)/publish_output/ which is App_Data/jobs/continuous/MySuperAppBGS
- task: ArchiveFiles#2
displayName: 'Zip Published Files'
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish_output'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.ArtifactStagingDirectory)/MySuperAppAPIBackgroundService.zip'
replaceExistingArchive: true
and publish the content of $(Build.ArtifactStagingDirectory) to drop artifact, which our zip file exist MySuperAppAPIBackgroundService.zip, in order to use it, in the next stage
- task: PublishBuildArtifacts#1
displayName: 'Publish Build artifacts'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Here is the second stage, that will deploy our zip file to the web app service, then it will be unzipped leaving
App_Data/jobs/continuous/MySuperAppBGS/* under \site\wwwroot\
- stage: 'Deploy'
jobs:
- deployment: 'Deploy'
environment: 'MySuperAppAPI_BackGround_Staging_env' #just an env variable, that will be used later if you want, give it whatever name you like
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp#1
displayName: 'Deploy MySuperAppAPIBackgroundService.zip to MySuperAppAPI-Staging-BackgroundService'
inputs:
azureSubscription: 'Your Azure service connection'
appType: 'webApp'
appName: 'MySuperAppAPI-Staging-BackgroundService'
package: '$(Pipeline.Workspace)/drop/MySuperAppAPIBackgroundService.zip'
deploymentMethod: 'zipDeploy'
Note: in the second stage, I didn't call DownloadBuildArtifacts#0 task, because I used deploy: within - deployment: job that auto inject the Download artifact task, and to access the published Artifact from the previous stage, you use $(Pipeline.Workspace) following by the artifact name you provided, in my case it is $(Pipeline.Workspace)/drop
Hope I was clear, for any clarification don't hesitate to ask me.
I am trying to use Azure Devops to do CI/CD. I have created the appropriate Git triggers to build when I push and I create a new release whenever I have produced a new build.
In the release tab I am trying to deploy a WebAPI project with several webjobs using the "Deploy Azure App Service" template. All the logs seem to indicate everything goes fine, but in the end I have nothing when I check the app service in Azure!
I have tried many different configurations and even a few more templates. They all seem fine according to the logs, but nothing is actually ever deployed!
If I try to build/deploy from VS2017 it works beautifully!
QUESTION
what do I need to do in order to successfully deploy my code via Azure Devops
.
My build YAML file is fairly close to the default, only added the CopyFiles#2 due to another SO post suggesting it:
trigger:
tags:
include:
- slot*
branches:
include:
- dev
pool:
vmImage: 'VS2017-Win2016'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
name: $(SourceBranchName)_$(Date:yyyyMMdd)$(Rev:.r)
steps:
- task: NuGetToolInstaller#0
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: CopyFiles#2
inputs:
targetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts#1
condition: succeeded() #and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
Second step I create a release from the artifacts produced via the YAML file.
Please add the following line in your package or folder option
$(System.DefaultWorkingDirectory)\*.*
It will make sure to pick all the files while deploying.
Also please refer to these ways to deploy webjob to azure:
Modify Visual Studio Build task to deploy webjob with FileSystem (MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish)
Add Delete Files task to release definition to delete bin folder (Source Folder:
$(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob); Contents:bin)
Modify Azure App Service Deploy task (
Uncheck Publish using Web Deploy option.
Package or folder: $(System.DefaultWorkingDirectory)/[artifact name]
/drop/WebJob)
Hope it helps.
There are two main problems with your deploy task.
As Mohit said, you need to specify the zip file of the web project you want to deploy, not just the directory it is in.
You need to uncheck "Exclude files from the App_Data folder". This will prevent webjobs from deploying with the website
2.1 If you haven't, in Visual Studio, you need to right click your web project Add > Existing Project as Azure Webjob. Do this for every webjob project so it will package the webjobs with the website
I have implemented a C# function in the Azure Portal.
I downloaded the content of the Function App as a Visual Studio project.
I now want to deploy it with Azure DevOps release pipeline.
The deployment works fine but my function is not deployed. Sounds like the .csx file is not taken into account.
I tried to change the Build Action of the csx file to C# Compiler but it failed during the compilation with missing dependencies. Not sure it is the right way to proceed.
What are the steps to deploy the Azure functions?
It seems a little bit overkill to deploy csx functions with AzureDevOps. We could simply zip those files in the same folder structure as they were downloaded, go to https://<functionappname>.scm.azurewebsites.net/ZipDeployUI and drag the zip file to deploy. If you prefer command line instead of manual deployment, check Azure CLI command.
If you have to work with AzureDevOps, have a look at Build pipeline YAML below(Release pipeline is the default template Deploy a function app to Azure Functions).
resources:
- repo: self
queue:
name: Hosted VS2017
steps:
- task: ArchiveFiles#2
displayName: 'Archive $(system.defaultworkingdirectory)'
inputs:
rootFolderOrFile: '$(system.defaultworkingdirectory)'
includeRootFolder: false
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
Note that the <functionName>.csproj file downloaded is useless and shouldn't be commited to repo. But if we have installed some extensions and see extensions.csproj file, add Net Core build task before ArchiveFiles#2.
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '$(Parameters.RestoreBuildProjects)'
arguments: '--configuration release -o bin --no-incremental'