Realm-dotnet: Realm.Database 2.0.0-rc1 / "No RealmObjects. Has linker stripped them?...."

[sushihangover]

Goals

Upgrade app from Realm 1.6.0 to 2.0.0-rc1 and test a iOS/Android application that is using Xamarin.Forms that has the RealmObjects in a PCL library

Expected Results

No runtime errors

Actual Results

iOS and Android report:

No RealmObjects. Has linker stripped them? See https://realm.io/docs/xamarin/latest/#linker-stripped-schema

Steps to Reproduce

• Update Nuget package to from 1.6.0 to 2.0.0-rc1 in all projects
  
  
  
  • Delete app from device(s)
  
  
  • Clean / Rebuild / Deploy / Debug results in No RealmObjects. Has linker st....
  
  
  • Only change is the 1.6 to 2.0.0-tc1 package change
  
  
• RealmObjects are in a PCL library

Note: If the solution/project is not placing the RealmObjects in a PCL/NetStd library, but are included into the core application project, Realm is fine and all the RealmObjects are available.

<package id="Realm.Database" version="2.0.0-rc1" targetFramework="portable45-net45+win8+wpa81" />

• Xamarin.iOS Version: 11.2.0.8
• Xamarin.Android Version: 8.0.0.33

[adolgov]

I'm seeing a similar issue, but I'm running 1.6.0 and using PCL + Xamarin.Android. My solution worked correctly prior to the upgrade, even with RealmObjects declared in a PCL project.

I've just upgraded

Fody: 2.1.2 -> 2.1.3
Realm: 1.5.0 -> 1.6.0
Realm.Database: 1.5.0 -> 1.6.0
Realm.DataBinding: 1.1.0 -> 1.2.0

I checked the recommendations in the Failed to Weave of the documentation, and also tried the solution linked at stackoverflow, all with no luck.

[nirinchev]

Can you make sure the module initializer of your PCL project is run prior to using Realm? For example, create a dummy class with an empty method in your PCL and invoke it. If the error persists, we'll need a repro project/more info as things are working as expected with the setup I tried.

[adolgov]

No luck here.

I created a simple class with a single method, instantiated the class, and called the method prior to any Realm-related calls; however, the error is still the same.

As background, my project is structured is the following way:
-Xamarin.Droid Project/application
----Main PCL project/library
--------Core PCL lib – this is where RealmObjects are defined

Xamarin.Droid, PCL, with MvvmCross as the MVVM framework, if that makes a difference.

This solution/code is what I have been using successfully for a while, but after doing NuGet upgrades, as described above, I started getting this error.

The exception happens after I get a user and log into the Realm Object Server (via Google token), I use the user to create a SyncConfiguration. When I look at the Realm Object Server, I do see that the user is created; however, no realms are created. The exception happens here

using (var realm = Realm.GetInstance(config))

Stack Trace (in case it helps):

  at Realms.Schema.RealmSchema+Builder.Build () [0x00008] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Schema/RealmSchema.cs:158 
  at Realms.Schema.RealmSchema.CreateSchemaForClasses (System.Collections.Generic.IEnumerable`1[T] classes) [0x000b6] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Schema/RealmSchema.cs:121 
  at Realms.Schema.RealmSchema+<>c.<.cctor>b__15_0 () [0x00000] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Schema/RealmSchema.cs:42 
  at System.Lazy`1[T].CreateValue () [0x00081] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/Lazy.cs:443 
  at System.Lazy`1[T].LazyInitValue () [0x00080] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/Lazy.cs:388 
  at System.Lazy`1[T].get_Value () [0x0003a] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/Lazy.cs:339 
  at Realms.Schema.RealmSchema.get_Default () [0x00000] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Schema/RealmSchema.cs:68 
  at Realms.Realm.GetInstance (Realms.RealmConfigurationBase config, Realms.Schema.RealmSchema schema) [0x00028] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Realm.cs:139 
  at Realms.Realm.GetInstance (Realms.RealmConfigurationBase config) [0x00000] in /Users/tightdb/jenkins/workspace/realm_realm-dotnet_PR-1516-XXBWU7QHQ7BDRGFQ3SWG4LYYREWB3SW2HPOQJGKXIIGUKJLT7ULA@3/Realm/Realm/Realm.cs:98 
  at Think.Services.ThinkRealmAccountService+<>c__DisplayClass24_1+<<LoginAsync>b__0>d.MoveNext () [0x00252] in C:\Users\adolg\Documents\Projects\sl\Think\Think\Think\Services\ThinkRealmAccountService.cs:125 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:151 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00037] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:187 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:156 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:128 
  at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:447 
  at Polly.Policy+<>c__DisplayClass192_0+<<TimeoutAsync>b__1>d.MoveNext () [0x0003d] in C:\projects\polly\src\Polly.Shared\Timeout\TimeoutSyntaxAsync.cs:255 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:151 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00037] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:187 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:156 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:128 
  at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult].GetResult () [0x00000] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:535 
  at Polly.Timeout.TimeoutEngine+<ImplementationAsync>d__1`1[TResult].MoveNext () [0x000df] in C:\projects\polly\src\Polly.Shared\Timeout\TimeoutEngineAsync.cs:33 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:151 
  at Polly.Timeout.TimeoutEngine+<ImplementationAsync>d__1`1[TResult].MoveNext () [0x00355] in C:\projects\polly\src\Polly.Shared\Timeout\TimeoutEngineAsync.cs:61 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:151 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00037] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:187 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:156 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:128 
  at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:447 
  at Polly.Policy+<ExecuteAsync>d__100.MoveNext () [0x0007d] in C:\projects\polly\src\Polly.Shared\PolicyAsync.cs:271 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/exceptionservices/exceptionservicescommon.cs:151 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00037] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:187 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:156 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:128 
  at System.Runtime.CompilerServices.TaskAwaiter.GetResult () [0x00000] in /Users/builder/jenkins/workspace/xamarin-android/xamarin-android/external/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/TaskAwaiter.cs:113 
  at Think.Services.ThinkRealmAccountService+<LoginAsync>d__24.MoveNext () [0x000ff] in C:\Users\adolg\Documents\Projects\sl\Think\Think\Think\Services\ThinkRealmAccountService.cs:94 

[sushihangover]

Thanks, I'm aware of the assembly initialization order issue, I wrote an SO answer that addresses that:

• https://stackoverflow.com/questions/46049316/xamarin-realm-no-realmobject-has-linker-stripped-them/46052017#46052017

This is a failure to resolve the RealmObjects after the assembly containing the class definitions is loaded. Something changed from 1.6 to 2.0rc1 that is causes the failure as no other code changes were made. I perform all Realm-based code in the same Viper-based data module (which translates to the same assembly). Disassembly of that shows the classes are there and weaved. Also force loading the assembly and its dependancies (in reverse order) via a Assembly.Load works in 1.6 and fails in 2.0c1 with the same error.

[nirinchev]

That's very odd, as I don't remember touching anything that could result in such behavior.

@sushihangover does any of your projects in the json extensions repo exhibit this behavior? If so, I'll try to clone it and debug.

@adolgov do you think you can share a repro project? If you'd like to share it privately, you can email it to [email protected] and reference this issue.

[adolgov]

As mentioned in the thread @sushihangover posted, the problem resolved when I completely removed all Realm and Fody NuGet packages from my solution, cleaned the solution, and then re-added everything back in.

After initially removing the NuGet packages, I also went and manually removed the .dll file and FodyWeavers.xml files that removing the packages seemed to leave behind.

[nirinchev]

I tried the same approach with the Nuget tests project in @sushihangover's repo and things worked. So seems to me like some Nuget weirdness 🤔

[ddomengeaux]

This appears to be more of an issue with Fody. I'm running into the same issue with 1.6.0 and trying to upgrade to Fody 2.1.3 from 2.1.2. It appears that moving to .3 causes the weaving tasks not to run. The upgrade also seemed to break the propertychanged weaver I use in the rest of my projects.

[sushihangover]

Ok, I have some RealmObjects being weaved and some not in this crazy solution at a client site that has way to many projects in it and RealmObjects in _multiple_ projects.

I created a matrix of Xamarin.iOS, Xamarin.Android apps and libraries projects and NetStandard and PCL library projects and hybrid NetStandard projects (ones that were PCL-based but converted to NetStandard, thus the csproj is the old style but it uses a project.json. All those projects using Fody 2.1.2 and Realm 1.6 initially.

Delete obj/bin and package dirs between every test, perform a nuget restore, and run msbuild with /verbosity:diag from cmd-line (using NuGet Version: 4.3.0.4406)

• Realm 1.6/ Fody 2.1.2 / <RealmWeaver/> builds correctly in every project.

Update the Realm package to 2.0.0-rc1:

Realm 2.0.0-rc1/ Fody 2.1.2 / <RealmWeaver/> Fails to weave anything in PCL projects, the FodyTarget never shows up MSBuild for this project type. All other project types weave correctly.

Update to Fody 2.1.3:

Realm 2.0.0-rc1/ Fody 2.1.3 / <RealmWeaver/> Fails to weave anything in PCL and NetStandard projects, the FodyTarget never shows up MSBuild for this project type.

Delete and re-add Realm 2.0.0-rc1, keeping Fody 2.1.3:

Realm 2.0.0-rc1/ Fody 2.1.3 / builds correctly in every project.

Check out test solution (Realm 1.6/ Fody 2.1.2) on another box with the same nuget version, builds correctly in every project.

Check out test solution (Realm 1.6/ Fody 2.1.3) on another box with the same nuget version, builds correctly in every project.

Check out test solution (Realm 2.0.0-rc1/ Fody 2.1.2) on another box with the same nuget version, fails to weave PCL projects.

Check out test solution (Realm 2.0.0-rc1/ Fody 2.1.3) on another box with the same nuget version, fails to weave PCL projects but NetStandard weaves fine.

I am SOOOO confused.... there is some strange wackiness going on.

Re: https://github.com/Fody/Fody/issues/409

[jpeterson312]

I can not get it to work with Fody 2.1.3 (same error every time) -> No RealmObjects. Has linker stripped them?

I just down graded Fody to 2.1.2 (seems to be my only option)... I'm running Realm 2.0.0

[ddomengeaux]

Fody has dropped support for .NET 4.5. Converting my project to .netstandard solved the issue, but I ended up downgrading since now all the libraries in use are compatible with .netstandard as of yet.

[nirinchev]

I'm closing this as it seems to be an issue with Fody/NuGet and not directly related to Realm.