@redth reported on Slack that projects using Forms 2.4 and 2.5 and Realm are getting xamlc compilation errors that seem to go away when Realm is removed. His assumption is that it may have to do with different Cecil versions (0.9 for Fody and 0.10 for Forms) but other Fody weavers seem to be unaffected.
Here's a simple repro sample
XFXamlCRealmRepro.zip
You should see the xamlctask output similar to:
Writing the assembly... failed.
/Users/redth/.nuget/packages/xamarin.forms/2.5.0.77107/build/netstandard1.0/Xamarin.Forms.targets(103,3): error : Value cannot be null.
/Users/redth/.nuget/packages/xamarin.forms/2.5.0.77107/build/netstandard1.0/Xamarin.Forms.targets(103,3): error : Parameter name: instruction
at Mono.Cecil.Cil.InstructionOffset..ctor (Mono.Cecil.Cil.Instruction instruction) [0x00003] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeReader.ReadScope (Mono.Cecil.Cil.ScopeDebugInformation scope) [0x00015] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeReader.ReadDebugInfo () [0x0002a] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeReader.ReadMethodBody () [0x00091] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeReader.ReadMethodBody (Mono.Cecil.MethodDefinition method) [0x00014] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataReader.ReadMethodBody (Mono.Cecil.MethodDefinition method) [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MethodDefinition+<>c.<get_Body>b__41_0 (Mono.Cecil.MethodDefinition method, Mono.Cecil.MetadataReader reader) [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet] (TRet& variable, TItem item, System.Func`3[T1,T2,TResult] read) [0x00040] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MethodDefinition.get_Body () [0x0002c] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MethodDefinition.get_HasCustomDebugInformations () [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddCustomDebugInformations (Mono.Cecil.Cil.ICustomDebugInformationProvider provider) [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddMethodDebugInformation (Mono.Cecil.Cil.MethodDebugInformation method_info) [0x0003a] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.PortablePdbWriter.Write (Mono.Cecil.Cil.MethodDebugInformation info) [0x00006] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeWriter.WriteUnresolvedMethodBody (Mono.Cecil.MethodDefinition method) [0x00086] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.Cil.CodeWriter.WriteMethodBody (Mono.Cecil.MethodDefinition method) [0x00012] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddMethod (Mono.Cecil.MethodDefinition method) [0x00013] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddMethods (Mono.Cecil.TypeDefinition type) [0x00013] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddType (Mono.Cecil.TypeDefinition type) [0x000a2] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.AddTypes () [0x00018] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.BuildTypes () [0x00014] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.BuildModule () [0x0009f] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.MetadataBuilder.BuildMetadata () [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleWriter+<>c.<BuildMetadata>b__2_0 (Mono.Cecil.MetadataBuilder builder, Mono.Cecil.MetadataReader _) [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet] (TItem item, System.Func`3[T1,T2,TResult] read) [0x00029] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleWriter.BuildMetadata (Mono.Cecil.ModuleDefinition module, Mono.Cecil.MetadataBuilder metadata) [0x0000f] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleWriter.Write (Mono.Cecil.ModuleDefinition module, Mono.Disposable`1[T] stream, Mono.Cecil.WriterParameters parameters) [0x000fb] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleWriter.WriteModule (Mono.Cecil.ModuleDefinition module, Mono.Disposable`1[T] stream, Mono.Cecil.WriterParameters parameters) [0x00002] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleDefinition.Write (System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00019] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.ModuleDefinition.Write (Mono.Cecil.WriterParameters parameters) [0x0000e] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Mono.Cecil.AssemblyDefinition.Write (Mono.Cecil.WriterParameters parameters) [0x00000] in <2e24b151dd8041d8b7d36a855bb53c66>:0
at Xamarin.Forms.Build.Tasks.XamlCTask.Execute (System.Collections.Generic.IList`1[System.Exception]& thrownExceptions) [0x00a79] in <42afaaac5eed4ddf9c469950223de895>:0
Done executing task "XamlCTask" -- FAILED.
Finally, it looks to me like this might be due to differences in Cecil versions being used. PropertyChanged.Fody seems unaffected since they fork and directly bundle the code from Cecil that they need in their own assembly. I think what might be happening is, the 0.9.x version of Cecil that Realm.Database is shipping is probably loaded first when the Realm weaver executes, and then Xamarin.Forms, which ships 0.10.x of Cecil is perhaps still using the 0.9.x already loaded? I'm not sure, that's just a theory at this point.
In any case, removing Realm from the project (and the associated code for the model) makes things happy again.
Any updates here?
My workaround was disabling XamlC.
It would still be great if this issue would be resolved!
Any news on this? After updating VS4Mac, Mono etc. yesterday, I'm now getting this error when debugging, even with XamlC disabled.
It sounds to me like XamlC is now forcibly enabled, but I'm not sure why. Either way, I can't launch my app at all, and not sure why.
EDIT: Just to update, I'm definitely seeing "XamlC skipped" lines in the build log, but do note that I'm still getting the error _when debugging_, eg. after launching the app in a simulator or on a device, immediately on startup.
EDIT 2: Never mind, looks like my issue is _not_ happening on an older version of the project, which leads me to believe it's something I've recently changed. Still no idea what, though.
Any updates on this? As of now I've been skipping XamlC, but I'd prefer to keep it enabled. Hoping for this to be fixed in the next release along with support for Fody >= 3.0.0 so that we can avoid issues like these for production.
Up this issue again, seems like first reported issue was created before 16 Nov 2017 - from this time any changes to resolve this issue?
Can we use one of the "Nightly builds". to avoid this issue?
PropertyChanged.Fody seems unaffected since they fork and directly bundle the code from Cecil that they need in their own assembly.
Is it possible to use same approach for Realm as PropertyChanged.Fody use?
I using Realm from ~0.6 version and noticed Cecil issue already few times, probably it will close this issue for long time.
@alexlobanov I resolved this by downgrading PropertyChanged to 2.2.10 and Fody to 2.5.0, however I'm not sure if this fixes your project. This still needs to be fixed though, I'll try to take a closer look when I've got time for it, if there's no one from the Realm working on it.
@arnemolland Thanks a lot for suggestion.
Our current project using:
.Net Standard 2.0.1
Xamarin.Forms 2.5.1
Realm 3.0
Prism 7.0
PropertyChanged 2.2.10
And using PropertyChanged 2.2.10 - is not fixed issue, as seems like PropertyChanged.Fody using
since they fork and directly bundle the code from Cecil that they need in their own assembly.
But just my thinking that Xamarin.Forms >= 2.4 using 0.10 Cecil, but Realm still using 0.9 -> and this causing XAMLC issue.
What Xamarin.Forms version you use it your project?
@alexlobanov We're on the latest stable 3.0 update.
This has been addressed by moving to Fody 3.x. For anyone impatient, I've published the prerelease nugets here: https://github.com/realm/realm-dotnet/issues/1693#issuecomment-399225588.
Most helpful comment
Any updates on this? As of now I've been skipping XamlC, but I'd prefer to keep it enabled. Hoping for this to be fixed in the next release along with support for Fody >= 3.0.0 so that we can avoid issues like these for production.