December 2009 - Posts

Merry Christmas and a Happy New Year
Thu, Dec 24 2009 17:08

See all next year!

by luisabreu | with no comments
Filed under:
Enabling session state programmatically
Fri, Dec 11 2009 15:18

“Finally!!!”, you say…I hear you man! With ASP.NET 4.0, we can enable/disable session state programmatically (like in C# code :) ). The new version of the framework adds a new method (SetSessionStateBehavior) to the HttpContext class. You’re supposed to pass it a value from the SessionStatebehavior to influence the use of session state. Currently, you can pass the following values:

  • Default: passing this means that everything works as before (ie, you control session through the @page directive or the <pages> entry in the web.config file);
  • Required: session state is enabled for read/write access;
  • ReadOnly: gives access to read only session state;
  • Disabled: turns off session state for the current request.

In practice, passing one of the last three methods means that eventual settings specified at the @Page directive or in the <pages> element of the config file are ignored. There’s a caveat: you can only use the new method influence the use of state until the AcquireRequestState event is fired. Doing it after means getting an exception.

And that’s it. Stay tuned for more on ASP.NET.

by luisabreu | with no comments
Filed under:
Another cool nudge: maintaining the selection of an element when using paging
Thu, Dec 10 2009 10:24

This is one of those simple things which really improves the use of controls like GridView and ListView. ASP.NET 4.0 adds the EnablePersistedSelection property to the GridView and ListView controls. To support this feature, the control ended up adding a new field (_persistedDataKey) which is saved in the control state of the control. Notice that what is persisted is the key that uniquely identifies the selected item (and not its position in the rows displayed by the grid.

When the grid needs to create its rows, it will update the SelectedIndex (and other associated props) by checking the data key of each item it is rendering against the value persisted in the _persisteDataKey field. What this means is that when you change the page and go to a new one that doesn’t have the previous selected item, you’ll end up getting –1 for the SelectedIndex property. I guess this isn’t really the behavior you’d expect, but I’m assuming that it wasn’t changed so that it was backward compatible with previous versions (or it might end up breaking existing code). To recover the current selected item you’ll have to use the new SelectedPersistedKey property (which returns a DataKey object associated with the item that has been selected).

And that’s it for now. Keep tuned for more  on ASP.NET.

by luisabreu | with no comments
Filed under:
Christmas 2009 in Funchal
Wed, Dec 9 2009 19:48

Yesterday I’ve took some pictures of Funchal by night. This is really the best time of year to visit this city…

by luisabreu | with no comments
Filed under:
Ensuring that IIS 7 will handle extensionless URLs
Wed, Dec 9 2009 14:55

As you probably know, I’ve been updating my ASP.NET book to 4.0. It has been more work that initially expected, but I can also say that I’ve been having some fun. One of the things I’ve had to investigate was routing. This is one of those cool additions that will really help improve SEO in web forms apps (ASP.NET had some support for friendly URLs, but it was close to useless :))

Now, if you’ve been doing MVC, you already know that routes are an important feature and you probably know lots about it (btw, I’ve written about it in the past). One of the things you probably know is that getting extensionless URLs in IIS 6 involves some configuration. However, that shouldn’t be needed in IIS 7 and above. I guess it was a surprise to me when I started getting 404 on my demo app for routing in Web Forms. What? 404? But I’m running the site in IIS 7 with integrated mode on…wtf???

Well, after some tweaking, I’ve managed to understand what was going on: you must ensure that the routing module is configured to handle managed and unmanaged requests (there are several options for doing this; the easiest is using the IIS 7 admin console – check the properties of a module and you should see a dialog with a checkbox that lets you enable/disable this feature).

I’ve started asking around and I was lucky enough to get an answer from Stefan Schackow about it. When you create a new VS project, you’ll see that the web.config contains the following entry:

<modules runAllManagedModulesForAllRequests="true" />

this is all that takes to make everything run smoothly. Unfortunately, I’ve ended up deleting that entry from the web.config and that meant that my extensionless URL never got through the URL module (it ended up being processed by the static file handler, which is not a managed handler). Special thanks go to Stefan for helping me with this problem.

by luisabreu | 1 comment(s)
Filed under:
The “Cannot open user default database…” error
Sat, Dec 5 2009 11:34

Today I’ve ended up getting the following error after refreshing a page that was working (3 minutes before):

Server Error in '/' Application.

Cannot open user default database. Login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: Cannot open user default database. Login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.

As I said, this happened while I was updating the code for my book and it happened when I hit refresh on a working page in the browser. So, if it was working just a few minutes ago, why did it stopped working? It must have been something I’ve done, but what? After some seconds, I’ve remembered that I did add a new LINQ To SQL file to my project and that it used the same SQL Express database (user instance) than the remaining site. After checking the Server Explorer, I could see that VS was still connected to the instance database. And yes, that was the problem: closing the connection on Server Explorer made the error go away!

I’m almost positive that this was not the error one got in previous versions of ASP.NET (when an user instance was opened by some other process), but I might be wrong. Now, the important thing is that if you end up getting this error, you should check if there’s anything holding up your user instance db file. And that’s it. Stay tuned for more.

by luisabreu | with no comments
Filed under:
The new ViewState model
Thu, Dec 3 2009 21:18

Everybody knows that using view state means that you’ll go to hell when you die….nonetheless, many keeps using it, even after having been warned about it (probably because they find heaven to dull??? who knows :) )…to be honest, the default opt-out model we had until now didn’t really helped. The good news is that ASP.NET 4.0 introduces a new model known as opt-in model. So, what’s the idea behind it? A quick recap of what we had is in order…until 4.0, view state was controlled through the EnableViewState property. Whenever you set it to false, you’re saying that that control and all its children won’t persist any data in view state.

Now, this caused all sorts of quirks in v1.0 because programmers would turned it off at the page level (less KBs in a page is good, right?) and all hell broke loose because server controls stopped working. The workaround was simple: leave it on by default at the page level and turn it off in all the controls that don’t need it (btw, this was called the opt-out model). Even though ASP.NET 2.0 introduced control state to make controls work without relying on view state, the truth is that existing opt-out view state model still sucked in the real world because 1.) people are lazy and/or 2.) there was always someone who ended up forgetting to disable view state in the controls they’ve added to the page.

Now, things are better with ASP.NET 4.0 and its new opt-in model. In order to make it work, they’ve added a ViewStateMode property, which gets its value from an enum with the same name.Currently, it supports the these values:

  • Inherit: inherits the value of the property from its control parent. This is the default value;
  • Enabled: enables view state in the current control (even if the parent has its ViewStateMode set to Disabled);
  • Disabled: disables view state in the current control.

Before going, you must understand that this property will only be of use when the EnableViewState property is set to true (when it’s set to false, view state is off for that control and all the controls on its control tree). Now, lets see how we can use this new property and the new opt-in model.

By default, ViewStateMode is set to inherit (default value inherited from the Control class itself – which, btw, also sets EnableViewState to true). Now, if you set the ViewStateMode at page level to Disabled, you can turn it on only for the controls that need it by setting that property to enabled on those controls. This is the new (and let me add this: cool!) opt-in model introduced by ASP.NET 4.0.

Final note: If you debug an ASP.NET page, you’ll notice that Inherits is still the value of the ViewStateMode property…if that is the case, then view state shouldn’t be on by default, right? After all, Page is the top control in the control tree and the docs clearly say that view state is on only when the ViewState is set to Enabled or when a parent control has that value and the current one has its mode set to Inherits…so, “what gives?” (reaped shamelessly from October Road, another great TV show which ended abruptly…it seems like these ABC guys terminate all the series I like…oh, lets leave this whining to a future post)

The answer lies on the private SaveAllState method, which is responsible for persisting view state info into the hidden field (the default behavior). When it sees that the ViewStateMode of the page is set to Inherits, it will automatically use Enabled instead. And that’s it. I’ll try to come back with more on ASP.NET.

by luisabreu | with no comments
Filed under:

Search

This Blog

Tags

Community

Archives

Syndication

Email Notifications

News




  • View Luis Abreu's profile on LinkedIn


    Follow me at Twitter

    My books

    Silverlight 4.0: Curso Completo

    ASP.NET 4.0: Curso Completo

    Portuguese LINQ book cover

    Portuguese ASP.NET 3.5 book cover

    Portuguese ASP.NET AJAX book cover

    Portuguese ASP.NET AJAX book cover