XA0107 Ignoring '' as it is a Reference Assembly #3898
Comments
jpobst
added
the
Area: App+Library Build
|
@maratoss can you attach a diagnostic MSBuild log? I think |
jonathanpeppers
added
the
need-info
|
log for this cmd: |
|
So I compared your log: To my log with a File -> New Project: It looks like your build isn't picking up Since, this is only happening on your build server. If you delete your NuGet cache at |
yes, it cannot pick that depended library for some reason same problem after:
then run
|
|
@jonathanpeppers btw do you have an idea why the link to the package is missing in that warning?
|
|
Is it the same version of Visual Studio (such as VS 2019 16.3.9) on both machines? The version of MSBuild and NuGet could affect this, but it shouldn't matter if you have Enterprise vs Community. Looking at the code we might need a But that doesn't explain the problem, it would just fix the warning message. |
|
TC machine 16.3.8, local machine 16.3.5 |
|
It looks like we already have a fix for the warning: 4d3d650 But this isn't shipping until a future release (16.5 Preview 1). I'll post a link to a build you can try when we have one. |
|
okay, thanks |
|
I am seeing similar issue on our on prem azure devops system. Strangely i can make it work if i use default nuget restore folder. However if i in the Nuget Restore step change the "destination folder" i am no longer able to build, and receive above error and warnings. This happens for multiple references. I will try and make a demo project. However our system is very complex, and i might not be able to do it. This is on a VS2019 agent only, if i use an Agent with VS17 and VS19 it works fine. |
|
@CSkoubo what are you doing to change the NuGet restore folder? Can you post an example? I can try that. |
|
I found the minimal example where I can reproduce the problem. My setup:
Result:
I attach my minimal example. |
|
@pasn I'm not getting any build warnings, but I have VS 16.4.1 (just came out). Can you try |
|
Sure. Here you are: |
|
@jonathanpeppers I reproduced the problem with VS 16.4.1 using exactly the same steps |
|
I see an error in your log: Can you use If using |
|
@jonathanpeppers thanks for info, I did not know that nuget.exe does not support Package References. Support for it was added in nuget 4.3.0. I tried to use msbuild /restore instead, but I have the same result. I also checked that after I do it, 'D:\Projects\Playground\Xamarin.Android.VS2019\DependencyInNetStandard\obj\project.assets.json' file is present. Could you re-check my new binary log and maybe try to unzip my example and execute this command on your side: New binlog: |
|
@pasn on 16.4, I get the blank filename warnings, but we have fixed this warning in 16.5 preview: I added this to <Reference Include="System.Configuration.ConfigurationManager" />Does that work for you? In the .NET 5 timeframe, we hope to rework the MSBuild task emitting the warnings/errors here. |
|
@jonathanpeppers, here are more details about the issue. I expect these two commands both to produce the same result:
For VS2017 both builds would end with success, but not for VS2019. Broader context is that we have big solution with Android, iOS, .NET Core and .NET Framework applications using a lot of .NET Standard libraries. We are now migrating from VS2017 to VS2019. Xamarin.Android's _ResolveAssemblies task is the only blocker for this migration. If this issue is not solved, restoring packages to separate path would require testing every time when new package is added/updated/removed. Transitive dependencies resolution (added with Package References) won't be that useful as it was before. I could add missing references to Android project, but I see it as a workaround and not the real solution. Could you check why restoring to separate directory works differently from restoring to the default one? I provide you with the binlog file for successful build for comparison. The only difference I could see in diagnostics log is that the task producing XA0107 warning for failed build would find the DLL from lib folder instead. |
Does this actually solve your problem in your real project? It would be adding the one reference in the main app project. The real solution is to completely remove Let me know if the workaround works in your real solution or not, thanks! |
|
Same issue here (with Microsoft hosted agents on Azure DevOps). Our CI pipeline was setting the NuGet package path to have control over it for caching purposes (like documented). We didn't want to cache the existing packages the build agent already comes with, and instead we only want the packages our builds actually require. As such we specified the path instead of using the default one. As @pasn explained, simply not setting the packages path resolves the issue for us. We've currently turned off the caching anyway, but in the future, we may turn it back on. Then later we may decide to split our solution (.NET Core 3.0+, .NET Standard 2.1+, Xamarin.Android 10.0+) up, so we build and cache the Xamarin.Android projects independently. I'm not looking forward to that pipeline complexity because we also reference our projects from the Xamarin.Android ones... tl;dr: Using the default NuGet packages path works for us, too. The reason we're not using the other (potential) workaround mentioned, i.e. adding the package reference to the Xamarin project: We are hitting this issue with at least 3 packages already and do not want to specify transitively needed packages manually this way. |
We will try it next week. Treat this nuget as an example. We have the same problem with System.IO.Pipelines package and not sure how many more such errors may appear in the rest of our Android apps. Still, Do you know what is the source of different behaviour between these two scenarios? |
|
Hi @jonathanpeppers. I tried your workaround and added this to App.csproj: Unfortunately this has no impact. I tried it on our real solution, but later on also on this min example. My colleague tried it as well and also could not get it to work. We also tried to include nuget package directly in Android project, but it also did not help. Are you sure that you are building with this command? The only workaround we know now is to restore to default directory. This is ok on dev machines, but not in our CI. This is because we have multiple agents working on the same machine and many build definitions, so we want to minimize the impact they have on each other. PS: System.Configuration.ConfigurationManager is not the only package we have problems with. Other examples:
|
grendello
removed
the
need-info
|
@jonathanpeppers : is it possible to somehow work around this issue by modifying the in the affected projects after the import of Xamarin targets? |
|
Hi all, Another package that is giving issues is the Extension framework from the Asp core team. When following the blog post from James Montemagno about using the Asp Core DI framework the build servers (Hosted and private) are unable to build the Android project. It gives the same (kind of) errors: ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1808,2): Error XA2002: Can not resolve reference: Issue on the dotnet extension GitHub page has been opened on: https://github.com/dotnet/extensions/issues/1631 For troubleshooting I've created the a GitHub repo at https://github.com/rneeft/XamarinDotNetCoreIssue The Android project is building fine on my dev machine but it doesn't build on the build agents. |
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
@rneeft does your local machine have a newer Xamarin.Android than the build agents? That could be the cause. We are trying to rework this code path that has been around since the beginning of Xamarin.Android (before my time). It will take some time as it is not easy: #4171 If this change breaks existing projects, things will be even more complicated. |
|
@jonathanpeppers I don't think so but to be sure I've setup a new Windows Server 2019 with Visual Studio 2019 and configure it as a build agent. It still gives errors. I've installed the same components as on my local machine. (In the repo https://github.com/rneeft/XamarinDotNetCoreIssue/blob/master/machine/.vsconfig I've push my .vsconfig) Solution is building fine when cloned on the build server and build via visual studio manually. Please let me know if I need to do/test something. |
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. We can also remove: * Any of the `<PackageReference Include="NuGet.*" />` packages we are using. * `MetadataResolver` class, `NuGetLogger` class The first issue I found was that we have to include these references by default: Java.Interop; Mono.Security; System.Net.Http; System.ServiceModel.Internals; System.Runtime; `System.dll` references `Mono.Security.dll`. `Mono.Android.dll` references `System.Net.Http.dll` due to `AndroidClientHandler`. The dependency tree for `System.ServiceModel.Internals.dll` is somewhat more convoluted: Adding assembly reference for Mono.Android, recursively... Adding assembly reference for System.Drawing.Common, recursively... Adding assembly reference for System.Runtime.Serialization, recursively... Adding assembly reference for System.ServiceModel.Internals, recursively... The next issue I hit was building the SmartHotel360 app in `Release`: error XALNK7000: Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA2006: Could not resolve reference to 'System.CodeDom.Compiler.ICodeGenerator' (defined in assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') with scope 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. When the scope is different from the defining assembly, it usually means that the type is forwarded. ---> Mono.Cecil.ResolutionException: Failed to resolve System.CodeDom.Compiler.ICodeGenerator at Mono.Linker.Steps.MarkStep.HandleUnresolvedType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference) at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkField(FieldReference reference) at Mono.Linker.Steps.MarkStep.InitializeFields(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly) at Mono.Linker.Steps.MarkStep.Initialize() at Mono.Linker.Steps.MarkStep.Process(LinkContext context) at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Run(Pipeline pipeline, LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) --- End of inner exception stack trace --- at Java.Interop.Tools.Diagnostics.Diagnostic.Error(Int32 code, Exception innerException, String message, Object[] args) in C:\src\xamarin-android\external\Java.Interop\src\Java.Interop.Tools.Diagnostics\Java.Interop.Tools.Diagnostics\Diagnostic.cs:line 166 at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.RunTask() at Xamarin.Android.Tasks.AndroidTask.Execute() I reworked `<LinkAssemblies/>` to use a single `AssemblyResolver` that uses `FrameworkDirectories` as search directories: <LinkAssemblies ... FrameworkDirectories="$(_XATargetFrameworkDirectories);$(_XATargetFrameworkDirectories)Facades" With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. We can also remove: * Any of the `<PackageReference Include="NuGet.*" />` packages we are using. * `MetadataResolver` class, `NuGetLogger` class The first issue I found was that we have to include these references by default: Java.Interop; Mono.Security; System.Net.Http; System.ServiceModel.Internals; System.Runtime; `System.dll` references `Mono.Security.dll`. `Mono.Android.dll` references `System.Net.Http.dll` due to `AndroidClientHandler`. The dependency tree for `System.ServiceModel.Internals.dll` is somewhat more convoluted: Adding assembly reference for Mono.Android, recursively... Adding assembly reference for System.Drawing.Common, recursively... Adding assembly reference for System.Runtime.Serialization, recursively... Adding assembly reference for System.ServiceModel.Internals, recursively... The next issue I hit was building the SmartHotel360 app in `Release`: error XALNK7000: Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA2006: Could not resolve reference to 'System.CodeDom.Compiler.ICodeGenerator' (defined in assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') with scope 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. When the scope is different from the defining assembly, it usually means that the type is forwarded. ---> Mono.Cecil.ResolutionException: Failed to resolve System.CodeDom.Compiler.ICodeGenerator at Mono.Linker.Steps.MarkStep.HandleUnresolvedType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference) at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkField(FieldReference reference) at Mono.Linker.Steps.MarkStep.InitializeFields(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly) at Mono.Linker.Steps.MarkStep.Initialize() at Mono.Linker.Steps.MarkStep.Process(LinkContext context) at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Run(Pipeline pipeline, LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) --- End of inner exception stack trace --- at Java.Interop.Tools.Diagnostics.Diagnostic.Error(Int32 code, Exception innerException, String message, Object[] args) in C:\src\xamarin-android\external\Java.Interop\src\Java.Interop.Tools.Diagnostics\Java.Interop.Tools.Diagnostics\Diagnostic.cs:line 166 at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.RunTask() at Xamarin.Android.Tasks.AndroidTask.Execute() I reworked `<LinkAssemblies/>` to use a single `AssemblyResolver` that uses `FrameworkDirectories` as search directories: <LinkAssemblies ... FrameworkDirectories="$(_XATargetFrameworkDirectories);$(_XATargetFrameworkDirectories)Facades" With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. We can also remove: * Any of the `<PackageReference Include="NuGet.*" />` packages we are using. * `MetadataResolver` class, `NuGetLogger` class The first issue I found was that we have to include these references by default: Java.Interop; Mono.Security; System.Net.Http; System.Runtime; System.Runtime.Serialization; System.ServiceModel.Internals; `System.dll` references `Mono.Security.dll`. `Mono.Android.dll` references `System.Net.Http.dll` due to `AndroidClientHandler`. The dependency tree for `System.ServiceModel.Internals.dll` is somewhat more convoluted: Adding assembly reference for Mono.Android, recursively... Adding assembly reference for System.Drawing.Common, recursively... Adding assembly reference for System.Runtime.Serialization, recursively... Adding assembly reference for System.ServiceModel.Internals, recursively... The next issue I hit was building the SmartHotel360 app in `Release`: error XALNK7000: Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA2006: Could not resolve reference to 'System.CodeDom.Compiler.ICodeGenerator' (defined in assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') with scope 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. When the scope is different from the defining assembly, it usually means that the type is forwarded. ---> Mono.Cecil.ResolutionException: Failed to resolve System.CodeDom.Compiler.ICodeGenerator at Mono.Linker.Steps.MarkStep.HandleUnresolvedType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference) at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkField(FieldReference reference) at Mono.Linker.Steps.MarkStep.InitializeFields(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly) at Mono.Linker.Steps.MarkStep.Initialize() at Mono.Linker.Steps.MarkStep.Process(LinkContext context) at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Run(Pipeline pipeline, LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) --- End of inner exception stack trace --- at Java.Interop.Tools.Diagnostics.Diagnostic.Error(Int32 code, Exception innerException, String message, Object[] args) in C:\src\xamarin-android\external\Java.Interop\src\Java.Interop.Tools.Diagnostics\Java.Interop.Tools.Diagnostics\Diagnostic.cs:line 166 at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.RunTask() at Xamarin.Android.Tasks.AndroidTask.Execute() I reworked `<LinkAssemblies/>` to use a single `AssemblyResolver` that uses `FrameworkDirectories` as search directories: <LinkAssemblies ... FrameworkDirectories="$(_XATargetFrameworkDirectories);$(_XATargetFrameworkDirectories)Facades" With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
One of the remaining pain points in the Xamarin.Android build is the `<ResolveAssemblies/>` MSBuild task. 1. It isn't particularly fast and runs on *every* build. During the devloop it runs twice for `Build` and `Install`. It runs for DTBs, designer builds, too. 2. It breaks for certain NuGet packages as mentioned on a few Github issues: dotnet#3898 dotnet#4074 After some research and looking at build logs, we may be able to rework the behavior: 1. Remove NuGet-related code and recursive assembly searching. 2. Use `@(_ReferencePath)` and `@(_ReferenceDependencyPaths)`. 3. Include assemblies even if they have `%(ResolvedFrom)` == `ImplicitlyExpandDesignTimeFacades`. We can also remove: * Any of the `<PackageReference Include="NuGet.*" />` packages we are using. * `MetadataResolver` class, `NuGetLogger` class The first issue I found was that we have to include these references by default: Java.Interop; Mono.Security; System.Net.Http; System.Runtime; System.Runtime.Serialization; System.ServiceModel.Internals; `System.dll` references `Mono.Security.dll`. `Mono.Android.dll` references `System.Net.Http.dll` due to `AndroidClientHandler`. The dependency tree for `System.ServiceModel.Internals.dll` is somewhat more convoluted: Adding assembly reference for Mono.Android, recursively... Adding assembly reference for System.Drawing.Common, recursively... Adding assembly reference for System.Runtime.Serialization, recursively... Adding assembly reference for System.ServiceModel.Internals, recursively... The next issue I hit was building the SmartHotel360 app in `Release`: error XALNK7000: Java.Interop.Tools.Diagnostics.XamarinAndroidException: error XA2006: Could not resolve reference to 'System.CodeDom.Compiler.ICodeGenerator' (defined in assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') with scope 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. When the scope is different from the defining assembly, it usually means that the type is forwarded. ---> Mono.Cecil.ResolutionException: Failed to resolve System.CodeDom.Compiler.ICodeGenerator at Mono.Linker.Steps.MarkStep.HandleUnresolvedType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkType(TypeReference reference) at MonoDroid.Tuner.MonoDroidMarkStep.MarkType(TypeReference reference) at Mono.Linker.Steps.MarkStep.MarkField(FieldReference reference) at Mono.Linker.Steps.MarkStep.InitializeFields(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeType(TypeDefinition type) at Mono.Linker.Steps.MarkStep.InitializeAssembly(AssemblyDefinition assembly) at Mono.Linker.Steps.MarkStep.Initialize() at Mono.Linker.Steps.MarkStep.Process(LinkContext context) at MonoDroid.Tuner.MonoDroidMarkStep.Process(LinkContext context) at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step) at Mono.Linker.Pipeline.Process(LinkContext context) at MonoDroid.Tuner.Linker.Run(Pipeline pipeline, LinkContext context) at MonoDroid.Tuner.Linker.Process(LinkerOptions options, ILogger logger, LinkContext& context) at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) --- End of inner exception stack trace --- at Java.Interop.Tools.Diagnostics.Diagnostic.Error(Int32 code, Exception innerException, String message, Object[] args) in C:\src\xamarin-android\external\Java.Interop\src\Java.Interop.Tools.Diagnostics\Java.Interop.Tools.Diagnostics\Diagnostic.cs:line 166 at Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver res) at Xamarin.Android.Tasks.LinkAssemblies.RunTask() at Xamarin.Android.Tasks.AndroidTask.Execute() I reworked `<LinkAssemblies/>` to use a single `AssemblyResolver` that uses `FrameworkDirectories` as search directories: <LinkAssemblies ... FrameworkDirectories="$(_XATargetFrameworkDirectories);$(_XATargetFrameworkDirectories)Facades" With these changes I am still able to build SmartHotel360, and the `<ResolveAssemblies/>` is an order of magnitude quicker: Before: 310 ms ResolveAssemblies 1 calls After: 44 ms ResolveAssemblies 1 calls So this would save ~532ms (x2 620ms -> 88ms) from the dev-loop. This is a big WIP, as I need to figure out what types of projects this might break. Let's see what happens on CI!
|
@jonathanpeppers
|
|
yes @jonathanpeppers and @maratoss I also confirm the issue is gone. My test project is building fine now on the build server. Great work guys!! |
|
Hello, I've got the same (or very similar) error happening. If I create a new Xamarin Forms App targeting iOS and Android, install IPFS.Engine via nuget then I get the following: Looks like one of the packages that the installed package references is a "referenced assembly". Annoyingly, this used to build but then I updated my VS, in an attempt to fix one thing, and it broke this instead. I'm on VS 2019 version 16.6.0, Xamarin.Android SDK is at 10.3.1.0 (i.e. everything is latest version) Anybody got any thoughts on how to fix this? I've updated everything already! |
|
@markjerz, if you get a chance, if you can open a new issue for that behavior and attach a .zip file of your diagnostic MSBuild output or a .zip file of a small test project that reproduces the issue so that the team can take a look, that would be excellent. Thanks in advance! |
|
@brendanzagaeski This seemed so close to this issue that I replied here, apologies. I've now opened a new issue here: #4729 |
ghost
locked as resolved and limited conversation to collaborators
Steps to Reproduce
This is reproduced only on my Teamcity machine.
On my local PC it works well.
And one more strange thing is this warning with no path to file
I tried to build with VS and with MSBuild same result.
Seems smth wrong with a configuration of my buid machine, but i do not have a clue what need to change to get it worked.
Expected Behavior
Build success
Actual Behavior
Build failed with following errors:
Version Information
Log File
log.txt
The text was updated successfully, but these errors were encountered: