In WAP, should you expect to get errors when debugging an .aspx during compile time? I'm not getting any errors when my .aspx has errors until runtime when using Web Application Projects. I never really thought about it, because I've always just used WAP. I'm asking the question for someone else and I don't see any information on an answer to this.
we do conditional rendering of custom controls so it's important for us to be able to debug errors during compile time in an .aspx page before it hits production.
If you have syntax errors these can get caught at compile time. However, if you have bugs in the logic of the program or the look of the page, that may not always be caught at compile time. For example, if you want to have a specific layout of a form this requires running the page in various browsers to confirm that there isn't a bug.
Tools like Resharper can help some but there isn't a silver bullet for this. It may be better to have tests like nUnit or WatiN to help catch errors if something doesn't work as expected in terms of finding bugs.
Related
I did profiling of my asp.net web application when it randomly started using 99% of CPU to know what is going on. But what I get is some System.Collections.Generic.Dictionary<int,int>.FindEntry(int) called by some other external code are the most expensive one.
What can I do with this information? It should be somehow related to my code (or at least my actions), but profiler is showing me just that some external code are calling other external code (which I can neither look at, let alone change).
How do I know what is the cause of this? Is it even possible?
This is the other parts of call stack (from top to bottom, and the bottomest is FindEntry method), if it is somehow useful:
Yeah I got this same problem. I tried turning on native and external code debugging and that helped but it's still very confusing. It seems like VS profiler has a hard time tying external codes calls back to whatever ultimate started the call chain in your own code.
All answers point to "no!". However, some people say having debugging enabled is convenient when errors occur on the server. I am not sure what they mean by this. Do people actually debug live server code? I honestly didn't even know you could. With the website I work on, we use ELMAH for error reporting. When a server error occurs, we are emailed a complete stack trace. After acquiring a rough idea of where and how the error occurred, I will open the local solution containing all the code that's currently deployed to the production environment and debug locally. I never actually debug the code on the server itself, so I am not sure what people mean by that.
I ask this because I just found out today while consolidating web.config XML that debug=true exists on in the staging and production environments' web.config files. It must have been this way for a few years now and I am wondering what benefits we will experience by turning it off. Could anything possibly depend on debugging being turned on that might break if shut off after being enabled for over two years since the beginning of the project?
It should be fine to turn it off, and you should get a slight performance boost. It sounds like you are doing the right thing using ELMAH. I cannot think of a good reason why you would want to have it turned ON in production... hope that helps.
The "advantage" that people are talking about is that when an error occurs on the site, the default asp.net error page will show you the actual line of code that failed. If you have debug=false, then you will not see any of that information. I think most who would recommend something like this either do not know about logging frameworks like ELMAH (and hence, cannot easily find the cause of errors on the site without this), or they have left it on the production machine in the beginning of the project while they are installing/testing the site, and then forgot to change it later.
However, with a proper logging framework in place, you can still get good error information behind the scenes without presenting it to your end-users in that way. In fact, you don't want to show that kind of information to end-users because a) they won't know what it means, and b) it could be a possible security issue if sensitive aspects of your code are shown (info that might help somebody find vulnerabilities).
All the System.Diagnostic library is depend from this flag. If you do not use any of this function, then probably you can not see any direct effect, but for see other effect and messages that come from debug functions you need to monitor at lease the windows log file.
Functions like Debug.Assert, and Debug.Fail are still active if you do not set the debug flag to off, and affect performance, and maybe create small issues that you never see if you do not check the windows system log file.
In our library that they are full with assert, the debug flag are critical.
Also with Debug flag to on, probably the compiler is not make optimization's that also affect performance.
Either an advantage or disadvantage depending on how you look at it is that Webresource.axd type files are not cached when debug="true". You've got the advantage of having the latest files every time and a disadvantage of having the latest files every time.
This is often true with other third party compression/combining type modules due to the fact that it is easier to debug non minified javascript etc so they usually only begin properly function once debug is disabled.
I've just built a crap load of Telerik reports for my web site project, and they all work nicely. I have to demonstrate them tomorrow, and tried to build a viewing page that hosts their web ReportViewer. I have asked this question on their forums as well, but expect less response than from SO late on a Friday night.
Whether I use GAC or bin references, as soon as I add the ReportViewer control to my page, even without trying to load a report, I get the error Failed to map the path '/'. Other Telerik controls, from the Web.UI library work fine. I'm not expecting a Telerik specific answer here, although that would ease the pain of my all-nighter, but I can see nothing meaningful in the stack trace for this error.
How can I go about diagnosing what Telerik is looking for and can't find, or something of that ilk? This is a serious emergency, and I will sort a 'dereferenced' bounty for anyone that can offer any suggestions tonight. I'm going to reinstall Reporting so long.
UPDATE: Foolishly wary of excess complicating factors, I always try new things like this in a small, dedicated project separate from my main one. Yesterday I quickly tried a small web site project when I encountered my problem. I then tried a small web application project, with local, not GAC references to telerik, all telerik refs set to copy to local, and it all worked. Naturally I was quite ecstatic, as my main project is a web app, not site.
so you have a webpage running without problems.
Than you add a telerik ReportViewer controls - run the things again and get an error:
...Failed...'/'...
The control simply sits in the page and does nothing.
So like womp I would ask you to provide the full error output!
One other question:
Does the error also occure on the development machine (running the project from VS with webdev server)?
And a hint meanwhile (not sure if you'v already checked this):
http://www.telerik.com/support/kb/reporting/general/deploying-telerik-reporting.aspx
One last thing - maybe it con help you. I made up a little web site doing what you have told your site does.
You can download it here: www.pp-p.com/rvsite.zip
Maybe a look at web.config or so can help you to find what's missing in your site.
One thing - in the BIN folder are two txt files - replace them with the DLLs from telerik reporting to have the project work.
Maybe this helps (for the weekend till the telerik support guys are back at work)..
I have a requirement on my new project to serve up some "hidden" assets (actually just stashed in the App_Data directory) after a certain date. Before then, they should act like they aren't there.
I've done this kind of thing a hundred times with Page object, but as I started work on this, I thought I'd look into handlers. Having never worked with them (and being a little intimidated by them), I was happy to find that they'd serve up my XML and JPG files without the overhead of the whole Page class. Already, I'm happy that I considered it. I wrote it to handle functionality like "MyHandler.ashx?secretfile=blah.xml", and it worked great.
Then I started looking at special extension handling, so that a request for "blah.xml.secret" would get picked up by handler and return blah.xml after checking the date. A couple of lights went off in my head, and I reworked the code so that it handled that case. It worked (in the IDE)! I was pretty excited.
Getting it onto the dev server (IIS) was a little different: I had to register .secret as a .NET type (no big deal), and it still didn't work until I unchecked the "verify file exists" checkbox. (blah.xml.secret obviously doesn't exist: blah.xml does, but not in the spot it's being asked for, only in the secured App_Data directory.) That's not a huge deal, but now my clever solution relies on two implementation details from the IIS side.
So my question is: is this the intended use of handlers in asp.net? Am I warping this beyond recognition? I feel like I've seen sites do tricks like this in the past, but for the one thing I'm trying to do, the IIS changes seem overly complicated. In my research on this, I didn't find a slam dunk 1-2-3 guide to using handlers that included an example like this, so it's got me thinking I'm maybe abusing it or going about it the wrong way.
Yes, that's pretty much how it works. (In Windows Server 2008 there is a remote chance that you can do the settings from web.config so that you don't have to change anything in IIS.)
If you use an extension that isn't already registered to be handled by the ASP.NET engine, you have to register it. If you use an extension that already is handled by ASP.NET, like .aspx, then you don't have to register anything in IIS. (When you run it in the integrated web server in Visual Studio, everything is already handled by ASP.NET, that's why it works there.)
In order to debug an asp.net web app I have to have IE Script debugging enabled. Unfortunately, in the past week or so google's analytics javascript has developed a problem. So that when I browse to a site that has google analytics I receive the little pop up "A runtime error has occurred. Do you wish to debug?"
Yes, even stackoverflow is affected.
This is a tremendous pain in the butt. Is there any way to keep IE Script debugging enabled to keep the .net debugger happy, but get rid of the pop up?
I would suggest using IE for debugging purposes only, and Firefox for darn near everything else. Your life will benefit from this.
Script Debugging is not required to debug ASP.NET pages, it is only required if you wish to stepthrough script errors, you can disable this option in IE and still debug your server code fine. Unfortunately it is an IE wide option so if it's on it's on and if it's off it's off.
But disabling the option will not prevent you from debugging your asp.net applications.
Are you debugging javascript behaviour specifically in IE? If not, get Firefox and Firebug. Javascript debugging in IE is painful, and should only be resorted to in situations where you're trying to fix IE idiosyncrasies. You don't need script debugging enabled in IE if you're just debugging web forms.
You could write some code to make a change to the following key in the Registry
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Disable Script Debugger
Depending on how you have your project you might be able to tie it to the actual build (via a Macro), or if anything just put it somewhere in your Application_Start event.
Returning back to normal might be a little more difficult. Potentially you could watch for the iexplore.exe process and when it dies you revert it back.
Hope that helps.