I have installed the latest version of Azure CLI on my windows 2019 self hosted agent. Output when checking for version.
PS C:\Users\blahblah> az --version
azure-cli 2.3.1
command-modules-nspkg 2.0.3
core 2.3.1
nspkg 3.0.4
telemetry 1.0.4
Extensions:
azure-devops 0.18.0
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\builduser\.azure\cliextensions'
Python (Windows) 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 02:47:15) [MSC v.1900 32 bit (Intel)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Then when running the same script in devops azure pipeline release :
2020-04-18T03:50:14.3974844Z ##[debug]which 'az'
2020-04-18T03:50:14.3981389Z ##[debug]found: 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd'
2020-04-18T03:50:14.3981785Z ##[debug]which 'az'
2020-04-18T03:50:14.3985125Z ##[debug]found: 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd'
2020-04-18T03:50:14.3988433Z ##[debug]C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd arg: --version
2020-04-18T03:50:14.3989115Z ##[debug]C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd arg: --version
2020-04-18T03:50:14.3998697Z ##[debug]exec tool: C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd
2020-04-18T03:50:14.3998969Z ##[debug]exec tool: C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd
2020-04-18T03:50:14.3999139Z ##[debug]arguments:
2020-04-18T03:50:14.3999314Z ##[debug]arguments:
2020-04-18T03:50:14.4000072Z ##[debug] --version
2020-04-18T03:50:14.4000425Z ##[debug] --version
2020-04-18T03:50:14.4017396Z [command]C:\windows\system32\cmd.exe /D /S /C ""C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd" --version"
2020-04-18T03:50:17.1212688Z azure-cli 2.3.1
2020-04-18T03:50:17.1213010Z
2020-04-18T03:50:17.1213120Z command-modules-nspkg 2.0.3
2020-04-18T03:50:17.1213248Z core 2.3.1
2020-04-18T03:50:17.1213345Z nspkg 3.0.4
2020-04-18T03:50:17.1213451Z telemetry 1.0.4
2020-04-18T03:50:17.1213507Z
2020-04-18T03:50:17.1213631Z Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
2020-04-18T03:50:17.1214799Z Extensions directory 'C:\windows\ServiceProfiles\NetworkService\.azure\cliextensions'
2020-04-18T03:50:17.1214873Z
2020-04-18T03:50:17.1215003Z Python (Windows) 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 02:47:15) [MSC v.1900 32 bit (Intel)]
2020-04-18T03:50:17.1215081Z
2020-04-18T03:50:17.1215191Z Legal docs and information: aka.ms/AzureCliLegal
2020-04-18T03:50:17.1215271Z
2020-04-18T03:50:17.1215320Z
2020-04-18T03:50:17.1215369Z
2020-04-18T03:50:17.1215468Z Your CLI is up-to-date.
2020-04-18T03:50:17.1215525Z
2020-04-18T03:50:17.1215623Z Please let us know how we are doing: https://aka.ms/clihats
Notice how the release pipeline does not show that I have the azure-devops extension installed. I need this extension to remotely trigger a pipeline release creation. I've tripled and quadrupled check that I am comparing the same server.
My next step would be to add a step to install the Azure CLI extension before calling the az pipelines. However I would rather try to figure out why this is not working. I have make this same call locally and it works fine. However I log in as myself instead of using a service principal/service subscription when testing same call locally.
Has anyone run into this issue and know whats going on here? Any suggestion would be greatly appreciated.
I found that the Extensions directory is inconsistent in your local and release pipeline.
In local:
Extensions directory 'C:\Users\builduser\.azure\cliextensions'
In release pipeline log :
Extensions directory 'C:\windows\ServiceProfiles\NetworkService\.azure\cliextensions'
If you are using a private agent, the Extensions directory should be consistent:
So you need to check the following points:
1.The machine where you installed az cli is the same machine as the agent you use to run the pipeline.
2.According to the directory path, check the installation of azure cli.
Related
I would like to configure CI in Appveyor for a .net project and I am struggling with following errors:
error NU1403: Package content hash validation failed for System.Collections.NonGeneric.4.3.0. The package is different than the last restore.
Every project restore happens to throw similar thing
There was similar question and one advice was to clear nuget cache.
Whats the best course of action here?
Thanks
Directory.Build.props
<PropertyGroup>
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
<DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder>
</PropertyGroup>
Build started
git config --global core.autocrlf true
git clone -q --branch=master https://github.com/User/App.git C:\projects\App
git checkout -qf 7066b969dd7564c573fb5e30fa6600a86c48644f
choco install opencover.portable
Chocolatey v0.11.3
Installing the following packages:
opencover.portable
By installing, you accept licenses for the packages.
Progress: Downloading opencover.portable 4.7.1221... 100%
opencover.portable v4.7.1221 [Approved]
opencover.portable package files install completed. Performing other installation steps.
Downloading opencover.portable
from 'https://github.com/OpenCover/opencover/releases/download/4.7.1221/opencover.4.7.1221.zip'
Progress: 100% - Completed download of C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\opencover.portable\4.7.1221\opencover.4.7.1221.zip (7.76 MB).
Download of opencover.4.7.1221.zip (7.76 MB) completed.
Hashes match.
Extracting C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\opencover.portable\4.7.1221\opencover.4.7.1221.zip to C:\ProgramData\chocolatey\lib\opencover.portable\tools...
C:\ProgramData\chocolatey\lib\opencover.portable\tools
ShimGen has successfully created a shim for OpenCover.Console.exe
ShimGen has successfully created a shim for OpenCover.Simple.Target.exe
ShimGen has successfully created a shim for OpenCover.Simple.Target.exe
The install of opencover.portable was successful.
Software installed to 'C:\ProgramData\chocolatey\lib\opencover.portable\tools'
Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Did you know the proceeds of Pro (and some proceeds from other
licensed editions) go into bettering the community infrastructure?
Your support ensures an active community, keeps Chocolatey tip-top,
plus it nets you some awesome features!
https://chocolatey.org/compare
choco install codecov
Chocolatey v0.11.3
Installing the following packages:
codecov
By installing, you accept licenses for the packages.
Progress: Downloading codecov 1.13.0... 100%
codecov v1.13.0 [Approved]
codecov package files install completed. Performing other installation steps.
Extracting 64-bit C:\ProgramData\chocolatey\lib\codecov\tools/codecov-win7-x64.zip to C:\ProgramData\chocolatey\lib\codecov\tools...
C:\ProgramData\chocolatey\lib\codecov\tools
ShimGen has successfully created a shim for codecov.exe
The install of codecov was successful.
Software installed to 'C:\ProgramData\chocolatey\lib\codecov\tools'
Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
dotnet --version
5.0.403
dotnet restore
Determining projects to restore...
C:\projects\App\Tests\Common.Tests\Common.Tests.csproj : error NU1403: Package content hash validation failed for System.Collections.NonGeneric.4.3.0. The package is different than the last restore. [C:\projects\App\App.sln]
appveyor.xml
version: '1.0.{build}'
image: Visual Studio 2019
branches:
only:
- master
init:
- cmd: git config --global core.autocrlf true
install:
before_build:
- choco install opencover.portable
- choco install codecov
- cmd: dotnet --version
- cmd: dotnet restore
build_script:
- cmd: dotnet build --configuration Release --no-restore
test_script:
- cmd: dotnet test --configuration Release --no-build --no-restore --verbosity minimal --test-adapter-path:. --logger:Appveyor /p:CollectCoverage=true /p:CoverletOutput=TestResults/ /p:MergeWith="../TestResults/coverage.json" /p:CoverletOutputFormat=lcov
cache:
- '%USERPROFILE%\.nuget\packages -> **\project.json'
- C:\ProgramData\chocolatey\bin -> appveyor.yml
- C:\ProgramData\chocolatey\lib -> appveyor.yml
deploy: off
At Feodor suggestion I added powershell script which removes package.lock.json files and it worked.
before_build:
- choco install opencover.portable
- choco install codecov
- ps: >-
Get-ChildItem .\ -include packages.lock.json -Recurse | foreach ($_) { remove-item $_.fullname -Force }
- cmd: dotnet --version
- cmd: dotnet restore
I am trying to run Automation Tests on Azure Devops using ChromeDriver. For that I am following below steps:
npm install -g chromedriver This works fine
chromedriver -v This works fine and gives ChromeDriver 85.0.4183.87 (cd6713ebf92fa1cacc0f1a598df280093af0c5d7-refs/branch-heads/4183#{#1689})
But when I run maven command, for ex: mvn clean verify -Dcucumber.options="--tags #smoke" -e then it gives below error.
2020-10-06T12:34:50.0688871Z Oct 06, 2020 12:34:50 PM org.openqa.selenium.os.OsProcess checkForError
2020-10-06T12:34:50.0689959Z SEVERE: org.apache.commons.exec.ExecuteException:
Execution failed (Exit value: -559038737. Caused by java.io.IOException:
Cannot run program "G:\a\..\..\_tool\node\..\..\x64\chromedriver" (in directory "."):
CreateProcess error=193, %1 is not a valid Win32 application)
Node version is v10.22.1
NPM version is 6.14.6
OS name: "windows server 2016", version: "10.0", arch: "amd64", family: "windows". It is VM and ADO Agent
There a few possible causes for the "%1 is not a valid Win32 application" message including: the pathname for the application is incorrect or the file is a 32 bit executable, but for some reason it is trying to load a 64 bit DLL.
npm install -g chromedriver It will use a global location instead of install chromedriver under the local folder, you can use the cmd npm install chromedriver and check the log then we can get the path.
If we are using npm install -g to install the program. On Windows the path could be C:\Users\YOU\AppData\Roaming\npm\node_modules, and according to the log, we can see that it run the program under G:\a\..\..\_tool\node\..\..\x64\chromedriver
I am trying out the IBM BLockchain Extension for VSCode and going through the tutorial. I am able to create a smart contract project, add a workplace, and create a smart contract package. At the local fabric ops part - When I click start local fabric runtime I get an error:
[5/19/2019 10:17:44 AM] [INFO] startFabricRuntime [5/19/2019 10:17:44
AM] [INFO] 'generate.cmd' is not recognized as an internal or external
command, [5/19/2019 10:17:44 AM] [INFO] operable program or batch
file.
I am using:
VSCode
Windows 10 Enterprise
Docker Desktop for Windows
Uninstall ibm blockchain extension from extension
Delete runtime folder from vscode directory.
You can find vscode directory in home directory
path to runtime package
$ cd .fabric-vscode
$ ls
local_fabric_wallet packages runtime
$ rm packages
Reinstall the ibm blockchain extension in vscode
I´m on Windows 7, and i have Python 3.5.1 installed.
I want to create executables from Python scripts.
What i did so far:
I ran pip install cx_freeze and i got the Unable to find vcvarsall.bat error.
There #Cody Piersall linked to Steve Dowers blog entry.
From there i downloaded and installed the Visual C++ Build Tools 2015.
Now i have these *Microsoft Visual C++ ** ´es installed: Screenshot.
And i have the vcvars* batches installed in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\:
vcvarsall.bat
bin\vcvars32.bat
bin\amd64\vcvars64.bat.
etc
My prettyprinted PATH is:
C:\run\Python_3_5\Scripts\;
C:\run\Python_3_5\;
C:\Windows\system32;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\ProgramData\Oracle\Java\javapath;
C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;
C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;
C:\run\Haskell-Platform\lib\extralibs\bin;
C:\run\Haskell-Platform\bin;
C:\Users\Nils-Hero\AppData\Roaming\cabal\bin;
C:\run\Haskell-Platform\mingw\bin;
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;
C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;
Problem:
When i now rerun pip install cx_freeze, it doesn´t find a file cl.exe:
Collecting cx_freeze
Using cached cx_Freeze-4.3.4.tar.gz
Installing collected packages: cx-freeze
Running setup.py install for cx-freeze ... error
Complete output from command c:\run\python_3_5\python.exe -u -c "import setuptools, tokenize;__file__='C:\\Users\\NILS-H~1\\AppData\\Local\\Temp\\pip-build-9lhua9e9\\cx-freeze\\setup.py'
;exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record C:\Users\NILS-H~1\AppData\Local\Temp\pip-bb2i8jxv-record\install-re
cord.txt --single-version-externally-managed --compile:
adding base module named _bootlocale
adding base module named _collections_abc
adding base module named _compression
...
... adding a lot more base modules ...
...
running install
running build
running build_py
creating build\lib.win-amd64-3.5
creating build\lib.win-amd64-3.5\cx_Freeze
copying cx_Freeze\common.py -> build\lib.win-amd64-3.5\cx_Freeze
copying cx_Freeze\dist.py -> build\lib.win-amd64-3.5\cx_Freeze
...
... creating and copying a lot more things ...
...
running build_ext
building 'cx_Freeze.util' extension
creating build\temp.win-amd64-3.5\Release
creating build\temp.win-amd64-3.5\Release\source
cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT -Ic:\run\python_3_5\include -Ic:\run\python_3_5\include /Tcsource/util.c /Fobuild\temp.win-amd64-3.5\Release\source/util.obj
error: command 'cl.exe' failed: No such file or directory
----------------------------------------
Command "c:\run\python_3_5\python.exe -u -c "import setuptools, tokenize;__file__='C:\\Users\\NILS-H~1\\AppData\\Local\\Temp\\pip-build-9lhua9e9\\cx-freeze\\setup.py';exec(compile(getattr(to
kenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record C:\Users\NILS-H~1\AppData\Local\Temp\pip-bb2i8jxv-record\install-record.txt --single-versio
n-externally-managed --compile" failed with error code 1 in C:\Users\NILS-H~1\AppData\Local\Temp\pip-build-9lhua9e9\cx-freeze\
This executable is under C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\ and also in the subfolders.
I guess pip can´t find it because these paths are not on my PATH, but why wouldn´t that Visual C++ Build Tools 2015 installer add them? I´m scared to hand-tweak a 800MB sized, 50 minutes lasting installation. So i´ll better ask here first.
Ok. Solved.
I successfully installed cx_freeze from a wheel according to the answer to this Question.
But version 4.3.4 from the Gohlke site has a bug under Python 3.5 (ImportError: No module named '_frozen_importlib_external'). We have to wait until the cx_freeze author releases the next version of cx_freeze (which seems to be soon).
Meanwhile, Sebastian Krause was so kind to create some wheels from the latest code from repo, cx_freeze 5.0, and these wheels install and run without errors in my tests.
I am trying to add the Exchange 2007 SnapIn for 32-bit Powershell (Microsoft.Exchange.Management.PowerShell.Admin) but I seem to be having some trouble when installing the dll file.
These are the commands I am running in order to register the SnapIns
PS C:\Program Files\Microsoft\Exchange Server\Bin> $snapinPath = 'Microsoft.Exchange.Management.PowerShell.Support.dll'
PS C:\Program Files\Microsoft\Exchange Server\Bin> C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i $snapinPath
The above works without issue. I then go to install the main SnapIn with the following commands:
PS C:\Program Files\Microsoft\Exchange Server\Bin> $snapinPath = 'Microsoft.Exchange.PowerShell.Configuration.dll'
PS C:\Program Files\Microsoft\Exchange Server\Bin> C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i $snapinPath
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.5483
Copyright (c) Microsoft Corporation. All rights reserved.
Exception occurred while initializing the installation:
System.BadImageFormatException: Could not load file or assembly 'Microsoft.Exchange.PowerShell.Configuration, Version=8.
0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. An attempt was made to load a program with an incorrect format..
I'm not sure what I'm missing here. It's a fresh Exchange 2007 install so nothing should be corrupt.
My issue was that I was using the 64-bit version of the Microsoft.Exchange.PowerShell.Configuration.dll.
I required the 32-bit version. As it did not allow me to install the 32-bit version, I extracted the setup files for the 32-bit version of exchange, and copied the setup\serverroles\common folder to C:\Program Files\Microsoft\Exchange Server, and renamed it to Bin32.
The final stage was to copy this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Admin
to the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Admin
and then change any paths within the key to point to the new Bin32 folder.
At this point, it should be possible to load the Microsoft.Exchange.Management.Powershell.Admin snapin into a 32-bit Powershell (Great for IIS apps which depend on 32-bit libraries).