search

xamarin / xamarin-macios

.NET for iOS, Mac Catalyst, macOS, and tvOS provide open-source bindings of the Apple SDKs for use with .NET managed languages such as C#
Other
2.44k stars 508 forks source link

`NullReferenceException` during `FixReferencedItems` in `Xamarin.Messaging.Build.Client.TaskRunner` #21093

Closed MartinZikmund closed 2 weeks ago

MartinZikmund commented 3 weeks ago

Apple platform

iOS

Framework version

net8.0-*

Affected platform version

VS 2022 17.11.1

Description

When trying to build and run iOS Uno Platform test application on iOS Simulator, we are suddenly getting the following error in VS 2022 17.11.1:

C:\Program Files\dotnet\packs\Microsoft.iOS.Windows.Sdk.net8.0_17.0\17.0.8523\tools\msbuild\iOS\Xamarin.iOS.Common.After.targets(286,3): error MSB4018: The "Copy" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
   at Xamarin.Messaging.Build.Client.TaskRunner.FixReferencedItems(ITaskItem[] items) in D:\a\_work\1\s\src\MSBuild\Xamarin.Messaging.Build.Client\TaskRunner.cs:line 237
   at Microsoft.Build.Tasks.Copy.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks/MsBuildTasks/Copy.cs:line 12
   at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [D:\Work\uno\src\SamplesApp\SamplesApp.netcoremobile\SamplesApp.netcoremobile.csproj]

When trying the same in VS 2022 17.12.0 Preview, I got exactly the same error as in https://github.com/xamarin/xamarin-macios/issues/21005 instead

Steps to Reproduce

  1. Clone master of https://github.com/unoplatform/uno
  2. In src folder rename crosstargeting_override.props.sample to crosstargeting_override.props
  3. Open this file and uncomment line with and change it to net8.0-ios
  4. Save the props file and open Uno.UI-netcoremobile-only.slnf
  5. Connect to a remote Mac
  6. Try to run SamplesApp.netcoremobile on any iOS 17.5 Simulator

Did you find any workaround?

No

Build logs

The app project is SamplesApp.netcoremobile_Debug_AnyCPU

all.zip

rolfbjarne commented 3 weeks ago

17.0.8523

Is TargetFramework=net8.0-ios17.0 in your app project?

MartinZikmund commented 2 weeks ago

@rolfbjarne Yes, I was using net8.0-ios17.0. In the repro steps I mention that net8.0-ios should be used in the target framework override file, but in another .props file we then replace it with net8.0-ios17.0

rolfbjarne commented 2 weeks ago

@rolfbjarne Yes, I was using net8.0-ios17.0. In the repro steps I mention that net8.0-ios should be used in the target framework override file, but in another .props file we then replace it with net8.0-ios17.0

Is there any particular reason you're using net8.0-ios17.0 as opposed to net8.0-ios? By using the 17.0 version, you pick up an older version of the iOS workload, which has this bug. Using net8.0-ios will use the latest version of the iOS, where the bug is fixed.

microsoft-github-policy-service[bot] commented 2 weeks ago

Hi @MartinZikmund. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

MartinZikmund commented 2 weeks ago

I can confirm I am now able to build and deploy the app with Visual Studio 2022 17.12 Preview. For VS 17.11.1 I have hit another, likely unrelated issue - https://developercommunity.visualstudio.com/t/Unable-to-build-iOS-app-on-remote-Mac:-/10732362 .

Thanks a lot for the help!

Youssef1313 commented 2 weeks ago

@rolfbjarne Yes, we are using the oldest supported version so that users using older .NET SDK versions don't break. That's basically why we wanted https://github.com/dotnet/sdk/issues/30103

rolfbjarne commented 2 weeks ago

@rolfbjarne Yes, we are using the oldest supported version so that users using older .NET SDK versions don't break. That's basically why we wanted dotnet/sdk#30103

There's a difference between a library project and an executable project - using an earlier TargetFramework version makes sense for a library project, because you're keeping compatibility with consumers of that library project. Nobody is consuming an executable project though, so for executable projects we recommend using the latest TargetFramework (or the default).

Youssef1313 commented 2 weeks ago

Ah okay, this bug is only relevant for executables? We can fix it on our side. We were aligning TargetFramework for all projects in the solution, but we can only do it for libraries.

rolfbjarne commented 2 weeks ago

Ah okay, this bug is only relevant for executables? We can fix it on our side. We were aligning TargetFramework for all projects in the solution, but we can only do it for libraries.

It's more that using the earliest TargetFramework is only relevant for libraries (and this bug won't affect library builds).