wcf: System.PlatformNotSupportedException: Compiling JScript/CSharp scripts is not supported
Hi,
I am using a WSDL file (wsdl.zip) provided by Salesforce.com. When trying to logon to the service using the below code, it threw a System.PlatformNotSupportedException saying “Compiling JScript/CSharp scripts is not supported”
var salesforceClient = new SoapClient(); salesforceClient.loginAsync(null, username, password).Wait();
Here is the stack trace.
InnerException {System.PlatformNotSupportedException: Compiling JScript/CSharp scripts is not supported at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location) at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type) at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type) at System.ServiceModel.Description.XmlSerializerOperationBehavior.Reflector.SerializerGenerationContext.GenerateSerializers() at System.ServiceModel.Description.XmlSerializerOperationBehavior.Reflector.SerializerGenerationContext.GetSerializer(Int32 handle) at System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.AddHeadersToMessage(Message message, MessageDescription messageDescription, Object[] parameters, Boolean isRequest) at System.ServiceModel.Dispatcher.OperationFormatter.SerializeRequest(MessageVersion messageVersion, Object[] parameters) at System.ServiceModel.Dispatcher.ProxyOperationRuntime.BeforeRequest(ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.PrepareCall(ProxyOperationRuntime operation, Boolean oneway, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.Begin() at System.ServiceModel.Channels.ServiceChannel.BeginCall(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, TimeSpan timeout, AsyncCallback callback, Object asyncState) at System.ServiceModel.Channels.ServiceChannelProxy.TaskCreator.CreateGenericTask(ServiceChannel channel, ProxyOperationRuntime operation, Object[] inputParameters)} System.Exception {System.PlatformNotSupportedException}
Is this really something that is not supported by the tool yet?
Thanks, Son
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 19 (7 by maintainers)
Links to this issue
Commits related to this issue
- Workaround for https://github.com/dotnet/wcf/issues/2219 — committed to WHTaylor/LiveIngestTests by WHTaylor 3 years ago
I understood the root cause of the issue. One of the types generated by WCF Connected Service was wrong, see below.
The property is a 2-dimensional array, but the
XmlArrayItemAttribute
speicifed the item type astypeof(ListViewRecordColumn)
. To work around the issue, we can change the item type totypeof(ListViewRecordColumn[])
.The issue is a duplicate of https://github.com/dotnet/wcf/issues/1274. Resolved the issue as duplicate.
Hi Son, I tried the repro and could repro the issue on my machine. For now it seems to be a bug with the XmlSerializer generation using RefEmit. I need to investigate the issue further to understand the root cause.
XmlSerializer has a special mode in which the serializer would use reflection instead of RefEmit to do serialization. I wondered if the app would work in that mode. If you are willing to give it a try, you can enable the mode by using the code below at the app’s startup,
Note that, using reflection to enable the mode is subject to future changes.
@StephenMolloy, @HongGit, I think it might be worth revisiting this. This was closed in preference of another issue, and that issue was closed as there was a workaround. From what I remember/can tell, the problem is there are certain .NET class definitions which when generating an XmlSerializer using Ref.Emit would result in an exception being thrown and it would fail to generate. On .NET Framework, this triggered a fallback code path where it would use the legacy code generation XmlSerializer implementation which would work. One example where I’ve seen this happen is that when using code generation, the compiler can take advantage of implicit type conversion and implicit type conversion operators which Ref.Emit can’t (although that’s not solved by the reflection based serializer either, it would be a lot easier to implement there). I think we should consider an option to fall back to the reflection based serializer implementation in Core, but opt-in only as @Catchops mentioned, there can be cases where it does the wrong thing so this should be explicit.
@HongGit, I think there’s scope here for looking at what dotnet-svcutil produces from the WSDL as it seems like it might be interpreting it incorrectly. If modifying the generated classes makes something work, then we might have a bug that we can fix.
@Catchops, can you/did you open an issue about the reflection based serializer doing the wrong thing?
It is unfortunate that this issue is marked as closed (as well as https://github.com/dotnet/wcf/issues/1274 and https://github.com/dotnet/wcf/issues/2743 and https://github.com/dotnet/wcf/issues/2219 referred to as duplicate), as I encountered this problem today; but a Big Thank You to @shmao for the workaround, (above).
In my case, this Service Reference code that was generated from Vendor WSDL:
being called like this:
resulted in the
Compiling JScript/CSharp scripts is not supported
error on thatbool ok
line.As described above, adding these lines using
System.Reflection
appears to have fixed the error for me:*Edit: using Visual Studio 2019 Version 16.1.6 .NET Core 2.2 Console Application
I have a similar issue with .NET 7 and official Microsoft’s schemas for Dynamics - https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/customize-dev/form-xml-schema?view=op-9-1 I downloaded the schemas from here: https://download.microsoft.com/download/B/9/7/B97655A4-4E46-4E51-BA0A-C669106D563F/Schemas.zip Then I generated CS using XSD tool and when trying to create a XMLSerializer:
var serializer = new XmlSerializer(typeof(FormType));
I get this error:Stack trace:
I think that the problem is probably this:
but I’m not sure if I can replace
[][]
with a single[]
.Besides that are there any plans to fix this buggy behavior?
@HongGit I’m not sure I understand. Which other item is currently tracking this issue? I am currently having to manually modify the generated classes post-hoc. So I would really like to know which item to follow for an eventual solution to this issue.
For anyone who is reading this - the Reflection code does indeed work as a workaround. However, be very careful. I put this into our code which fixed the issue with the .cs files being generated from the svcutil utility. However, we had other code in our application where the Reflection changes caused harm to the XML serialization being done there. In our case, code to make payments. Therefore, make sure you do a thorough regression test on the application you are working in.
I searched the XSD file I had for
Type[][]
and fixed the correspondingXmlArrayItemAttribute
fromtypeof(Type)
totypeof(Type[])
and also got it working! Thanks so much @shmao