Xamarin-android: System.IO.Packaging not resolved correctly

[alexdrl]

Steps to Reproduce

We're having an issue with a Xamarin project, which as we added System.IO.Packaging 4.4.1 nuget package dependency, the reference is resolved as the ref/netstandard1.3 DLL, a reference assembly. It seems that because of that, the Xamarin app fails to start because this DLL does not get packaged, and so the app fails to start with this common xamarin error https://forums.xamarin.com/discussion/63584/android-could-not-load-assembly-xxx-during-startup-registration

There seems to be an issue open related to that https://github.com/dotnet/corefx/issues/23830

Expected Behavior

The application starts correctly.

Actual Behavior

The application fails to start with the "Could not load assembly 'xxx' during startup registration" error.

Version Information

VS 15.5.2
Xamarin 4.8
Xamarin.Android 8.1

VS bug #580833

[weshaggard]

@marek-safar @akoeplinger does System.IO.Packaging exist in the Xamarin platform?

[marek-safar]

@weshaggard no, we thought as this is fully managed assembly and we never supported it we could just get it from nuget as netstandard1.x

[weshaggard]

@marek-safar you're right this package doesn't have the Xamarian placeholders in it so it should be using the netstandard implementation.

@alexdrl can you give more information on the error you are hitting? Such as which assembly cannot be loaded? Can you also verify what assembly is getting deployed with your application? I would expect the lib\netstandard1.3 or lib\netstandard2.0 library to be deployed.

[jonpryor]

This feels like a variation on Bug #57342 and other bugs that I vaguely recall seeing but can't readily find.

@dellis1972: Do you remember anything more recent/specific?

@alexdrl: Could you please provide the diagnostic build output of the packaging process for your app?

msbuild /v:diag /t:SignAndroidPackage App.csproj > b.txt

Then upload b.txt "somewhere" (gist.github.com works).

[jonpryor]

Possibly related?

• https://github.com/xamarin/xamarin-macios/pull/2643
• https://github.com/xamarin/xamarin-macios/pull/2731

[alexdrl]

@jonpryor This is the build log. https://gist.github.com/alexdrl/9b1e284b6227e02a3413cb209aa4de84

[alexdrl]

@weshaggard This is the debug log that is displaying running the android app https://gist.github.com/alexdrl/39fb731fadd62d84fcd8ed2952e707e0

[marek-safar]

@alexdrl please attach full re-build log with verbosity level set to Diagnostic

[alexdrl]

@marek-safar I uploaded the file to this temporary repo as this is huge for the gist to manage, it is located here https://github.com/alexdrl/msbuildlog/blob/master/cleanlog.zip

[dellis1972]

@jonpryor looks like the fix we put in for ignoring reference assemblies is working . I see this following in the log file from above.

warning : Ignoring D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3 as it is a Reference Assembly [D:\W\AR\RPQPrototype\HealthAndWelfare\UI\Mobile\XF\Main\Droid\XF.Main.Droid.csproj]

So I guess we are correctly ignoring the reference assembly, but for some reason the actual assembly we need is not included in the list of resolved assemblies.

[jonpryor]

I'm not certain that we are ignoring the reference assembly:

  BuildApk Task (TaskId:1229)
    ApkInputPath: obj\Debug\android\bin\packaged_resources (TaskId:1229)
      ...
      obj\Debug\android\assets\System.IO.Packaging.dll (TaskId:1229)

So we're finding a System.IO.Packaging.dll assembly, and copying into obj\Debug\android\assets. Where's it coming from? This is where MSBuild diagnostic output is wonderful, compared to xbuild...

Task "BuildApk" (TaskId:1229)
  Task Parameter:AndroidNdkDirectory=C:\ProgramData\Microsoft\AndroidNDK64\android-ndk-r13b\ (TaskId:1229)
  Task Parameter:ApkInputPath=obj\Debug\android\bin\packaged_resources (TaskId:1229)
  Task Parameter:ApkOutputPath=obj\Debug\android\bin\RPQPrototype.Android.apk (TaskId:1229)
  Task Parameter:EmbedAssemblies=False (TaskId:1229)
  Task Parameter:
      ResolvedUserAssemblies=
      ...
  Task Parameter:
      EmbeddedNativeLibraryAssemblies=
      ...
          D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3\System.IO.Packaging.dll
                  CopyLocal=false
                  FusionName=System.IO.Packaging, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
                  ImageRuntime=v4.0.30319
                  NuGetIsFrameworkReference=false
                  NuGetPackageId=System.IO.Packaging
                  NuGetPackageVersion=4.0.0
                  NuGetSourceType=Package
                  OriginalItemSpec=D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3\System.IO.Packaging.dll
                  Private=false
                  ReferenceAssembly=D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3\System.IO.Packaging.dll
                  ReferenceSourceTarget=ResolveAssemblyReference
                  ResolvedFrom={RawFileName}
                  Version=

