Catch-22: WCF (Service Reference) / .NET 2.0 (Web Reference) on 64bit Platform

May 6, 2009 at 8:54 PM
Hi Michael,

We're well into our implementation of LINQ to CRM, and have run into a bit of a catch-22 situation. 

First - the background:
  • Dynamics CRM 4.0
  • CRM SDK 4.0.8
  • An ASP.NET 2.0 / .NET 3.5 web application is running in IIS 7 on Windows Server 2008 x64 as the web service client
  • We are using the latest SVN revision of LINQ to CRM
Now - the issue:
  • On the one hand, we've been able to add a WCF / service reference (as opposed to a .NET 2.0 / web reference), however we have been unable to get it to actually work against the CRM SDK web services. We get horrible exceptions that led me to a forum post indicating this is a bug (???) with CRM 4.0 (i.e. WCF clients will not work). I really hope this is incorrect. Please correct me if so.
  • If we use a web reference (i.e. not a WCF client), then we seem to have manifested an issue with WSE 3.0 - just creating an instance of the service (LINQ to CRM is not even involved at this point) gives us the following exception: 
    Unable to generate a temporary class (result=1).
    error CS0001: Internal compiler error (0xc00000fd)
    error CS0003: Out of memory
    System.Exception {System.InvalidOperationException}
We can actually prevent this second exception (using a web reference) from occurring by changing the advanced settings of the IIS application pool to enable 32-bit applications, and thus forcing the application pool to run as a 32-bit process. Clearly a Microsoft bug in play here. 

So - my favored method of resolving this is to figure out a way to
  • Create a WCF client that will actually work with the CRM SDK web services
  • Make LINQ to CRM work with this WCF client (I think I made decent progress with this until I realized the former was preventing me from doing anything meaningful)
Does anyone have successful stories to share on these last two points and perhaps wants to jot them down on paper?

May 7, 2009 at 9:15 AM
Hm, sounds hairy.

In the early days, LinqtoCRM actually used WCF. I wrote a blog-post on how to get that working, although that was probably CRM 3.0:

I'll drop steffana a line, maybe he has resolved this already.

Jun 11, 2009 at 4:02 PM


MS CRM 4.0 does not support a WCF proxy client connecting to it.

It did work in 3.0 but due to some issue in the WSDL its broken in 4.0 and I believe they are looking into it for 5.0


Jul 12, 2009 at 7:33 PM

We have been receiving the error you describe above (error CS0001: Internal compiler error (0xc00000fd) etc).

It's being thrown by the constructor when we do 

CrmService service = new CrmService();

However there's no IIS involved at this point - we haven't made a connection to a web service. We're just running the constructor.

I've found that reducing the size of the WSDL (or the Refrerene.cs class file that generated from it) does make the problem go away.

THe problem only happens on a 64 bit OS (Vista or Windows Server 2008). On 32 bit OS it works fine.

Is anyone able to shed any light on this? Could there be a problem in the 64bit .Net framework?

Jul 22, 2009 at 3:34 PM

We had same issue running CrmService instance in 64bit .net framework. And team provided alternate solution(2.0 complier issue). This issue would be fixed in .net 4.0 complier.

This issue only happans after exceeding certain no of custom entities in CRM.

Alternate solution is to Generate proxy class for CRM SDK wsdl, use console app and catch class file generated at runtime me63slj_.0.cs(%temp%).

Add this .cs file to solution you are adding Crm Sdk Reference. Make sure you use same namespace.

Add Crm Sdk webservice reference. Also add [System.Xml.Serialization.XmlSerializerAssembly] to SDK Reference.cs

Hope this helps.

Jul 22, 2009 at 6:45 PM

Thanks for chiming in bhaskermr!

Jul 22, 2009 at 9:30 PM

I'm pasting below the solution provided by Microsoft to this problem:


Unhandled Exception: System.InvalidOperationException: Unable to generate a temporary class (result=1) occurs when you create an instance of the CrmService in custom code on a 64 bit Microsoft Dynamics CRM 4.0 server


You receive the following error when you instantiate the CrmService web service in custom code on a 64-bit server:

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0001: Internal compiler
error (0xc00000fd) error CS0003: Out of memory


Stack Trace :
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies) at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type)
at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type)
at System.Web.Services.Protocols.SoapClientType..ctor(Type type)
at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()
at PluginRegistrationTool.CrmSdk.CrmService..ctor() in C:\Documents and Settings\jcp\Desktop\CRM4\crmsdk 4.0\tools\pluginregistration\Web References \CrmSdk\Reference.cs:line 58



This is caused by a C# compiler bug. The generation of dynamic serialization assemblies fails with a 64-bit server.


Use XML Serializer Generator Tool (Sgen.exe) to create an XML serialization assembly for the .dll file which contains the code to create an instance of the CrmService..


Create the XMLSerializers for your custom .dll.


Click Start , click Microsoft Visual Studio 200x , click Visual Studio Tools , and then click Visual Studio 200x command prompt .


Type Sgen /p “C:\program files\microsoft dynamics crm\crmweb\isv\bin\ <dll name> in the command prompt. NOTE : <dll name> is a place holder for the actual name of your dll.


Verify that <dll name> .XmlSerializers.dll is created in the same directory as your dll.
For example, verify that WebLib.XmlSerializers and WebLib.dll are located in C:\Program Files\Microsoft Dynamics CRM\CrmWeb\ISV\Bin.


Create the XMLSerializers for the App_WebReferences.dll.


Click Start , click Microsoft Visual Studio 200x , click Visual Studio Tools , and then click Visual Studio 200x command prompt


Type Sgen /p “C:\program files\microsoft dynamics crm\crmweb\isv\bin\App_WebReferences.dll” in the command prompt.


Verify that App_WebReferences.XmlSerializers.dll is created in the same directory as theApp_WebReferences.dll.
For example, verify that App_WebReferences.XmlSerializers.dll and App_WebReferences.dll are located in C:\Program Files\Microsoft Dynamics CRM\CrmWeb\ISV\Bin.

NOTE The build version of App_WebReferences.dll and App_WebReferences.XmlSerializers.dll / WebLib.dll and WebLib.XmlSerializers.dll should be the same. When two files have the same build version, place the files in the same folder.


XML Serializer Generator Tool (Sgen.exe)

Jul 23, 2009 at 6:21 PM


Thanks so much for posting that Microsoft support response. We have resolved our issues with Web References.

I'm not sure where I had read it, but I'd already tried generating a serialization assembly using sgen previously, but we'd failed in getting sgen to work against our DLL.

  • We had previously gone into our assembly project's properties, gone to the "Build" page, and turned "Generate serialization assembly" to "On" (it is usually set to "Auto" by default". This forces sgen to run against our output. 
  • Unfortunately, this results in sgen failing with a horrible error - for us at least.
  • The key to resolve this issue was passing the /p flag to sgen.
  • We implemented this by setting the "Generate serialization assembly" back to "Auto" and creating a post build event with the following text: $(FrameworkSDKDir)bin\sgen.exe" /p "$(TargetDir)OurDllNameHere.dll" /force

At some point I will also try compiling and running our stuff using .NET 4.0 beta stuff to see if that also helps. I think in any case, generating the serialization assembly is a good strategy (for speed), and so this seems to be an optimal resolution to our issue.

Thanks to everyone who contributed to this thread, and let me know if you'd like me to post more details.