TypeNotSerializable Arguments: Exception in WCF - wcf

We have an application in Silverlight ,WCF RIA and Entity Framework.
Ever since i added a property to a class in the back end which is of type List<string>
we are getting the error below sometimes, in Production Environment
[TypeNotSerializable] Arguments: System.Linq.Enumerable+<ExceptIterator>d__99`1[System.String] Debugging resource strings are unavailable.
I tried including a [KnownType(typeof(List<string>))], but still we are getting this error occasionally. Please let me know how to get rid of this error.
Thanks !

It would appear someone is using IEnumerable.Except and not calling .ToList which is causing the iterator to still be in the structure when it is being serialized.

Related

Unable to locate persister for the entity, no code has changed

I am suddenly getting the error: "Unable to locate persister for the entity named 'MyLib.Project'."
I did not make any code changes to this project since the last time I published it. The reason I went into the code to look at it is because a user reported that the web page that utilizes this library was giving an error. I have also checked the eager loading of the provider as per (NHibernate - Random occurrences of "Unable to locate persister") but I am already eagerly loading.
Furthermore, I even changed my data provider configuration to:
.Mappings(Function(x) x.FluentMappings.AddFromAssemblyOf(Of Project)())
I stepped through the code and actually saw it find the Project mapping and step through it. There are no exceptions thrown while building the provider, but yet the web app still fails when I try to fetch a Project from the DB.
Update
I have tested this same exact code with a desktop application and it works perfectly fine. It seems to me the problem must be with NHibernate and the Web Application. Does anyone have any ideas about this specifically?
The answer to this, of course, is that I made a mistake.
I had two session factories in use in the same program and I passed a session from the wrong factory to one of my functions. So the error is correct, because the session it was passed was unaware of the Project type. I found this out eventually by looking at the Connection property of the session I was querying through.
Hopefully this helps someone else who may have made the same mistake.

WCF Generated Proxy Crashes Monodroid and Monotouch

I've generated a proxy client for my WCF RIA service class via slsvcutil.exe as described in the Xamarin "Introduction to Web Services" document, however when I try to make a call to one of the async methods, my "completed" event handler never gets called -- after a couple of minutes, the app simply terminates from the Android emulator (it does the same thing in Monotouch as well).
After several days of troubleshooting, I finally found the source of the crash, but have no idea how to fix it. I suspect it's a bug in Mono somewhere, but don't know how to troubleshoot any further.
My generated proxy has a class defined like so:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name = "ChangeSetEntry", Namespace = "DomainServices")]
[System.Runtime.Serialization.KnownTypeAttribute(typeof(SL5Proxy.ChangeSetEntry[]))]
public partial class ChangeSetEntry : object
{
...
}
(The code above is greatly simplified - there are about a dozen KnownTypeAttribute() lines, but I've determined that the one shown above is the source of the problem. It's important to note that the ChangeSetEntry object does not have any reference to a ChangeSetEntry[] array.)
I found that if I simply comment out the
[System.Runtime.Serialization.KnownTypeAttribute(typeof(SL5Proxy.ChangeSetEntry[]))]
line from the proxy code, everything works 100% correct and my async "completed" handler is called exactly as expected. I don't know why slsvcutil.exe generates the problematic KnownTypeAttribute() line, but it does.
My guess is that there's some kind of infinite recursion that gets created when the ChangeSetEntry class tells the runtime serializer that ChangeSetEntry[] is a known type -- the runtime tries to resolve the known type, comes back to ChangeSetEntry and does it all again.
So I'm curious if anyone else has seen this issue, whether it's a known problem and whether there is a workaround -- perhaps some way to suppress the generation of the KnownTypeAttribute() lines from slsvcutil.exe

Internal fault in MS auto-generated method of WCF

I have a problem with WCF. My testing code is pretty simple.
I call a service layer method on my server from my silverlight application and print the result in a textbox.
Everything of this is surrounded by try-catch.
When my service layer method simply returns a constantly defined string there seems to be no problems - however as soon as it calls a more complex method it fails.
While debugging it does not even reach the complex model method; it fails before that inside some auto-generated code from microsoft:
/WuSIQ.jpg
As the error message "NotFound" is not exactly the most helpful or specific you can imagine my trouble googling for hints.
I thought maybe the auto-generated code could only send simple data so I made a temporary string and returned that, but this did not help.
I have already: a client access policy, a service reference added, removed duplicate reference in ServiceReferences.ClientConfig and a ServiceLayer.svc.cs.
I am debugging by running from the main window and my breakpoints are picked up.
Anyone?
I had some errors in the server side method that were quickly found after debugging was fixed.
I fixed this, as I said in comments, setting the project to have "Multiple Startup Projects".
Whenever I had troubles with updating the WCF service methods one of these usually solved it all:
1 Delete all bin and obj folders (specifically selecting re-build might do the same).
2 The servicelayer will not succesfully auto-update (but will work!) unless this:
[ServiceContract(Namespace = "")]
... is set to this:
[ServiceContract(Namespace = "YourServiceLayerName")]
3 Right clicking on the servicereference and selecting "update...".
Sometimes it would stop debugging again, but a forced full re-build would return it to normal.
I hope this helps someone.

Function evaluation timed out

I am using linq to sql in a Silverlight application and I keep getting this debug error..
http://www.freeimagehosting.net/uploads/bf4055b4ee.jpg
This code runs when the application is started up without problems. When I call it the second time, I only get a few of the results. When I add a breakpoint to the WCF service I get the following error...
Could someone please tell me whats going on here so i can make some changes?
TIA
ps. Might not be the most efficient coding but I will sort all that out later :P
If you add a breakpoint to the service code the caller will throw a Timeout Exception after the timeout time has passed. Raise the timeout of your service (on the server and client side), this will allow you to debug your service code without getting exceptions.

MSSOAP30 Object error: 0x80004002: Interface does not exist (VB)

I'm well and truly stuck with MS SOAP 3.0, which I'm currently running from VBA Excel in Office 2003. I have used MS SOAP Toolkit 3 to create a proxy class which I am using. If I don't use it, I don't get the error, but then I'd have to write out the entire proxy class by hand and it's massive.
When my program is first run, I get "Class not registered". If I run it again I get "Interface not supported". The error messge is:
run-time error: '-2147467262'
SoapMapper: The SoapMapper for element
callContextIn could not be created
HRESULT=0x80004002: No such interface
supported.
-WSDLOperation:Initialisation of a SoapMapper for operation getSNFormat
HRESULT=0x80004002: No such interfce
supported.
The error occurs when:
Set sc_PartService = New SoapClient30
Help would be greatly appreciated.
Thanks
Just now I deleted "Set", got an error of course, put it back and it ran properly. Once. Not again, and I've been unable to recreate this. Never encountered anything like that before!
HAve you checked if the COM object exists / is registered?