I'm using CSLA 2.0 and data portal exceptions are locking up visual studio. Seems to get stuck in the DataPortalException class and happens on any data portal errors like an invalid column name.
Any ideas? Is this possible a known issues fixed in a later release?
Thanks
Hi,
Don't think that I can help much, but I think I have the same issue. Sometimes, but not always, throwing a new DataPortalException hangs VS. To be more precise, it happens at DataPortal.cs line 191.
I think this is an issue with VS and not CSLA, but heck if I know. Not sure if you're using C# or VB.NET, but if you send the error report, Microsoft will tell you it's because of the VB compiler. Strange, because I use C#.
Since it takes so long for the error reporting dialog to come up, I've just placed a breakpoint on that line.
I did ask Microsoft about it here http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=483570&SiteID=1 - haven't got an answer though.
This will happen to me, *sometimes*, when I should be getting a SqlException. For example, accessing the database when it's not started, or a bad sproc name.
Kind of a pain, but not so bad with the breakpoint, at least it saves me time.
Regards,
Mike
That seems quite odd. Looking at the code in question - it is all on the client side, and DataPortalException (the client one) doesn't even get serialized or do anything fancy at all. It merely contains the inner exception and business object references, and takes a snapshot of the inner exception's stack trace.
So the only bit of that which is remotely interesting is the call to ex.StackTrace in the constructor.
Could you put your breakpoint into the constructor of DataPortalException to see if that completes?
I put a breakpoint in, followed it through, and the constructor for DataPortalException completes just fine. Whatever happens after that causes the crash. That is, you press F11 after the DataPortalException constructor comes back and then the crash.
Mike
tetranz:
still confirming this but, the problem only seems to occur for me for a BO derived from ReadOnlyListBase but not BusinessBase.
Ross
Yeah, there's something up with this. When you first wrote this something smelled familiar, but I couldn't duplicate it. Not really sure if I can duplicate 100%, but it seems if that a read-only object triggers a SqlException, this happens. If an editable object does the same, VS doesn't crash.
I'm using CodeSmith templates too, I have no idea if that's an issue.
Regards,
Mike
Anyone find a solution to this issue?
Seems pretty easy to reproduce at least on Vista with VS 2005 sp2 with Vista update. Just set the db connection string to something invalid and try and view/edit a project, it will throw a exception from try to list roles and that will lock project tracker and vs. If you kill projectracker sometimes vs comes back sometimes that gets killed to.
By setting the return object to null in the exception constructor it cures the problem actually going into debugger to show exception.
Annoying in project tracker but spent a while chasing this down thinking it something I was doing in some changes I made.
Justin
I don't follow what you are saying Justin. You altered Csla.Server.DataPortalException to set the return object (_result) to null?
public DataPortalException(
string message, Exception ex, DataPortalResult result)
: base(message, ex)
{
_innerStackTrace = ex.StackTrace;
_result = null;
}
Or are you saying something else?
No actually I just modified the client dataportal.cs line 193 from
throw new DataPortalException(
String.Format("DataPortal.Fetch {0} ({1})", Resources.Failed, ex.InnerException.InnerException),
ex.InnerException, result.ReturnObject);
To
throw new DataPortalException(
String.Format("DataPortal.Fetch {0} ({1})", Resources.Failed, ex.InnerException.InnerException),
ex.InnerException, null);
Seemed to cure the problem in my case although might still be a problem otherwise, although as the other posters said it only seems to be a problem when a ReadOnlyListBase is returned which pretty much only occurs on Fetch so I figured I would just change it there.
As they said the DataPortalException constructor seems to run through fine but goes into some infinite loop on throw. I didn't try "Unwind the call stack on unhandled exceptions" for vs.
I have to bring this subject backup... sorry but I think I have a similiar issue going on... and it does not have to do with VS IDE... my issue is the same with both Compiled apps and Debugging apps inside vs.
When using remoting to a remote server (separate computer) and the Server-Side Business Object Assembly is not the same as the one on the client... after the method call "result = proxy.Fetch(objectType, criteria, dpContext)" inside the DataPortal method Fetch... hangs.
I do not understand why... but it does? Is there something I am missing
ward0093
ward0093:
the Server-Side Business Object Assembly is not the same as the one on the client
It is odd though, because you’d think he’d get one
of those obscure Remoting exceptions about a serialization issue…
Still, there’s no doubt that having out-of-sync assemblies
is a certain cause for failure.
Rocky
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Wednesday, June 20, 2007 7:11 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] 2.0 DataPortalException
the Server-Side Business Object Assembly is not the same as the one on the client
I think that is your problem right there. There's probably an exception
being thrown but not getting back to the client, so the call hangs.
So... this issue is getting stranger,
we have this thread that loops every 60 seconds to make sure we can access the server... The very first time (usually, but not always) returns an error to the client:
Error occurred while accesssing the server-side business objects or database version; unable to determine if we are currently in-sync with the central server
---- BASE ERROR MESSAGE ----
Could not load file or assembly 'CMS.BusinessCore, Version=1.1.2726.16851, Culture=neutral, PublicKeyToken=74fbfaac09086bcc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Error occurred in [CentralServerSettings: GetServerSideAssemblyDetails] method.
---- EXCEPTION STACK ----
Server stack trace:
at System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)
at System.Runtime.Serialization.FormatterServices.GetTypeFromAssembly(Assembly assem, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.FastBindToType(String assemblyName, String typeName)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Bind(String assemblyString, String typeString)
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Csla.Server.IDataPortalServer.Fetch(Type objectType, Object criteria, DataPortalContext context)
at Csla.DataPortalClient.RemotingProxy.Fetch(Type objectType, Object criteria, DataPortalContext context)
at Csla.DataPortal.Fetch(Type objectType, Object criteria)
at Csla.DataPortal.Fetch[T](Object criteria)
at CMS.BusinessCore.AssemblyDetails.GetServerRoot()
But every call afterwards causes the client program to hang! Is IIS on the server stopping it... again I say "Usually" we get a return error on the very first call but not always.
ward0093
I understand problems with errors... but "Hanging"... that should not happen correct?
Also... I think something else is going on... because we did get the Assemblies In-Sync and the program still hangs? I am using a basic IIS setup with no firewall... what could be missing...
Even if the Assemblies were "Out of Sync" shouldn't we get an error back to the client?
ward0093
FINALLY.... After a good night sleep it dawned on me this morning...
The server is hooked up to the internet with a Static IP and no firewall or router. However... I was misinformed that our dev machines (all of them) are behind a firewall and router.
After hooking the server up to our internal network... viola! it works... even if the assemblies are out of sync... we get errors back from the server so we can diagnos this server side issue.
So... with that said... we now have to find out how to properly configure the Firewall to allow those exception traffic in. Rocky... have you seen this before in all your remoting tests?
sorry for the confusion,
ward0093
I agree.
The only “hang” situation I know of deals with a
read-only list. If an exception occurs in DataPortal_Fetch the client-side data
portal can hang when rethrowing the exception on the client. This appears to be
due to a bug in the debugger and I’m working with Microsoft to isolate
the issue.
The workaround is to uncheck “Unwind calls stack on
unhandled exceptions” in the debugger options.
But you said your issue occurs in release mode outside VS, so I
doubt this is your problem.
Rocky
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Wednesday, June 20, 2007 2:14 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: 2.0 DataPortalException
Well like I said when I was trying remoting in 1.0, I did
get just 'hangs.' I can't remember how I figured out what the problem was
though.
I would start small, and get remoting working on a single workstation (client
app on the same computer as IIS remoting host).
This setup should allow you to nail down the problem; you can even step into
server side code if you attach to the aspnet process.
“Unwind calls stack on unhandled exceptions” - No... that was the first thing I took a look and it was already unchecked...
it was definently the firewall in our office... the question I have is that I thought no configuration is needed on the network with CSLA & Remoting because everything is done via HTTP and port 80? Is there a setting we missed on our Router and Firewall by chance? Have you seen this before Rocky?
ward0093
No, I haven’t seen this before.
But you know, some firewalls screen content as well as blocking
ports. So perhaps the firewall is doing something based on the actual data
flowing through the connection?
Rocky
From: ward0093
[mailto:cslanet@lhotka.net]
Sent: Thursday, June 21, 2007 7:08 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: 2.0 DataPortalException
“Unwind calls stack on unhandled exceptions†- No... that was the first
thing I took a look and it was already unchecked...
it was definently the firewall in our office... the question I have is that
I thought no configuration is needed on the network with CSLA & Remoting
because everything is done via HTTP and port 80? Is there a setting we
missed on our Router and Firewall by chance? Have you seen this before
Rocky?
ward0093
There is a known problem where data portal exceptions will "lock up" Visual Studio if the business object is a read-only list.
The workaround is to make sure to uncheck the unwind call stack option as discussed earlier in the thread.
This appears to be a bug in Visual Studio's debugger (with the exception assistant actually), and I'm working with Microsoft to confirm it is a bug, and if so to get it fixed. I recently sent a consistent repro of the issue to a member of the debugger team, so we'll see what happens.
It isn't actually the case that VS hangs by the way. If you wait long enough it crashes. The actual problem appears to be a stack overflow within the debugger itself.
This issue, or at least some form of it, has been plaguing some of my development efforts over the past year. I too have been experiencing Visual Studio crashes related to using the ReadOnlyListBase class, although my situation was not fixed by unchecking the 'unwind call stack' option. Instead, I would open my solution, be able to debug once or twice...but if I would Rebuild Solution, Visual Studio would crash towards the end of the build process. In the event log, I was seeing the following:
.NET Runtime version 2.0.50727.832 - Fatal Execution Engine Error (7A0592A2) (80131506)
I was going to attempt to add some msbuild compile options to kick my build log out to a file to troubleshoot when I noticed that on my project's compile tab, 'Register for COM Interop' was checked. For giggles, I unchecked this and tried to get Visual Studio to crash through my normal process of opening the solution, running in debug and then rebuilding 2-3 times until VS would die. Remarkably, it is no longer crashing. FYI, my application is a class library that eventually goes into Component Services and utilizes Enteprise Services.
Obviously, this isn't a fix but hopefully it spurs more dialogue and hopefully a patch.
Cheers,
Matthew
From: Michael Hildner [mailto:cslanet@lhotka.net]
Sent: Tuesday, July 11, 2006 2:40 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] 2.0 DataPortalExceptionI put a breakpoint in, followed it through, and the constructor for DataPortalException completes just fine. Whatever happens after that causes the crash. That is, you press F11 after the DataPortalException constructor comes back and then the crash.
Mike
>>I can avoid the problem by going to Tools/Options/Debugging/General and unchecking "Unwind the call stack on unhandled exceptions".
Wow, how the heck did you find that? That works for me too. I haven't messed much with the VS defaults - although I've seen that option, I had no idea what it would do, so I never changed it. Quick google says it has something to do with edit and continue. Interesting as the error reporting will tell you it's something with the VB.NET compiler. Still, I use C#.
Seems more and more like a VS bug. I'll update my MSDN thread and see if anything comes of that.
Thanks for posting what you've found,
Mike
Copyright (c) Marimer LLC