Closed SteveBush closed 4 years ago
Work-around is to skip target files that contain a comma. I also moved the Write-Verbose call ahead of the Test-Path conditional.
Library.Template\azure-pipelines\artifacts_stage_all.ps1, line 29
# Skip if target contains a comma
if ($Target -match ',') {
return
}
if (Test-Path $Link) { Remove-Item $Link }
$LinkContainer = Split-Path $Link -Parent
Write-Verbose "Linking $Link to $Target in folder $LinkContainer"
if (!(Test-Path $LinkContainer)) { mkdir $LinkContainer }
if ($IsMacOS -or $IsLinux) {
ln $Target $Link | Out-Null
} else {
cmd /c mklink $Link $Target | Out-Null
}
}
It sounds like this isn't a bug in this template, but rather once you change the template, you expose a bug in AzP and GitHub. Have you filed bugs against them?
Updated to address comments below: 1) Made comments use code tag
There is no bug in the template until you upgrade to Visual Studio 16.6. Upgrading to Visual Studio 16.6 forced me to upgrade global.json sdk version to 3.1.300 and compiler build tools to 3.6. The later change creates a new file in the output directory: .NETStandard,Version=v2.0.AssemblyAttributes.cs which contains a comma. The template script mentioned above calls mklink on Windows which fails to link an artifact from the Release to the coverageResults-Windows folder.
I should also add that I have changed the src template to use <targetframeworks> instead of <targetframework> as I need to override this setting in an Android build. I believe this file is produced when you have multiple target frameworks.
I assuming someday consumers of the template will upgrade to Visual Studio 16.6 and be in the same situation. I don't think this is a bug against AzP or GitHub but a bug in the script that handles the linking of coverage files.
Linking C:\AzureAgent\_work\1\a\coverageResults-Windows\obj\PureActive.Core\Release\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs to C:\AzureAgent\_work\1\s\obj\PureActive.Core\Release\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs in C:\AzureAgent\_work\1\a\coverageResults-Windows\obj\PureActive.Core\Release\netstandard2.0
##[error]cmd : The syntax of the command is incorrect.
At C:\AzureAgent\_work\1\s\azure-pipelines\artifacts\_stage_all.ps1:36 char:9
+ cmd /c mklink "$Link" "$Target" | Out-Null
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (The syntax of the command is incorrect.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Upgrading to Visual Studio 16.6 forced me to upgrade global.json sdk version to 3.1.300 and compiler build tools to 3.6.
No it doesn't. VS works with older SDKs just fine. I've been using this Library.Template and repos based on it in VS 16.6 and 16.7 without a problem.
The requirement though is that the SDK is actually installed. It's quite possible that when you upgraded to 16.6 that the VS installer removed the SDK this template uses, which made it look like you had to upgrade the SDK used, when you could have actually just reinstalled the SDK that the VS upgrade removed.
That is actually one reason why this template includes an init
script, which will install the SDK it requires. If you run the init script and then launch VS from that same command window, it will work. Or if you add -InstallLocality Machine
then elevation is required but then the SDK will be installed at the machine-wide location and VS will find it even without launching from that environment window.
Updating the compiler toolset alone didn't repro the problem you're seeing. It seems to be the SDK update to 3.1.300 that does it.
I should also add that I have changed the src template to use instead of as I need to override this setting in an Android build.
I don't understand that statement. Can you rephrase? Perhaps a grammatical error.
The template script mentioned above calls mklink on Windows which fails to link an artifact from the Release to the coverageResults-Windows folder.
Ah! Excellent. I'll look into that right away.
Change
<targetframework>
to<targetframeworks>
. This creates the file with the comma
I wouldn't expect multi-targeting to be required to repro the problem. #56 doesn't do this and it still has experienced some failures. So I'll start with investigating those and try again with a multi-targeting project to see if anything new crops up.
Thanks for reporting.
I upgraded to Visual Studio 16.6 which forced an upgrade to the 3.6.0 compiler build tools:
and global.json upgrade for sdk to 3.1.300. Builds fine locally but fails in GitHub and Azure Windows build clients.
I tracked down the cause to the 3.6.0 build tools producing the following file in the obj folder: .NETStandard,Version=v2.0.AssemblyAttributes.cs
The artifact publishing scripts on Windows are failing due to the comma after .NetStandard. In the Publish artifacts stage the following error is produced:
I have verified the breaking change is the inclusion of new file with a comma in the 3.6.0 compiler toolset.