I'm currently in the process of writing an ASP.NET core application and I'm getting data from a web api and loading the information in a grid and some dropdown menus.
This all works fine, but I've noticed that sometimes when I'm debugging and I step through the functions that make requests to the api and receive the data back from it, the data just fails to load in my application. Everything seems fine while I'm debugging, and this doesn't happen when I start my application by selecting "Start Without Debugging."
I would like to specify that this only happens when I step through the code; if I run the debugger without any break points it behaves correctly. In addition this behaviour is not always observable when I step through the code, and it is more likely to happen when I take a long time.
I'd like to know if anyone knows what exactly is causing this or can point me to some reading material that would help me understand it. I'm assuming it has something to do with stalling the requests or making them time out but I obviously need to learn more about what is happening.
Related
I'm making app with using Xamarin.forms pcl.
Unless I use ModernHttp, my app is always deadlocked at the end.(Xamain.Forms-iOS).
It works fine for a while, but few hours later, every 'await' call does not back to its place.
This is a deadlock, isn't it?
My app has tons of http request call and it could be called at the same time sometimes.
This is very weird and serious problem for my app.
The problem is ModernHttp is out of date, which means the creator doesn't update library anymore.
Maybe because of that, I'm experienced some problem with using ModernHttp. For example, UriImageSource sometimes does not load the image from web. (Works fine with built-in HttpClient)
Any tip for me?
I am trying to debug a project, suddenly I'm running into an issue where enumerating any object collections results in a timeout if I try to view it.
If I run the program normally I have no issues. If I try to view any collection, such as a list, I get a timeout error and the whole thing bombs out.
I thought something might be going on with one of my more complex collections so I tried creating just a normal list of strings as follows...
List<string> blah = new List<string>{"fsdf","fsdg","Gt","gsersg","ser","gersgxdrsd"};
The same thing happens. I can hover over the object, I can even see the object count, however if I view the collection it dies.
I've ensured that the project/class library is in debug mode, disabled all extensions, restarted the system, tried percusive maintnence - nothing has worked.
Does anyone have any ideas? I'm completely losing my mind here.
I should also mention that this is a web application, I didn't notice before but a w3wp debug window pops up after I stop debugging. Sorry to leave out important info - was too frustrated to think straight when I wrote the post. I can still execute my code normally, and while debugging. I can examine all other objects without issue, it is only looking at collections in the watch window (or by hovering) that breaks.
Have a look at How to correctly debug web applications on local IIS 7.5 with VS 2010 Beta2?
I'm fairly new to web service development, and I am really confused about how ASP.Net Development Server synchronizes with code during debug mode. When I make changes to my service, I cannot figure out how to propigate those changes so that my client can "see" them (I've been able to synchronize through a stumbling series of publishing the service, viewing the service in browser, etc... but I have a feeling there's a more reliable system than my random ritual).
Here are the symptoms I'm seeing: After I've made a change to the code behind my service (Service1.svc.cs), started the application through the debugger and attached the debugger to the WebDev.WebServer.exe process as well, my latest changes are not executed, and my breakpoints are not hit (they have the message that
"The source code is different from the original version."
What really baffles me, though, is that when the ASP.Net Development Server notification pops up in my system tray, its physical path points to my project folder, so I don't understand how it could be looking at anything but my current code files.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
I'm having a simple ASP.NET application hosted on my local IIS6, under Vista.
It contains a button that when I click I execute a piece of code for recognizing the text in a WAV file (using the System.Speach.Recognition.SpeechRecognition class) and display the text in a label.
The code works great on a desktop application, and it almost works on the web one... I say almost, because if I debug, I can see that the recognizer returns the correct text from the WAV, I can see that I am finishing the handler for the button click with no error, but nothing gets displayed in my page, and the page appears like loading... it's hanging, or something... No errors, no timeout, nothing. Just loading...
I don't know if this detail helps, but in order to make the piece of code that was already working on the desktop application work on the web application, I had to set the identity of the ApplicationPool of my application to LocalSystem (security breach, I know). Otherwise, I would have received a Access Denied error (0x80070005(E_ACCESSDENIED)).
Do you have any ideea why the call hangs like that? I'm fighting with this for more than two days, time pressures me, and I have no clue... Any help is really welcomed!
Thanks!
After another one week of stuglles, I found an overcome to the problem. I'm posting this just so other that might have this problem find the solution faster.
The solution was to call the method for making the speech recognition on a different thread. I think this forced the release of all resources in that thread after the recognition ended.
I cannot make any sense why this even happened on the first place (I used using blocks and I closed and disposed all the object in all the imagining ways), but I suspected to be a memory release problem...
Anyway, a very simple call on another thread fix it!
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.