Using the Silverlight 4 WCF RIA services works just fine via web page. After installing it as an Out Of Browser application, there is a blank screen then an error comes up saying "Load operation failed for query 'GetUser'. The HTTP request to 'http://reports.mywebsite.com/Reports/ClientBin/Reports-Web-AuthenticationService.svc/binary/GetUser' has exceed the allotted timeout..." Using the SqlMembershipProvider with userid/password in the database connection string - using Forms Authenication.
Clicking 'OK' and then the login screen comes up and everything's normal thereafter.
Kinda odd that the timeout happened and then everything's fine. What can I do to prevent that from happening?
Thanks!
This is likely due to your RootVisual not being set to something. See my post here that addresses this issue:
http://blog.virtual-olympus.com/blog/post/2011/04/10/Silverlight-4-Out-of-Browser%E2%80%93Windows-Authentication-Timeout.aspx
Related
I'm new to Blazor.
I'm hosting a Blazor Server app on Window 2016 machine(IIS). If I leave the app hanging for a long time on the browser, then it shows this error message 'An error has occurred. This application may no longer respond until reloaded. Reload'
How can fix this issue? How can I make the app reload if the session times out?
After upgrading an application from .NET Core 1.0 to 2.1, I am receiving the following error when I try to debug it with IIS Express:
Unable to start process C:\Program Files\dotnet\dotnet.exe. The web server request failed with status code 502, Bad Gateway.
However, this only happens every second time I launch the application. Otherwise it works just fine if I just launch it again.
This creates a mild nuisance to my debugging process, as I constantly have to keep closing the error windows popping up.
The full response shows some additional info:
HTTP Error 502.3 - Bad Gateway
The specified CGI application encountered an error and the server terminated the process.
And the error code "0x80072efe" is shown.
Logging is enabled in web.config, but the crashing launches are not shown at logs at all. I have also tried looking Event Viewer for additional information, but I have not found anything.
The only fix for this I have found so far is to set Kestrel use libuv instead of sockets, but I have no idea why it works. Does anyone have any idea how to fix this?
I encountered the same problem after I upgraded, regardless of what I did it would always show the 502 error on the second load. It appears this problem was introduced in ASP.NET Core 2.1. I tracked it down to the asp-prerender-module tag in my view. Remove the prerender and it goes away.
I was able to fix the problem and keep my prerendering by upgrading to ASP.NET Core 2.2.
My SL application is commercial and working just fine on hundreds of machines.
SL is using a WCF service and it works as expected, but today I observed behavior on client machine, where literally no call is made to server.
After you click button that sends a call, some error occures, and no record about WCF call is created in Fiddler.
Error is:
[HttpWebRequest_WebException_RemoteServer]
Arguments: NotFound
Debugging resource strings are unavailable...
I read about this error that people recommend to use Fiddler, but as I say there is no call displayed in Fiddler
So problem is worse than I thought initially.
It comes and goes. Currently we have found a working solution that fixes the problem after it appears although it doesn't make any sense to me.
For example if I get this error in chrome & mozilla & OOB version,
launching a program in IE works, and after that chrome,mozilla & OOB
start to work too.
Thing is that same people who had this problem solved with this workaround experience it again in some days, like a week, with no apparent reason, and then combination of launches from various locations helps (usually IE helps the most).
Any help appreciated, I start a bounty as its pretty sick bug and I need to fix it somehow.
Update
Weird IE fix scenario:
At some point OOB version gets into state where it doesn't send any WCF request to server.
(fiddler doesn't see it, server doesn't gets it).
After launching web version in IE, and hitting the same button, that sends WCF request we get desired result in IE web version.
Without changing anything else, just relaunching OOB version which was in this buggest state before, makes OOB version work correctly. Its not reinstalled, not changed - nothing.
This is what I call "IE cure" of this problem.
So the question is what can IE launch potentiall change for OOB version?
According to this thread the message Debugging resources are unavailable appears when de client is not using the the Silverlight Developer Runtime.
This means that the actual exception is hidden from you (and us) so the next step is to reproduce the error on a system that has the Silverlight Developer Runtime.
I found this article. It might be worth it to check the certificate you are using (are you using a certificate) It is one of those things that is different with OOB apps and browsers.
I have a Silverlight 4 application which talks to a 'manager' class, which talks to a WCF Service ( .net 4) , which uses the Microsoft.ApplicationBlocks.Data library to talk to my SQL database.
My issue is with exceptions not bubbling up to the Silverlight App.
What happens is, an insert to the database fails, creating an SQLException, this then throws the error further, to the generated service reference code used by the Manager, which, in the completed event handler, finds that the Error property is not null. This throws an event to the Silverlight app which displays a message to the user saying that an error has occured.
This works when I am locally debugging my application but fails silently when the appliaction is on the live/production server, no error message gets displayed.
If I generate the service reference from the wcf service running on the server (not locally), and use a local instance of my Silverlight App, it also works correctly which makes me think that the error is happening in the service reference (generated code) and Silverlight communication.
The service is hosted in a 'hand-coded' host application and the Silverlight app on the server is hosted in IIS. They both use http and not https.
I have scoured the Internet but found nothing that relates to this situation. I do not kill off objects, therefore preventing exceptions being returned to non-existant objects.
In short, the Manager correctly recieves and throws an event on my local system but not when deployed on the server.
WCF Experts needed please!
So, after some more fruitless searching, my collegue built a test app where he built a custom silverlight Fault Contract class based on this example:
http://msmvps.com/blogs/theproblemsolver/archive/2009/01/27/returning-exception-information-to-a-silverlight-client-through-wcf.aspx
Although this helped alot with getting the specific error from the service instead of the generic garbage Silverlight spews, we could still not get the error to display on the screen.
My previous guess that the communication was failing was incorrect. Instead, it was simply the fact that the result did not have any effect on the UI Thread. We used the Dispatcher to jump back onto the UI Thread:
Deployment.Current.Dispatcher.BeginInvoke(
() =>
{
//throw event to window which shows error window
}
);
which displayed the true error. I still do not know exactly why this was required for the app on the Production server but it worked fine on my localhost, in debug mode or not.
If anyone with more knowledge about the technicalities of this occurance reads this, please be so kind as to explain what really happened here.
I have written a Silverlight application that is basically an account registration form. I have been able to successfully deploy this to one of our production servers running windows server 2008/IIS7. While this took some time to do, I was able to work through and solve the issues that came up fairly easily. Now I am trying to deploy the application on our main production server. This server is running windows 2003/IIS6 and this is where I have hit some problems.
I have solved most of the issues and now the silverlight application will load and I can see the form for a few seconds before it disappears. I believe during this time it is trying to load data from the database using the RIA services.
In IE I get the following error:
Webpage error details
Message: Unhandled Error in Silverlight Application
Code: 4004
Category: ManagedRuntimeError
Message: System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
System.Windows.Markup.XamlParseException:
Cannot find a Resource with the Name/Key ApplicationResources [Line: 6 Position: 9]
I believe it must be a configuration issue in IIS6 because the app works fine on IIS7 but I am drawing a blank as to what to try. I have spent hours trying to find a solution to this particular problem and while others have mentioned getting this problem the answers always tend to be non-specific in nature.
This is what I have done so far:
Added New Application Pool for .NET 4.
Set the website to use .NET 4 on the ASP.NET tab (nearly had heart failure when this did an iisreset).
Added the MIME types for Silverlight .xaml, .xap, etc.
Unchecked Integrated Windows Authentication (was giving an error when checked).
Give Execute permissions to Scripts and Executables.
Recycled the application pool.
The one thing I have seen suggested but have not tried is an iisreset, and while I am not entirely convinced that doing this would solve the problem, we have scheduled this to be done tonight (if I cannot find a solution before then).
So basically I am wondering if anyone out there has seen this problem and knows how to solve it?
UPDATE 1: We tried an iisreset last night and as I expected this did not solve the problem.
Okay I have solved the problem. As suggested I did a WCF trace on the application. This highlighted the REAL problem straight away, which was 'The SELECT permission was denied on the object...'. Once I fixed this the application works as I expected. It turns out that a colleague of mine had already made this permission change on our other server (running IIS7) so that was why it worked there (this is bad - I know).
Also it didn't help that the javascript error I was receiving on the client side (shown in the question) had nothing to do with the underlying issue and led me well and truly up the garden path.