That does not look right; @(ReferencePath) and/or @(ReferenceDependencyPaths) is hitting the reference assembly, not the actual assembly.

Regardless, that doesn't answer where obj\Debug\android\assets\System.IO.Packaging.dll is coming from. Searching further backward...

Task "LinkAssemblies" (TaskId:1189)
  Task Parameter:UseSharedRuntime=true (TaskId:1189)
  Task Parameter:MainAssembly=obj\Debug\android\assets\ADDInformatica.RPQPrototype.HealthAndWelfare.UI.Mobile.XF.Main.Droid.dll (TaskId:1189)
  Task Parameter:OutputDirectory=obj\Debug\linkdst\ (TaskId:1189)
  Task Parameter:OptionalDestinationDirectory=obj\Debug\android\assets\ (TaskId:1189)
  Task Parameter:LinkMode=None (TaskId:1189)
  Task Parameter:LinkDescriptions=LinkDescription.xml (TaskId:1189)
  Task Parameter:LinkOnlyNewerThan=obj\Debug\link.flag (TaskId:1189)
  Task Parameter:
      ResolvedAssemblies=
          ...
          D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3\System.IO.Packaging.dll

The <LinkAssemblies/> task (optionally) links the assemblies -- LinkMode=None here, so no linking is performed -- and copies the assemblies into obj\Debug\android\assets.

We thus infer that @(ResolvedAssemblies) erroneously contains the reference assembly.

We may be emitting the warning about ignoring a reference assembly, but notice that we're ignoring netstandard1.3, not System.IO.Packaging.dll. It's System.IO.Packaging.dll which is causing problems.

@(ResolvedAssemblies) is set by the <ResolveAssemblies/> task, and we see that @(FIlteredAssemblies) contains the reference assembly:

Task "ResolveAssemblies" (TaskId:1169)
  Task Parameter:
      Assemblies=
          ...
          D:\W\Packages\system.io.packaging\4.0.0\ref\netstandard1.3\System.IO.Packaging.dll

Unfortunately, it appears that our creation of @(FilteredAssemblies) removes the item metadata, so we don't see any metadata within the above fragment.

@(FilteredAssemblies) in turn comes from @(ReferenceCopyLocalPaths) and @(ReferencePath). Unfortunately, I can't quickly find where System.IO.Packaging.dll is coming from to be located within either @(ReferenceCopyLocalPaths) or @(ReferencePath).

[dellis1972]

Some more informations. It looks like the required target ResolvePackageDependenciesForBuild is not built. This is probably because it is part of the Microsoft.NET.Sdk.targets. Since android (and iOS) projects do not use the new project format I suspect that those targets are not being imported. They are then never run, so we end up with the wrong references.

@radical might be able to confirm this. I'm trying to see what we need to do to add this to android.

[ConX-Ryan]

what is the estimated working timeline on fixing this and the downstream issues? 1196

Xamarin Forms with .NETStandard 2.0 is DOA at the moment

[dellis1972]

@ConX-Ryan from my understanding this is a problem in the MSbuild NetStandard targets so this will probably be tracked on Microsoft/msbuild#2776. @radical can you confirm that is the case?

[johnwmcintosh]

I'm having this problem with EF Core 2.0.1 as described here https://stackoverflow.com/questions/48956433/ef-core-2-0-1-unsafe-in-xamarin-android

@JonDouglas asked I post a "reaction" here. Not sure what that means so I'm just using a comment.

[jonpryor]

@dellis1972: This is thought provoking: https://github.com/xamarin/xamarin-macios/issues/3199#issuecomment-369312646

With a .NET Core project, for example, there are two steps: build and publish. The build target compiles against the ref assembly. The publish target will result in the lib assembly being copied to the publish directory so it can be used at runtime.

Should we follow suite, such that our "Build" step can use reference assemblies, while the "Publish" step acquires and uses the actual assemblies?

Can we follow suite? Is such a change supportable by our build process?

[dellis1972]

ResolveAssemblies is what we use to pull together the list of assemblies we need to package. See https://github.com/xamarin/xamarin-android/pull/1356

[alexdrl]

I am getting this error with the same Project that made me opened this issue, using VS 15.7.3. I Thought that the issue was closed because the problem is solved but I tried with no luck.

It is blocked bt https://github.com/Microsoft/msbuild/issues/2776 ?