views:

970

answers:

19

When I am working with ASP.NET, I find that there are always unexpected things I run into that take forever to debug. I figure that having a consolidated list of these would be great for those "weird error" circumstances, plus to expand our knowledge of oddness in the platform.

So: answer with one of your "Gotcha"s!

I'll start: Under ASP.NET (VB), performing a Response.Redirect inside a try/catch block does not stop execution of the current Response, which can lead to two concurrent Responses executing against the same Session.

+5  A: 

Life cycle of custom controls does not match up perfectly with page life cycle events of same name.

Bob Dizzle
+19  A: 

Don't dynamically add controls after the page init event as it will screw up the viewstate tree.

Bob Dizzle
+1 Thanks, good tip!
Chuck Conway
+2  A: 

Don't edit your web.config with notepad if you have accented characters, it will replace it with one with the wrong encoding. It will look the same though. Just your application will not run.

Sklivvz
IME the problem is that it inserts a BOM at the start of the file. Correct for .aspx files, but wrong for web.config (XML documents must not start with a BOM.)
finnw
+8  A: 

Viewstate ... if you are using it ... can get out of control if you are not paying attention to it.

mattruma
Viewstate is fine for changes made to controls by the user. It's when changes made by your code start making their way in there that you have a problem.
Joel Coehoorn
I agree ... it's just something you want to keep an eye on ... as it is prone to sloppiness.
mattruma
A: 

You can't reference anything at all above the application's root folder.

Joel Coehoorn
That's a security feature. Otherwise malicious code, say on a shared server, could browse the entire drive.
MatthewMartin
A: 

All the code I have to maintain that still looks like it was written in vb6, showing complete ignorance of the newer styles.

I'm talking things like CreateObject(), excessive <% %> blocks, And/Or instead of AndAlso/OrElse, Len() instead of .Length(), s/o Hungarian prefix warts, Dim MyVariable with no type, functions with no return type... I could go on.

Joel Coehoorn
+1  A: 

Custom controls are only supported by the designer when building the control or when building the page that uses the control, but not both.

Joel Coehoorn
+4  A: 

Having to jump through hoops to get the .ClientID property into javascript.

It'd be nice if the render phase of the lifecycle created a script that set up a var for each server control with the same name as the control that was automatically initialized to the clientID value. Or maybe have some way to easily trigger this action.

Hmm... I bet I could set up a method for this on my own via reflection.

Joel Coehoorn
I HATE this. Thank god the MVC framework makes this unnecessary.
Adam Lassek
At least in VB.NET, you have the option to use classic ASP delimiters to get the job done. It's not pretty, but it works:function jsFunction(){ var someElement = document.getElementById(<%= SomeControl.ClientId %>); ...}
Jeremy Frey
I wouldn't put it straight into a .getElementById() call. I prefer to have a global script near the top where each control I use get's it's own var, defined once, with the clientID set as the value. They'd save a lot of hassle if they just made that standard.
Joel Coehoorn
this has been fixed in ASP.Net 4.0
Alexandre Brisebois
It was addressed. I'd say it's still far from "fixed".
Joel Coehoorn
I would consider it "fixed" as best as possible considering they need to support the legacy way of creating ID's. If you're working on a new site from scratch, setting the Page or MasterPage's ClientIDMode to Static will override it on all controls.
rossisdead
A: 

(VB.NET) If you send an Object via a Property's Get accessor into a function with a ByRef keyword, it will actually attempt to update the object using the Set accessor for the Property.

Ex:

UpdateName(ByRef aName as String)

UpdateName(Employee.Name) will attempt to update the name by using the Set on the Name property of Employee.

Thunder3
That's a good thing- the way it should be.
Joel Coehoorn
+5  A: 

The whole life-cycle thing in general.

Not that I see anything wrong with it, it's just that you'd be amazed at the number of people who start working on large ASP.Net projects before understanding it, rather than vice versa. Hence, it becomes a gotcha.

Note that I said large projects: I think the best way to come to terms with the life cycle is to work on a few smaller projects yourself first, where it doesn't matter so much if you screw them up.

Joel Coehoorn
+1 This is true in general. I go a step farther and recommend they stick around to feel the pain of their coding/design decisions.
Chuck Conway
A: 
  • Code in the html-markup.
  • Bloated code-behinds.
Thomas Eyde
This wasn't an area to bitch about what you don't like about ASP.NET
FlySwat
You need code somewhere: pick one.
Joel Coehoorn
I am not bitching, I have been burned more than once due to those two bullet points. And yes, I need to put the code somewhere, but we aren't limited to the markup or codebehind, are we?
Thomas Eyde
+1  A: 

When using a gridview without a datasource control (i.e. binding a dataset straight to the control) you need to manually implement sorting and paging events as shown here:

http://ryanolshan.com/technology/gridview-without-datasourcecontrol-datasource/

Adam Pope
+2  A: 

I just learned this today: the Bind() method, as used with GridViews and ListViews, doesn't exist. It's actually hiding some Reflector magic that turns it into an Eval() and some kind of variable assignment.

The upshot of this is that calls like:

<%# FormatNameHelper(Bind("Name")) %>

that look perfectly valid will fail. See this blog post for more details.

Adam Lassek
+4  A: 

Page_Load is run before control handlers. So you can't make changes in an event handler and then use those changes in the page load. This becomes an issue when you have controls in a master page (such as a login control). You can get around the issue by redirecting, but it's definitely a gotcha.

Dan Goldstein
+1  A: 

Linq: If you are using Linq-To-SQL, you call SubmitChanges() on the data context and it throws an exception (e.g. duplicate key or other constraint violation), the offending object values remain in your memory while you are debugging, and will be resubmitted every time you subsequently call SubmitChanges().

Now here's the real kicker: the bad values will remain in memory even if you push the "stop" button in your IDE and restart! I don't understand why anyone thought this was a good idea - but that little ASP.NET icon that pops up in your system tray stays running, and it appears to save your object cache. If you want to flush your memory space, you have to right-click that icon and forcibly shut it down! GOTCHA!

Shaul
This smells like abusing your DataContext (extending its lifetime beyond what it was designed for). Also, try enabling Edit-and-Continue.
ErikHeemskerk
+2  A: 

If you are running Classic ASP applications in the same Virtual Directory as you ASP.Net application, the fist hit on the application must be on an ASP.Net page. This will ensure that the AppPool be built with the right context configurations. If the first page to be hit is a Classic ASP page, the results may vary from application to application. In general the AppPool is configured to use the latest framework.

Alexandre Brisebois
+2  A: 

Making a repeater-like control, and not knowing about INamingContainer.

vdboor
A: 

Being unaware of heaps of existing and extensible functionality in the framework. Things often redone are membership, roles, authorization, site maps. Then there are the controls and the associated tags which can be customized to alleviate issues with the client IDs among others. Also simple things like not knowing to properly use the .config file to auto import namespaces into templates, and being able to do that on a directory basis. Less known things like tag expressions can be valuable at times as well. Surely, as with all frameworks, there is a learning curve and always something left to be desired, however more often than not it is better to customize and extend an existing framework instead of rolling your own.

eulerfx
+2  A: 

Debugging is a very cool feature of ASP.Net, but as soon as you change some code in the app_code folder, you trigger a re-build of the application, leading to all sessions being lost.

This can get very annoying while debugging a website, but you can easily prevent this using the "StateServer mode" : it's just a service to start and a line to change in the web.config : refer to msdn : http://msdn.microsoft.com/en-us/library/ms178586.aspx

  1. InProc mode, which stores session state in memory on the Web server. This is the default.
  2. StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
  3. SQL Server ...
  4. Custom ...
  5. Off!
oldbrazil
You could just create a web application instead of a website, which aleviates a lot of these problems.
ErikHeemskerk