-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VSBuild@1 fails to build appx WITHOUT the task updating #10617
Comments
Also run into this is issue. The last succesfully completed pipeline for me was with runner image version 20240811.1.0. At this image the "Fastlink to Full PDB Converter" version was 14.33.31424.0. |
Hi @Skintkingle , Thank you for bringing this issue to us. We are looking into this issue and will update you on this issue after investigating. |
Thanks for looking into this, This is currently stopping us from releasing and as such is quite a critical blocker for us. Do you have any ideas of a workaround for the time being? |
HI @Skintkingle , Could you please try to. build with windows-2019 image . |
Hi @kishorekumar-anchala We have also tried downloading .Net 8 with the UseDotNet@2 Task, but fundamentally, given this installs the dotnet tool for that .Net version, and not MSBuild, we're left in the same situation. |
Also run into this issue and also unable to use windows-2019 image which only supports .NET 5.0 and lower. This is preventing us from releasing and is also a critical blocker for us, so any better workaround or permanent fix would be great. |
This is impacting us too. We are unable to build or deploy updates to our internal applications so it is very critical for us to get a workaround at least for the time being. |
HI @Skintkingle , Could you please share your yaml file to investigate further. |
Sure, it is very simple though. I've also removed everything after the failing step (as it's never got to) :)
|
Hi @Skintkingle , In VsBuild@1 task , kindly modify platform value to Any CPU from x64 and try . it works for me. thank you ! |
I have practically the same yaml file and the same error occurring on the exact same task. Changing the platform from 'x64' to 'Any CPU' is not compatible with our solution as it is not configured to build with Any CPU, so this is not a valid fix or workaround, even. This is becoming a more urgent issue as it is almost a week now we cannot deploy releases. |
This also doesn't work for us. We get the same error when platform is set to |
HI @Skintkingle @josephsleiman16 , Might be issue with the Vstask@1 , have you tried to change the version of vsbuild to 2 ? could you please try this , as sometimes it will fix the issue. and also confirm what is the image version you're using ? 20240912.1.0 ? |
there is only VSBuild@1. The task is unchanged between it working and it not working. I can confirm these tests this morning were run against a newer version of the runner: 20240915.1.0 |
Hi @Skintkingle , Could you please raise issue with azure tasks team. https://github.com/microsoft/azure-pipelines-tasks |
If you sincerely beleive that it's a tasks issue and not an image issue (given the runner image has changed between it working and not working, but the task hasn't changed) |
I am skeptical that it's the tasks fault though. Please don't stop investigating. |
Further to this, I have tried using MSBuild@1 rather than VSBuild@1 on the slim chance it's the tasks fault, and I get exactly the same error at exactly the same point in the MSBuild task. This has almost certainly go to do with the build environment (or its' configuration or available tooling or something like that) The MSBuild task looked like this:
|
Agree with @Skintkingle, this is almost certainly a build issue with the runner image changing. Our builds were working on Friday on runner image 20240811.1.0 and then on monday, using runner image 20240912.1.0 they stopped working, despite being the exact same commits using the exact same yaml pipelines and tasks. |
Agreed here as well. Does not seem to be an issue with the task at all from our perspective. |
@kishorekumar-anchala are you still looking into this or not anymore? |
To add more information, I've added the command /p:AppxSymbolPackageEnabled=False, to not run into the "PDB file error".
This results in the following error: (I have removed some paths and names because of company names etc)
I've checked the last succesfull pipeline, and the used buildnummer fro MakeAppx.exe is unchanged (10.0.22621.0) |
adding `/p:AppxSymbolPackageEnabled=false' actually worked around the issue, for us. So thanks for that idea @Wuppie007 ! It's definitely a workaround though. So I'm still keen to see a proper resolution |
It seems to be that de parameter /p:AppxPackageOutput=$(Build.ArtifactStagingDirectory)\outputApp.msix is causing trouble. When removing this, the pipeline succeeds. But then there are several files created instead of one *.msix file |
Description
COPIED FROM Azure Pipelines Issue
Last week, we were using VSBuild@1 (version 1.245.0), last used Friday 13th September at 8pm UTC to successfully build and package an APPX.
On sunday (and today) we are using the same version (1.245.0), and the build is now failing with the following error:
I have raised this here INSTEAD of azure-pipelines-tasks because the task hasn't changed between the successful execution and the failure, so I don't beleive it's the task that has changed to make this fail, rather the hosting environment/agent
The task is configured as such (and has been like this for many months):
Critically - we can run this on the same commit that previously passed, and it now fails.
This is preventing us from releasing any changes and as such, for us, is critical to get a fix or workaround
Wondering if the fix deployed for this event was the cause
Which would be related to #10601
Platforms affected
Runner images affected
Image version and build link
20240912.1.0
Is it regression?
yes, 20240811.1.0
Expected behavior
For vsbuild@1 to build appx packages
Actual behavior
failed with the above error
Repro steps
The text was updated successfully, but these errors were encountered: