ASP.NET - Common Gotchas

Question

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.

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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

Answer 5

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

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

(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.

Answer 10

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.

Answer 11

• Code in the html-markup.
• Bloated code-behinds.

Answer 12

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/

Answer 13

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.

Answer 14

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.

Answer 15

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!

Answer 16

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.

Answer 17

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

Answer 18

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.

Answer 19

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!