ResolveAssemblies task wrongly uses reference assemblies #1162
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
vs-sync
For internal use only; creates a VSTS "mirror" issue.
Milestone
Comments
marek-safar
changed the title
dellis1972
added
the
Area: xamarin-android Build
jonpryor
added
Area: App+Library Build
|
Until this is resolved, has a workaround been identified? Having this issue with System.Memory and System.Runtime.CompilerServices.Unsafe |
|
The only thing I can think of is to add a reference to the missing assemblies to the main app. And make sure you reference the |
|
That does not work. I have tried all the workarounds, such as changing the linker, adding the packages.config, etc. URLs below. I am trying to use SignalR Core in a Cross Platform Xamarin / Xamarin Forms app using .NET Standard as the code sharing mechanism. Getting the same two skips with the reason that it is a reference Assembly.
https://github.com/aspnet/EntityFrameworkCore/issues/8922 |
|
Here's a functioning workaround. It's hacky and ugly but works with minimum fuss. Put this in an XML file and Update: Fixed an issue where if there were no ref assemblies in the list, the |
|
I found another workaround: In my case, the NuGet package "System.Runtime.CompilerServices.Unsafe" caused the issue. So I made a copy of the package (*.nupkg file), removed the "ref"-folder from it (which contains the reference assemblies), and installed that modified package into my project. Now that the package only contains the "real" assembly, there's no way for Mono to accidentally pick the wrong assembly. |
|
That is an interesting workaround :) it that might cause some issues though. We are still working through this issue here, hopefully we will find a good soluition. |
|
The problem with any of these workarounds, once I get it to build and deploy, the Xamarin Forms won't find and attach property changed notify for any fields. I spent a week trying to figure out why. The only thing I can think of is that there's an internal problem with these pre-release libraries. |
3 tasks
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 5, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `NewtonSoft.Json` since it provides a decent API for querying json. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` and `$(_NuGetTargetFallbackMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging/4.4.0`. My first throught was to use the version of the reference assembly we just loaded. But in this package even though the nuget version was `4.4.0` the assembly versioin was `4.0.2` .. so not helpful. So we need to just search for the items starting with `System.IO.Packaging`. Next is to look for the `runtime` item and then finally the value of that. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format.
|
@SvenEV your soulution work perfectly, I just open the .nupkg with WinRar and remove the ref folder, also from the package folder and the the application work fine |
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 6, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `NewtonSoft.Json` since it provides a decent API for querying json. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` and `$(_NuGetTargetFallbackMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging/4.4.0`. My first throught was to use the version of the reference assembly we just loaded. But in this package even though the nuget version was `4.4.0` the assembly versioin was `4.0.2` .. so not helpful. So we need to just search for the items starting with `System.IO.Packaging`. Next is to look for the `runtime` item and then finally the value of that. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format.
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Mar 9, 2018
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 9, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `NewtonSoft.Json` since it provides a decent API for querying json. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` and `$(_NuGetTargetFallbackMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging/4.4.0`. My first throught was to use the version of the reference assembly we just loaded. But in this package even though the nuget version was `4.4.0` the assembly versioin was `4.0.2` .. so not helpful. So we need to just search for the items starting with `System.IO.Packaging`. Next is to look for the `runtime` item and then finally the value of that. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 9, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `Nuget.ProjectModel` since it an API for querying the `project.assets.json`. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging`. We need to look at the `lockFile.Libraries` to get information about the install path in the Nuget folder, and then `target.Libraries` to pick out the `runtime` item. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format. Hopefully we can just update the `Nuget` nuggets if that happens.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 13, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `Nuget.ProjectModel` since it an API for querying the `project.assets.json`. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging`. We need to look at the `lockFile.Libraries` to get information about the install path in the Nuget folder, and then `target.Libraries` to pick out the `runtime` item. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format. Hopefully we can just update the `Nuget` nuggets if that happens.
|
@SvenEV and @danielmeza this unfortunately did not work in my case. I removed the system.runtime.compilerservices.unsafe v.4.4.0 from the android (forms) project using the nuget manager. I then added via the PM command line the modified system.runtime.compilerservices.unsafe.4.4.0.nupkg without the ref folder. I still get the 'Could not load assembly 'system.runtime.compilerservices.unsafe' during startup registration' error. @danielmeza you mentioned removing something from the packages folder but I am not sure what to remove. The Packages folder has a few folders with one file and the structure looks like package>services>metadata>core-properties>e1a986c2358d484f8041396b6b6d35c7.psmdcp Did you remove this as well? I tried removing the .psmdcp file and got the same results. I also tried installing the system.runtime.compilerservices.unsafe 4.5.0-preview1-26216-02 from nuget and got the same results. |
|
@brian8227 Are you 100% sure that your modified package got installed and not the original/official one from NuGet? In my case, the modified package was correctly installed on my machine, but on another machine VS somehow preferred the original package from NuGet and the error appeared again. Since I don't know about the precedence of NuGet package sources, I solved the issue by simply assigning a different version number to the modified package, e.g. "4.4.0-patched". |
|
@SvenEV Thanks I really thought that was the case once you mentioned it as well. Originally I did a PM> install-package c:\users\brian\desktop\system.runtime.compilerservices.unsafe.4.4.0.nupkg I am not saying VS2017 couldn't have done something else in the background but that was the command I used after uninstalling the original it is very likely it grabbed another package. I just tried modifying the file as you suggested I verified in the csproj file this: I still get the error Perhaps I didn't modify the file correctly? I just removed the Ref folder edited the metadata version number and then saved it with the matching version name. I used Nuget Package Explorer by Luan Nguyen which seems to do what I needed. |
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Mar 14, 2018
* Removed no longer needed Audit files - will be replaced by single Realm file * Added Realm file * Replaced services to get data from Realm database * Updated NuGet packages * Display speaker basic info * Added fix for netstandard/android. See dotnet/android#1162 (comment) * Display meetups, backend fixes * Fix build in App Center * Display speaker details * Simplified getting talks for speaker by leveraging Realm backlink property * Replaced all manual queries with backlinking * Added friend logos * Now app displays all Audit information based on Realm database * Replaced all entity service with realm service using automapper * Attempt to fix App Center build * Cleaning up, bugfixes * Updated .gitignore * Added missing Realm file, part I * Removed obsolete directories * Attempt to fix Android build in App Center * Attempt to fix App Center build #3 * Attempt to fix iOS build * Cleaning up, increased app version to 1.1.0 * Attempt to fix iOS build #2 * Attempt to fix iOS build #3 * Rolled back to Android SDK 8.0 due to App Center issues * Cleaning up - added TwitterService & LanguageService * Android: rolled back Target Framework to Android 8.0 to fix App Center build * Fixed images on speakers page * Fixed displaying speaker avatars on Meetup page * Fixed displaying Friends logos * Removed small speaker avatar
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 15, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `Nuget.ProjectModel` since it an API for querying the `project.assets.json`. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging`. We need to look at the `lockFile.Libraries` to get information about the install path in the Nuget folder, and then `target.Libraries` to pick out the `runtime` item. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format. Hopefully we can just update the `Nuget` nuggets if that happens.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 20, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `Nuget.ProjectModel` since it an API for querying the `project.assets.json`. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging`. We need to look at the `lockFile.Libraries` to get information about the install path in the Nuget folder, and then `target.Libraries` to pick out the `runtime` item. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format. Hopefully we can just update the `Nuget` nuggets if that happens.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Mar 21, 2018
Fixes dotnet#1154, dotnet#1162 Netstandard packages sometimes ship with both reference and implementation assemblies. The Nuget build task `ResolveNuGetPackageAssets` only resolves the `ref` version of the assemblies. There does not seem to be away way to FORCE Nuget to resolve the lib one. How .net Core manages to do this is still a mistery. That said the Nuget `ResolveNuGetPackageAssets` does give us a hint as to how to use the `project.assets.json` file to figure out what `lib` version of the package we should be including. This commit reworks `ResolveAssemblies` to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly. We need to be using `Nuget.ProjectModel` since it an API for querying the `project.assets.json`. We make use of the Nuget build properties `$(ProjectLockFile)` for the location of the `project.assets.json` , `$(NuGetPackageRoot)` for the root folder of the Nuget packages and `$(NuGetTargetMoniker)` for resolving which `TargetFrameworks` we are looking for. All of these properties should be set by Nuget. If they are not we should fallback to the default behaviour and just issue the warning. { "version": 3, "targets": { "MonoAndroid,Version=v8.1": { "System.IO.Packaging/4.4.0": { "type": "package", "compile": { "ref/netstandard1.3/System.IO.Packaging.dll": {} }, "runtime": { "lib/netstandard1.3/System.IO.Packaging.dll": {} } }, } } } The code above is a cut down sample of the `project.assets.json`. So our code will first resolve the `targets`. We use `$(NuGetTargetMoniker)` to do this. For an android project this should have a value of `MonoAndroid,Version=v8.1`. Note we do NOT need to worry about the version here. When Nuget restores the packages it creates the file so it will use the correct version. Next we try to find the `System.IO.Packaging`. We need to look at the `lockFile.Libraries` to get information about the install path in the Nuget folder, and then `target.Libraries` to pick out the `runtime` item. Once we have resolved the path we need to then combine that with the `$(NuGetPackageRoot)` to get the full path to the new library. If at any point during all of this code we don't get what we expect (i.e a null) we should abort and just issue the warning. The only real concern with this is if the format of the `project.assets.json` file changes. It is not ment to be edited by a human so there is the possibiltity that the Nuget team will decide to either change the schema or even migrate to a new file format. Hopefully we can just update the `Nuget` nuggets if that happens.
jonpryor
pushed a commit
that referenced
this issue
Mar 21, 2018
…s. (#1356) Fixes: #1154 Fixes: #1162 NetStandard packages sometimes ship with both reference and implementation assemblies. The NuGet build task `<ResolveNuGetPackageAssets/>` only resolves the `ref` version of the assemblies. There does not seem to be away way to *force* NuGet to resolve the lib one. This commit reworks the `<ResolveAssemblies/>` task to attempt to map the `ref` to a `lib` if we find a Referenece Assembly. Historically we just issue a warning (which will probably be ignored), but now we will use the `project.assets.json` file to find the implementation version of the `ref` assembly, by using the `NuGet.ProjectModel` package to find the library which is associated with a reference assembly. We thus "ignore" reference assemblies, using the "referenced"/"real" assemblies instead, to ensure that our existing build process continues to generate usable packages. *Note*: An alternative approach would be to "embrace" reference assemblies, allowing them to be used in the build. This doesn't currently work with our build system, as we assume assemblies will contain native libraries, Android resources, and other artifacts which must be extracted at build time, and reference assemblies will not contain these artifacts. We would like to explore the "embrace" strategy, but this will require far more effort to support.
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Apr 1, 2018
* Full screen image of the speaker is shown by tap on the speaker page … (#119) Full screen image of the speaker is shown by tap on the speaker page * Add information about target branch (#128) * Update README.md * Add information about gitflow * Net Standard (#130) * Removed obsolete & now deprecated Components * Updating to .NET Standard part I * Updating to .NET standard part II * Updating to .NET Standard part III * Update to .NET standard part 4 * Removed obsolete BCL packages * Temporarily disabling tweets; project now compiles successfully * Fixed getting tweets, now app is fully functional * Removed Obsolete packages, minor improvements * iOS improvements * Removed obsolete UWP solution * Added UWP project * iOS fixes * UWP: removed obsolete files * UWP: more fixes * UWP: now project compiles successfully * UWP: added splash screen * Updated several NuGet packages * Updated ALL packages; UWP fixes * Added comment about CircleTransformation & linker issue * displays twitter account full name in news page, closes #121 (#133) * Meetups list (#135) * meetups list on friends page, closes #58 * Speakers grouping and fast navigation by speakers list (index list - … (#136) * Speakers grouping and fast navigation by speakers list (index list - iOS, fast scroll - Android) were added. * Post-review commit: style changes + ordering by FirstName * Post-review commit: indentation was fixed * Improving app size & startup time (#134) * Removed unneeded icons * Removed obsolete Android 4.4 styles * Removed obsolete files, enabled ProGuard * Futher Android optimizations: getting rid of unused packages & permissions * AppSize: removing obsolete code * Android: removed unneeded Support Library * iOS size improvements * iOS: increased app version * Android: enabled AOT & LLVM to improve start up time * iOS fixed info.plist * iOS: added ARMv7s to support iPhone 5C * Android: enabled native HttpHandler & TLS to improve performance & appsize. Enabled experimental GC * Android: drop x86 support to reduce app size * iOS: fixed issue with iPhone 5, 5c support * iOS: changed ARMv7s to ARMv7 as Apple doesn't support ARMv7s anymore * iOS: project configuration fixes * Create CODE_OF_CONDUCT.md (#138) * Performance improvements (#140) * Enabled XAML compilation for all XAML files * Updated Resharper settings * Android: optimized PNG images * Android: removed unneeded references * Got rid of Newtonsoft.Json reference * Updated DotNetRu.BottomTabbedPage package - now all packages support .NET Standard 2.0 * Release1.0.1 (#143) * Fixed zooming of speaker photo Updated technology used page * Added original version of BottomTabbedPage package * Removed App Analytics from Debug builds * LivePlayer fixes & Language improvements * Added Kazan * Updated Audit * Changed upcoming meetups color * Fixed layout on Friends page * Create CONTRIBUTING.md (#139) * Create CONTRIBUTING.md * Update CONTRIBUTING.md * Fixed twitter feed (#146) * Realm backend (#148) * Removed no longer needed Audit files - will be replaced by single Realm file * Added Realm file * Replaced services to get data from Realm database * Updated NuGet packages * Display speaker basic info * Added fix for netstandard/android. See dotnet/android#1162 (comment) * Display meetups, backend fixes * Fix build in App Center * Display speaker details * Simplified getting talks for speaker by leveraging Realm backlink property * Replaced all manual queries with backlinking * Added friend logos * Now app displays all Audit information based on Realm database * Replaced all entity service with realm service using automapper * Attempt to fix App Center build * Cleaning up, bugfixes * Updated .gitignore * Added missing Realm file, part I * Removed obsolete directories * Attempt to fix Android build in App Center * Attempt to fix App Center build #3 * Attempt to fix iOS build * Cleaning up, increased app version to 1.1.0 * Attempt to fix iOS build #2 * Attempt to fix iOS build #3 * Rolled back to Android SDK 8.0 due to App Center issues * Cleaning up - added TwitterService & LanguageService * Android: rolled back Target Framework to Android 8.0 to fix App Center build * Fixed images on speakers page * Fixed displaying speaker avatars on Meetup page * Fixed displaying Friends logos * Removed small speaker avatar * Fixed displaying of speaker avatar * Fixed credits on about app page * Fix issue with duplicate AutoMapper initialization
|
Any ETA for a fixed version of Xamarin.Android with these ? |
|
To whomever used my workaround, there's a bug in it that breaks your build if there are no referenced .net standard libraries that use ref assemblies. The code is fixed now so it works even on a fresh project. Updated the comment: #1162 (comment) |
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Jun 12, 2018
* Full screen image of the speaker is shown by tap on the speaker page … (#119) Full screen image of the speaker is shown by tap on the speaker page * Add information about target branch (#128) * Update README.md * Add information about gitflow * Net Standard (#130) * Removed obsolete & now deprecated Components * Updating to .NET Standard part I * Updating to .NET standard part II * Updating to .NET Standard part III * Update to .NET standard part 4 * Removed obsolete BCL packages * Temporarily disabling tweets; project now compiles successfully * Fixed getting tweets, now app is fully functional * Removed Obsolete packages, minor improvements * iOS improvements * Removed obsolete UWP solution * Added UWP project * iOS fixes * UWP: removed obsolete files * UWP: more fixes * UWP: now project compiles successfully * UWP: added splash screen * Updated several NuGet packages * Updated ALL packages; UWP fixes * Added comment about CircleTransformation & linker issue * displays twitter account full name in news page, closes #121 (#133) * Meetups list (#135) * meetups list on friends page, closes #58 * Speakers grouping and fast navigation by speakers list (index list - … (#136) * Speakers grouping and fast navigation by speakers list (index list - iOS, fast scroll - Android) were added. * Post-review commit: style changes + ordering by FirstName * Post-review commit: indentation was fixed * Improving app size & startup time (#134) * Removed unneeded icons * Removed obsolete Android 4.4 styles * Removed obsolete files, enabled ProGuard * Futher Android optimizations: getting rid of unused packages & permissions * AppSize: removing obsolete code * Android: removed unneeded Support Library * iOS size improvements * iOS: increased app version * Android: enabled AOT & LLVM to improve start up time * iOS fixed info.plist * iOS: added ARMv7s to support iPhone 5C * Android: enabled native HttpHandler & TLS to improve performance & appsize. Enabled experimental GC * Android: drop x86 support to reduce app size * iOS: fixed issue with iPhone 5, 5c support * iOS: changed ARMv7s to ARMv7 as Apple doesn't support ARMv7s anymore * iOS: project configuration fixes * Create CODE_OF_CONDUCT.md (#138) * Performance improvements (#140) * Enabled XAML compilation for all XAML files * Updated Resharper settings * Android: optimized PNG images * Android: removed unneeded references * Got rid of Newtonsoft.Json reference * Updated DotNetRu.BottomTabbedPage package - now all packages support .NET Standard 2.0 * Release1.0.1 (#143) * Fixed zooming of speaker photo Updated technology used page * Added original version of BottomTabbedPage package * Removed App Analytics from Debug builds * LivePlayer fixes & Language improvements * Added Kazan * Updated Audit * Changed upcoming meetups color * Fixed layout on Friends page * Create CONTRIBUTING.md (#139) * Create CONTRIBUTING.md * Update CONTRIBUTING.md * Fixed twitter feed (#146) * Realm backend (#148) * Removed no longer needed Audit files - will be replaced by single Realm file * Added Realm file * Replaced services to get data from Realm database * Updated NuGet packages * Display speaker basic info * Added fix for netstandard/android. See dotnet/android#1162 (comment) * Display meetups, backend fixes * Fix build in App Center * Display speaker details * Simplified getting talks for speaker by leveraging Realm backlink property * Replaced all manual queries with backlinking * Added friend logos * Now app displays all Audit information based on Realm database * Replaced all entity service with realm service using automapper * Attempt to fix App Center build * Cleaning up, bugfixes * Updated .gitignore * Added missing Realm file, part I * Removed obsolete directories * Attempt to fix Android build in App Center * Attempt to fix App Center build #3 * Attempt to fix iOS build * Cleaning up, increased app version to 1.1.0 * Attempt to fix iOS build #2 * Attempt to fix iOS build #3 * Rolled back to Android SDK 8.0 due to App Center issues * Cleaning up - added TwitterService & LanguageService * Android: rolled back Target Framework to Android 8.0 to fix App Center build * Fixed images on speakers page * Fixed displaying speaker avatars on Meetup page * Fixed displaying Friends logos * Removed small speaker avatar * Release 1.1.0 (#156) * Fixed displaying of speaker avatar * Fixed credits on about app page * Fix issue with duplicate AutoMapper initialization * Push notifications for Android (#165) * add xml parsing * add converting from xml model to realm * Implemented app autoupdate (without images) * Fixed issue with Rate limiting Added loading images for new speakers/friends * Improved updating speaker photos * Slightly improved updating Realm - now it's done in one transaction * Improved speed of Audit update - now 3x times faster * Set up push notifications for Android. Now app is capable of autoupdating itself on push * Set up Push Notifications for iOS * Push Notifications improvemtns: enhanced logging, background update (not working yet) * Fixed error with background update, enhanced logging for Android (logcat). Now app successfully updates Audit on background (but there's still an issue with silent pushes) * Added updating current audit version after successful update (using new table w/ commit hash) * Added Firebase SDK * Improved logging for troubleshooting Firebase issues * Push Notifications improvements - [Android] Added displaying local notification after successful update - Added Realm overwrite after each app update (actual for release builds) - Fixed build & run issues due to outdated Firebase package * Fixed AppCenter build issue * Fixed incorrect AppCenter.Crashes reference * Updated ALL nuget packages * [Android] Added support for Notification channels * [Android] Added Firebase specific notification handler * [Android] Rolled back to Android 8.0 due to App Center issues * - Fixed issues with threading & Realm due to lack of synchronization context - Improved AutoMapper configuration to avoid issues with multiple updates - Now pushes on Android work just fine independing of app state (background or foreground) * [Android] Removed App Center Push as Firebase is used now * iOS: increased version to 1.2.0 * [Android] Fixed App Center issue with targetSDK not being set * [iOS] Attempt to fix issue with notification handling - Missing type DateTimeOffsetConverter * [Android] Fixed issue with notification on Android < 8.0 [iOS] Added initial Firebase SDK * [Android] moved notification related logic to one place * Changing Settings page to TableView * [iOS] Removed Firebase package. APNS will be used instead * Updating Settings page * [Android] Fixed build in version of Visual Studio (15.7.1) * Replacing ListView in Settings page with custom viewcells * Replaced listview with custom cells in Settings page * Fixed translation for communities items * Added background color for text cells * Removed XfGloss due to bugs * Fixed opening Friends Added WhitetextCell control * Renamed Android channelID to new meetup * Android. Improved Settings page * [Android] Add notification icon, changed text, add auto-cancel * Updated Audt * Added missing localization * Removed hack realted to .NET standard as new version of Xamarin handles .NET Standard properly * Added pre-build script to change App Center key * Moved pre-build script to Android project * Attempt to fix pre-build file path issue * Attempt to fix issues with pre-build script * Dummy build to test App Center * Changed enconing to UTF-8 * pre-build script: added part to replace App Center configs * pre-build script: removed unneeded option * Attempt to fix pre-build script in AppCenter * Attempt to fix pre-build script * Changed pre-build script to only master branch & production config
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Jul 20, 2018
* Removed no longer needed Audit files - will be replaced by single Realm file * Added Realm file * Replaced services to get data from Realm database * Updated NuGet packages * Display speaker basic info * Added fix for netstandard/android. See dotnet/android#1162 (comment) * Display meetups, backend fixes * Fix build in App Center * Display speaker details * Simplified getting talks for speaker by leveraging Realm backlink property * Replaced all manual queries with backlinking * Added friend logos * Now app displays all Audit information based on Realm database * Replaced all entity service with realm service using automapper * Attempt to fix App Center build * Cleaning up, bugfixes * Updated .gitignore * Added missing Realm file, part I * Removed obsolete directories * Attempt to fix Android build in App Center * Attempt to fix App Center build #3 * Attempt to fix iOS build * Cleaning up, increased app version to 1.1.0 * Attempt to fix iOS build #2 * Attempt to fix iOS build #3 * Rolled back to Android SDK 8.0 due to App Center issues * Cleaning up - added TwitterService & LanguageService * Android: rolled back Target Framework to Android 8.0 to fix App Center build * Fixed images on speakers page * Fixed displaying speaker avatars on Meetup page * Fixed displaying Friends logos * Removed small speaker avatar
|
@maddentist I had to switch to packages.config for the Android App and this fixed my issue |
|
I had this fix on my project for awhile now and completely forgot about it since. I loaded up my project on an updated version of VS and it wouldn't build. Took me awhile and a lot of sniffing around to figure out that this fix was the cause of my build issues. After removing it, my app now builds again. |
pfedotovsky
added a commit
to DotNetRu/App
that referenced
this issue
Oct 31, 2018
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.
Steps to Reproduce
If you instead the build log you will see that
has few
...ref/netstandard2.0/...references which is wrong as they should never be used as an input to linker or any post compilation processingThis issue is possibly related to #1154
Expected Behavior
No error during execution.
Actual Behavior
[Mono] Assembly Loader probing location: 'System.Memory'.
[monodroid-assembly] Could not load assembly 'System.Memory' during startup registration.
Version Information
Xamarin.Android
Version: 8.1.0.25 (Visual Studio Community)
Android SDK: /Users/marek/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
6.0 (API level 23)
7.1 (API level 25)
SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.5
SDK Build Tools Version: 25.0.3
Log File
The text was updated successfully, but these errors were encountered: