Runtime: XslCompiledTransform BadImageFormatException - Bad Method Token

[leecow]

@ThuCommix commented on Wed Aug 16 2017

XslCompiledTransform BadImageFormatException

When using XslCompiledTransform.Transform the framework throws a BadImageFormatException - Bad Method Token. It works fine with the full framework.

General

I'm using the newest dot net core sdk available in combination with Visual Studio 2017.3 and Windows10.

Steps to reproduce:

1. Adjust the directories in the attached project to point to the xsl and xml which are also in the zip.

2. Debug to transform.Transform
   -> Exception

   at System.Xml.Xsl.CompiledQuery.Query.{urn:schemas-microsoft-com:xslt-debug}init(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
   at System.Xml.Xsl.CompiledQuery.Query.Execute(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime)
   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlSequenceWriter results)
   at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer)
   at System.Xml.Xsl.XslCompiledTransform.Transform(XmlReader input, XsltArgumentList arguments, Stream results)

Sample Project.zip

---

@leecow commented on Thu Aug 17 2017

Moving issue to corefx repo

[danmosemsft]

@krwq

[krwq]

Ok, I've had a successful local repro. Current status:

I've done some manual searches to see if I can find something obvious but was unlucky.

I've generated Qil (intermediate step to compiled xsl) through private reflection on both full framework and .NET Core (which unfortunately was missing code for debugging this but was able to port it quickly) and not seeing a difference on them which means that the bug is either in QIL->MSIL step or in the XSL Runtime.

I'll be investigating this further.

[ThuCommix]

Is BadImageFormat Not something with x86/x64 Problems?

[krwq]

@ThuCommix I believe this can be x86/x64 but could also be invalid IL instructions being generated or anything which is unexpected in the compiled code. Considering that your testcase seems to be unique and other XSL tests are passing I believe there is likely some kind of bug which got introduced when porting XSL. My steps here were first to make sure the source of compilation is as expected - if syntax tree is wrong the compiled code will be wrong too - seems like first stage of compilation (XSL stylesheet -> QIL which is an internal representation) is correct. The bug can be anywhere in XSL code but also could be Ref.Emit or some other piece - it is hard to tell - the bug is in the assembly generated on the fly by XSL compiler.

[krwq]

@ThuCommix for now you can use new XslCompiledTransform(false) to unblock yourself (disabled debug mode) - it seems like it doesn't repro when it's disabled

[krwq]

@ThuCommix I've sent a PR with a fix.

If this will be hit more frequently on 2.0 we may want to consider back porting this.

[ThuCommix]

@krwq Thank you very much for your efforts! I guess not many people use xsl even though it's a very powerfull tool.