Build error with EFCore 3 #4074
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
bug
Component does not function as intended.
Milestone
Comments
VladislavAntonyuk
added
the
Area: App+Library Build
|
Hi @VladislavAntonyuk this project seemed to work for me: EFCore3Repro.zip Can you see if there is a difference between this project and yours? Can you attach a diagnostic MSBuild log, too? Thanks! |
jonathanpeppers
added
the
need-info
|
I can add that issue is reproduced if you set NuGet.config file with custom globalPackageFolder |
|
Hmm, the I could only reproduce via the https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#config-section Either way, I can repro this now, thanks! This might be the same issue as: #3898 |
jonathanpeppers
added
bug
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 7, 2020
|
I can reproduce the issue in a test: master...jonathanpeppers:issue4074 Unfortunately, I see no way for us to actually "find" the assembly here. Stepping through the code, I don't see how we can locate The simple workaround is to add the 641def6#diff-571cf18620dfe20db6f256078c834986R4208-R4211 Does this fix work for you as well? Just add this to your main app project: <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.0" />This |
|
I have added both EFCore and EFCore.Relations but it didn’t solve the issue. |
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 24, 2020
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!
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 27, 2020
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!
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 29, 2020
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!
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 29, 2020
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!
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 29, 2020
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!
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 29, 2020
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
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jan 30, 2020
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 I hit by the original bug and technically willing to help, but not sure that I properly understand the scope of current change in the WIP PR and what part of Xamarin build process is affected by the bug. Will it be practical for me start debugging from current master, or better attempt to fix some cases which not fully covered in WIP PR ? |
|
the issue is solved with the latest nightly version of Xamarin.Forms (4.7)/EF(5.0) and Preview version of Visual Studio (16.5) |
|
thanks! glad to hear. will check it out. |
|
I just received this issue with the latest .net core version, and adding package 3.1.7. it tries to look at my packages out of my user directory. Added a simple .net core 3.1 project and added this reference. Added a new DBContext type and tried to build. Blows up wtih this error Error An attempt was made to load an assembly with an incorrect format: |
|
@DanielWalters101 to my knowledge Xamarin projects would not implement (or use) If so, you probably need to file an issue here: https://github.com/dotnet/efcore/issues If you think it's something with Xamarin.Android can you file a new issue with a diagnostic MSBuild log or sample project? Thanks! |
|
Xamarin android and iOS works with netstandard2.1 |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4>D:\Miscellaneous\source\repos\draw-go\Packages\microsoft.bcl.asyncinterfaces\1.1.0\ref\netstandard2.1\Microsoft.Bcl.AsyncInterfaces.dll : warning XA0107: Ignoring Reference Assembly
D:\Miscellaneous\source\repos\draw-go\Packages\microsoft.bcl.asyncinterfaces\1.1.0\ref\netstandard2.1\Microsoft.Bcl.AsyncInterfaces.dll.4>D:\Miscellaneous\source\repos\draw-go\Packages\microsoft.bcl.hashcode\1.1.0\ref\netstandard2.1\Microsoft.Bcl.HashCode.dll : warning XA0107: Ignoring Reference Assembly
D:\Miscellaneous\source\repos\draw-go\Packages\microsoft.bcl.hashcode\1.1.0\ref\netstandard2.1\Microsoft.Bcl.HashCode.dll.4>D:\Miscellaneous\source\repos\draw-go\Packages\system.runtime.compilerservices.unsafe\4.7.0\ref\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll : warning XA0107: Ignoring Reference Assembly
D:\Miscellaneous\source\repos\draw-go\Packages\system.runtime.compilerservices.unsafe\4.7.0\ref\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll.4>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1815,2): error XA2002: Can not resolve reference:
Microsoft.Bcl.AsyncInterfaces, referenced byMicrosoft.EntityFrameworkCore. Please add a NuGet package or assembly reference forMicrosoft.Bcl.AsyncInterfaces, or remove the reference toMicrosoft.EntityFrameworkCore.4>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1815,2): error XA2002: Can not resolve reference:
Microsoft.Bcl.AsyncInterfaces, referenced byMicrosoft.EntityFrameworkCore.InMemory. Please add a NuGet package or assembly reference forMicrosoft.Bcl.AsyncInterfaces, or remove the reference toMicrosoft.EntityFrameworkCore.InMemory.4>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1815,2): error XA2002: Can not resolve reference:
Microsoft.Bcl.AsyncInterfaces, referenced byMicrosoft.EntityFrameworkCore.Relational. Please add a NuGet package or assembly reference forMicrosoft.Bcl.AsyncInterfaces, or remove the reference toMicrosoft.EntityFrameworkCore.Relational.4>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1815,2): error XA2002: Can not resolve reference:
Microsoft.Bcl.AsyncInterfaces, referenced byMicrosoft.EntityFrameworkCore.Sqlite. Please add a NuGet package or assembly reference forMicrosoft.Bcl.AsyncInterfaces, or remove the reference toMicrosoft.EntityFrameworkCore.Sqlite.4>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1815,2): error XA2002: Can not resolve reference:
Microsoft.Bcl.AsyncInterfaces, referenced bySystem.Text.Json. Please add a NuGet package or assembly reference forMicrosoft.Bcl.AsyncInterfaces, or remove the reference toSystem.Text.Json.Steps to Reproduce
Note: Adding Microsoft.Bcl.AsyncInterfaces (version 1.1.0) doesn't solve the issue
Expected Behavior
No error
Actual Behavior
Build error
Version Information
Microsoft Visual Studio Professional 2019 Preview
Version 16.5.0 Preview 1.0
VisualStudio.16.Preview/16.5.0-pre.1.0+29521.150
Microsoft .NET Framework
Version 4.8.03752
Installed Version: Professional
Visual C++ 2019 00435-60000-00000-AA249
Microsoft Visual C++ 2019
ASP.NET and Web Tools 2019 16.5.126.18061
ASP.NET and Web Tools 2019
ASP.NET Web Frameworks and Tools 2019 16.5.126.18061
For additional information, visit https://www.asp.net/
Azure App Service Tools v3.0.0 16.5.126.18061
Azure App Service Tools v3.0.0
C# Tools 3.5.0-beta1-19571-01+fb3f812a3e4b7534bef784fa2df1c21d1f67864d
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Color Picker 1.0
Integrated Color Picker for Visual Studio IDE and Editor
Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
EditProj 1.0
This packages allows you to edit project and solution files without the need to unload them first.
Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.
IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed Info
JetBrains ReSharper Ultimate 2019.3.1 Build 193.0.20191219.91525
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright © 2020 JetBrains, Inc.
Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
Microsoft Library Manager 2.1.3+g9c91cdec24
Install client-side libraries easily to any web project
Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers
Microsoft Visual C++ Wizards 1.0
Microsoft Visual C++ Wizards
Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.
Microsoft Visual Studio VC Package 1.0
Microsoft Visual Studio VC Package
Mono Debugging for Visual Studio 16.5.505 (ecce84f)
Support for debugging Mono processes with Visual Studio.
NuGet Package Manager 5.5.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/
ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info
SQL Server Data Tools 16.0.61911.21070
Microsoft SQL Server Data Tools
StylerPackage Extension 1.0
StylerPackage Visual Stuido Extension Detailed Info
Tizen.STV.Extension Extension 1.0
Tizen.STV.Extension Visual Studio Extension Detailed Info
TypeScript Tools 16.0.11113.2001
TypeScript Tools for Microsoft Visual Studio
UnoPlatformPackage Extension 1.0
UnoPlatformPackage Visual Studio Extension Detailed Info
Visual Basic Tools 3.5.0-beta1-19571-01+fb3f812a3e4b7534bef784fa2df1c21d1f67864d
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual F# Tools 10.4 for F# 4.6 16.5.0-beta.19556.3+c2b6d5980a7f64dd4e46448b9b4f5d96eb415aeb
Microsoft Visual F# Tools 10.4 for F# 4.6
Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio
Visual Studio Container Tools Extensions (Preview) 1.0
View, manage, and diagnose containers within Visual Studio.
Visual Studio Tools for CMake 1.0
Visual Studio Tools for CMake
Visual Studio Tools for CMake 1.0
Visual Studio Tools for CMake
Visual Studio Tools for Containers 1.0
Visual Studio Tools for Containers
VisualStudio.DeviceLog 1.0
Information about my package
VisualStudio.Foo 1.0
Information about my package
VisualStudio.Mac 1.0
Mac Extension for Visual Studio
Xamarin 16.5.000.322 (d16-5@4d76f33)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin Designer 16.5.0.93 (remotes/origin/d16-5@2c7bbb76b)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.
Xamarin Templates 16.5.31 (91cfcf5)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.
Xamarin.Android SDK 10.2.0.16 (d16-5/48f0fe7)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: 062f0ab
Java.Interop: xamarin/java.interop/d16-5@47f47bc
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools/master@9f4ed4b
Xamarin.iOS and Xamarin.Mac SDK 13.14.0.6 (bde12ca)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
The text was updated successfully, but these errors were encountered: