Search
Active

8
Sign in to vote
0
Sign in to vote
Sign in
 to vote
Type: Bug
ID: 433569
Opened: 4/19/2009 5:55:16 AM
Access Restriction: Public
0
Workaround(s)
4
User(s) can reproduce this bug
If a OperationContract is defined to return IList<T> where T is a type defined by a DataContract, and an array is returned, then WCF throws an ExecutionEngineException.

Looks similar to the following issue, but more general as it doesn't require the same conditions.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391260&wa=wsignin1.0

This is with the final vesion of .NET Framework 3.5 SP1, not the beta but there was no option to select this in the feedback form.

I am looking for advice on best practices to return collections from WCF web services. To date I usually return as IEnumerable<T> or IList<T> for flexibility, but this exposes me to the bug described here and in the above linked issue.
Details (expand)

Product Version

.NET Framework 3.5 SP1 (Beta)
Product Language
English

Operating System
Windows XP
Operating System Language
English

Architecture
x86

Priority
(1=blocking, 2=important, 3=nice to have)
 

Severity
(1=major functionality issue, 2=important functionality issue, 3=nice to have)
 

Steps to Reproduce
Using the attached VS2005 project:
1. Start the service WcfExecutionEngineException.Host (e.g. in Cassini)
2. Start the test client WcfExecutionEngineException.TestClient.
3. Click on the "Test Service" button without checking "Use Array"
4. A message box is displayed with data returned by the service, dismiss it.
5. Check the "Use array" checkbox and click on the "Test Service" button .
Actual Results
At Step 5 the Cassini server crashes with an ExecutionEngineException.
Expected Results
At Step 5 data should be returned from the service like at step 3.
Component Usage
(any information on your scenario that may help in investigating your issue)
 

How often does this happen?
Always Happens

Have you seen this problem in other versions?
I don't know if this issue existed previously
File Attachments
1 attachments
WcfExecutionEngineException.zip
Sign in to post a comment.
Posted by Microsoft on 4/20/2009 at 7:18 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Posted by Microsoft on 4/22/2009 at 12:02 AM
We were able to reproduce the issue you are seeing. We are escalating this issue to the product unit who works on that specific feature area. The product team will review this issue and make a decision on whether they will fix it or not for the next release.
Posted by Microsoft on 4/22/2009 at 2:05 PM
Hi Joe,

Yes, you've stumbled across the same bug that is the cause of the Connect bug you linked to. At present, the only known workaround is to GAC the assemblies that contain your custom DataContracts. Can you try that let me know if that fixes your issue?

Thanks,

-- Dave, WCF team
Posted by Microsoft on 4/22/2009 at 2:06 PM
And just to clarify, this will certainly be fixed in an upcoming release so that the workaround is not needed.

-- Dave
Posted by JocularJoe on 4/24/2009 at 11:35 AM
Unfortulately deploying to the GAC won't be possible in this environment. When you say this will be fixed in an upcoming release, do you mean a Service Pack for .NET 3.5 or will we need to wait for .NET 4?

Meanwhile, what recommendations would you make about returning collections from Operation Contracts or collection properties in DataContracts? Are there some guidelines we could follow that would avoid this issue?
Posted by Microsoft on 4/24/2009 at 12:31 PM
Regarding workarounds, if GAC'ing isn't possible, I believe you can set LoaderOptimization to SingleDomain and this will workaround the issue:
http://msdn.microsoft.com/en-us/library/system.loaderoptimization.aspx

Alternatively, have you tried using an array instead of IEnumerable?

With respect to the release vehicle, all I can say is that it will be fixed in the next public release. However, given that this is a bug on .NET 3.5 (& earlier) code, I can say that you won't be required to upgrade to .NET 4.0 in order to take get the fix.
Posted by JocularJoe on 4/24/2009 at 12:58 PM
Thanks for the response. LoaderOptimization sounds like a much better workaround, but it seems like it's an attribute that needs to be set on the main method of an executable. In my case the service is hosted in IIS. Is there any way to use LoaderOptimization in this scenario.

I am not currently using IEnumerable<T> - I've adopted a convention of using IList<T> for return values from OperationContracts and for properties of DataContracts that represent collections.

It would be easy to change Operation Contract return values to use an array - I just need to use ToArray if I'm usign a List<T> internally. So I'm wanting to know if this is the recommended workaround.

Using the same workaround for collection properties of a DataContract is more problematic, as it makes it difficult / impossible for the service tier to add items to the collection represented by the property.

It seems to me to be a fairly serious bug. And if we're going to need to wait for .NET 4.0 for a fix, I'd expect to see a KB article with guidelines to work around the problem - knowing that the GAC is not always possible (especially in a hosting environment).
Posted by Microsoft on 5/11/2009 at 12:24 PM
Thank you for your continued feedback here - you are making some very valid points, especially with regards to the difficulty this bug creates in hosted environments. I believe you've found one possible workaround already (converting to an array) and it seems that the other known workarounds previously discussed won't work for you. At this point, if the issue is still causing you significant business impact, please contact Microsoft Product Support and refer to this bug. I obvioulsy cannot commit to a hotfix decision here, but based on what I've seen so far, you would have a great case if you were to ask for a hotfix for this issue.
Posted by novokshanov on 8/14/2009 at 2:28 PM
I believe, the best workaround could be replacing IList<T> property types with List<T> types. This solution works without any problem. It also makes serializer to deserializes these collection to writable ones instead of read-only ones for IList<T> types.
Posted by James Ashley on 8/26/2009 at 9:09 AM
.ToList() in the implementation will fix this, as well as returning an array in the contract rather than an IList (same issue occurs when you try to return an array as IEnumerable<T>, ICollection<T> or IList<T>.

It seems to be fixed in .NET 4, however. I just ported some code that wouldn't work in VS 2008 into VS 2010 and there are no longer any issues.
© 2009 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement