[.NET 9.0 Preview 5] Could not load file or assembly NuGet.ProjectModel

[alexeygritsenko]

Description

Hi, I'm looking forward to AndroidMavenLibrary, this is what I've been waiting for for a very long time and want to try. After all, for full-fledged development, we always lacked the libraries that developers use in Android Studio.

So I installed:
VS 2022 Preview
.NET 9.0 Preview 5
.NET 9.0 MAUI Workload

And added to Android Binding project

<ItemGroup>
  <AndroidMavenLibrary Include="com.squareup.okhttp3:okhttp" Version="4.9.3" />
</ItemGroup>

then output error:

1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028: System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.ProjectModel, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The specified file cannot be found.
1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028: File name: 'NuGet.ProjectModel, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.NuGetPackageVersionFinder.Create(String filename, TaskLoggingHelper log)
1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.DependencyResolver..ctor(String lockFile, TaskLoggingHelper log) in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/JavaDependencyVerification.cs:line 124
1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.JavaDependencyVerification.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/JavaDependencyVerification.cs:line 77
1>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25

Steps to Reproduce

see above

Link to public reproduction project repository

No response

Version with bug

Unknown/Other

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[drasticactions]

I don't believe this is related to the MAUI UI project. This is dotnet Android SDK tooling. Can you try this in a dotnet Android project (dotnet new android) that doesn't implement the MAUI UI tools? If it fails there, then I think you want the android tooling repo instead. @jonathanpeppers what do you think?

[dotnet-policy-service]

Hi @alexeygritsenko. We have added the "s/needs-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.

[jonathanpeppers]

@alexeygritsenko I would imagine this works fine with dotnet build? And it's only broken in Visual Studio or .NET framework MSBuild.exe?

[alexeygritsenko]

@drasticactions, Yes, this is reproduced in android native project (without MAUI), I didn't know that you have dotnet/android repo. Sorry if I posted this topic in the wrong place.
@jonathanpeppers, I did not think about that. You're right. I just checked through the command line and there is no such error.

In this case, when can I expect Visual Studio support?

[jpobst]

While we should of course address this root issue, also note that we already maintain an okhttp3 binding: https://www.nuget.org/packages/Square.OkHttp3.

[jonathanpeppers]

I had a memory of "how does this work without us shipping NuGet.ProjectModel.dll"?

But I can't remember where I posted that comment:

• https://github.com/dotnet/android/blob/main/build-tools/installers/create-installers.targets

[alexeygritsenko]

While we should of course address this root issue, also note that we already maintain an okhttp3 binding: https://www.nuget.org/packages/Square.OkHttp3.

Thanks. As for Square.OkHttp3 library, I know that it already exists in Nuget, I was just interested in testing how it works. In the future, I want to connect libraries that are not available on Nuget in this way, for example mikepenz/FastAdapter

[jpobst]

I had a memory of "how does this work without us shipping NuGet.ProjectModel.dll"?

I suspect it works because the msbuild process will very likely already have the NuGet libraries loaded in order to do the project build. However they may not be the version we expect, or perhaps a VS build can be broken up into small enough pieces that NuGet isn't in that msbuild process.

I think we will likely need to ILRepack the libraries to ensure we always have and use our expected versions.

[jonathanpeppers]

I think we will likely need to ILRepack the libraries to ensure we always have and use our expected versions.

I wanted to remove ILRepack, can we just ship the assembly like we normally would?

[drasticactions]

@drasticactions, Yes, this is reproduced in android native project (without MAUI), I didn't know that you have dotnet/android repo. Sorry if I posted this topic in the wrong place.

No worries! It's hard to tell sometimes where issues should go, since these tools are so interlinked and the brands can make it hard to tell what is going on. We just wanna make sure it gets to the right place. It's always better to file an issue somewhere than not file it at all.

[jpobst]

I wanted to remove ILRepack, can we just ship the assembly like we normally would?

Given that there is very likely a copy of this assembly already loaded in the msbuild process, and it may not match our version, I think we need it ILRepack'd but I could be wrong. I would think the same about other assemblies we currently ILRepack like Newtonsoft.JSON as well.

[jonathanpeppers]

No it's strong named and versioned, so it should work to just ship a copy.

[jpobst]

No it's strong named and versioned, so it should work to just ship a copy.

That should work for .NET framework which supports strong naming, but I suspect it won't work on .NET 6+ which doesn't check strong names.

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

(https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named)

For example, let's say we use an API added in Newtonsoft.Json 12.0, and a user's project includes another MSBuild task assembly that references and ships Newtonsoft.Json 11.0.

On a dotnet build, if their MSBuild task assembly is loaded first it will load 11.0 and I suspect our task would fail.

[dellis1972]

The old problem was that VS had third party extensions (ILSpy/Refactor) which shipped incompatible assembly versions for things like Cecil and NewtonSoft. These would break our tasks, so ILRepack was the only option.

Someone needs to test this in VS to make sure we do not hit any clashes.

[jonathanpeppers]

I think this PR will work in both VS and dotnet build:

• [installers] Ship NuGet* assemblies needed by <AndroidMavenLibrary>. #9098

An old sample I have is:

• https://github.com/jonathanpeppers/dotnet-using-task

1. VS / .NET framework should work, because the NuGet assemblies are strong-named and versioned. .NET framework can only load a single assembly with the same "identity", no matter if it is a different file path.

2. dotnet build should work. Even though it doesn't validate strong names, it can successfully load different assemblies from <UsingTask/>. dotnet build should be able to load assemblies of the same name with different paths.

ILRepack seems more useful for fixing Mono MSBuild and VS Mac, as Mono didn't do either 1 or 2.

If we are concerned, we could try different versions of Newtonsoft.Json in my sample above?