LA.NET [EN] : ASP.NET

Enabling session state programmatically

luisabreu — Fri, 11 Dec 2009 15:18:48 GMT

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

Another cool nudge: maintaining the selection of an element when using paging

luisabreu — Thu, 10 Dec 2009 10:24:42 GMT

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.

Ensuring that IIS 7 will handle extensionless URLs

luisabreu — Wed, 09 Dec 2009 14:55:45 GMT

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.

The “Cannot open user default database…” error

luisabreu — Sat, 05 Dec 2009 11:34:32 GMT

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.

The new ViewState model

luisabreu — Thu, 03 Dec 2009 21:18:55 GMT

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.

Getting 503 errors on IIS 7 with custom application pool (Integrated Mode)?

luisabreu — Thu, 26 Nov 2009 15:23:06 GMT

So today I’ve though about giving IIS’ integrated mode a shot…The idea was simple: create a new application pool, configure it to use ASP.NET 4.0 in integrated mode and then associated it to an existing web application. The problem: The first request would always kill the application pool and it returned a 503 error to the browser. IIS Manager seemed to confirm that the pool was really dead:

WTF? I’ve read a couple of posts on IIS 7 and 503, but none helped. Then I tried one more thing: I’ve configured the web app to use the default ASP.NET v4.0 application pool. And it worked…the mystery was solved when I looked carefully at the application pool list. Can you spot the problem? If you’re thinking that my custom livro application pool is using the wrong .NET version, you’re right! I don’t know how it happened, but it seems like all this beta stuff I’ve been adding to my machine removed the correct version of .NET from the .NET version dropdown (I only had v4.0 available from the dropdown list).

Running aspnet_iisreg from within the 4.0 framework folder made everything go back to normal. So, are you getting 503 in integrated mode? Don’t forget to check the .NET version used by the application pool…it might not exist and that means 503!

Changing the action attribute of an HtmlForm

luisabreu — Thu, 26 Nov 2009 12:29:22 GMT

In these last days I’ve went back to ASP.NET world (server side) since I’m thinking in rewriting my ASP.NET book (which was written way back when ASP.NET 2.0 was released and which got a slight updated for .NET 3.5). One of the things I’ve noticed is that now we can change the action attribute of a form and it sticks! According to my investigations, this behavior was changed with the release of .NET 3.5.

Now, you might be thinking on why you’d want to use this attribute…it’s specially cool when you’re using friendly urls (remember: in the past, we didn’t had any url routing engines). Suppose you’re using the old friendly urls introduced by ASP.NET 2.0:

Now, the problem with pre-3.5 releases was that you couldn’t set the Action property and you’d end up getting the Activites.aspx in your browser’s location box. There were some hacks, but….they were simply hacks…With the 3.5 behavior change, those hacks can finally go back into the garbage bin! hurray! :)

Asking feedback for ASP.NET book

luisabreu — Tue, 24 Nov 2009 12:35:22 GMT

This is a post to my Portuguese readers (ie, for those guys and gals that have read my Portuguese books). I’m still preparing material for a possible ASP.NET 4.0 book and I would really appreciate some feedback on the previous editions (that is, if you read the book). What did you like? What didn’t you like? What would you like to see covered?

If you want, you can put your comments in Portuguese. Thanks for your help.

Crash dumps, ASP.NET and VS 2010

luisabreu — Fri, 06 Nov 2009 22:21:25 GMT

Pretty cool stuff!

Rick’s tip on ASP.NET client IDs + JQuery

luisabreu — Thu, 15 Oct 2009 13:55:08 GMT

Rick Strahl has an interesting post on how you might use JQuery’s powerful selector syntax to get a reference to an ASP.NET control placed inside a naming container. Pretty cool stuff :)

Dave Reed on MS AJAX 4 preview 5

luisabreu — Sun, 13 Sep 2009 21:43:24 GMT

Another excellent post by Dave Reed on a topic which I shall begin looking at in depth next week.

Has ASP.NET really left the track?

luisabreu — Mon, 24 Aug 2009 11:12:28 GMT

Hannes Preishuber has a post which asks if ASP.NET has left the track? It seems like Hannes is bashing the team for not improving the platform since the 2.0 release. I agree with this idea, though not with the specifics. In fact, in all the web apps I’ve worked until now, I’ve only used a couple of ASP.NET server controls. I’ve found most of them useless since I’ve ended up needing much more control over the generated HTML.

In fact, I’m not sure if I’d want the team to waste more time with ineffective controls. I’d really prefer that they would update the core infrastructure instead. For instance, my friend Paulo has already made several useful suggestions on connect which are way more important than getting more controls…

MVC Action filter project on Codeplex

luisabreu — Tue, 28 Apr 2009 09:46:29 GMT

Roni Schuetz informed me of a new Codeplex project he created for building a common library of ASP.NET MVC action filters. If you’re into MVC and you’d like to contribute, then check it out.

The MVC framework: the ActionLink control

luisabreu — Mon, 13 Apr 2009 20:43:21 GMT

Ok, so today I’ve finally updated my local copy of the MVC source code (which I’m doing through my preferred SVN client) and lo-and-behold: new stuff to talk about in the MVC futures source code! Today we’re going to talk about the ActionLink control.

As you might expect (from the name), this is a really simple control which extends the base MvcControl. Currently, it exposes the following properties:

ActionName: lets you pass the action name that should be used for rendering the link;
ControllerName: lets you set the name of the controller. Used for influencing the generated url;
RouteName: as you’ve probably guessed, you can use this to generate a link by using its name;
Values: lets you pass a dictionary for setting the route’s dictionary values;
Text: used for setting the text that is generated for the link.

If you’re used to using the Html.ActionLink helper, then there really shouldn’t be anything new in here. Anyway, here’s an example of how you can use this new control in your page:

<mvc:actionlink runat="server"
ActionName="About"
Text="Go to about" />

Unlike the other controls, the name property isn’t really used internally to get any info from the view data dictionary. You’re probably wondering how you can fill the Values property. Nothing better than a quick example…the next snippet creates a link to the Index action and sets its id property (I’m using the default routes you get when you create a new MVC app):

<mvc:actionlink runat="server" ActionName="Index" Text="Go to about" name="message">
<Values id="1" />
</mvc:actionlink>

This ends up generating the following HTML:

<a name="message" href="/MvcRTM/home/Index/1">Go to about</a>

If you had more parameters, you could simply add them as attributes to the Value element. And that’s it for today. Stay tuned for more on the MVC framework.

The MVC framework: the AcceptAjaxAttribute

luisabreu — Wed, 08 Apr 2009 23:01:50 GMT

There might be some scenarios where you have methods that should only be invoked for AJAX requests. In those cases, you can use the AcceptAjaxAttribute to decorate those methods. This is an ActionMethodSelectorAttribute which overrides the IsValidForRequest and delegates all its work to the Request.IsAjaxRequest extension method.

When you’re not in an AJAX request, the IsAjaxRequest method returns false and you end up getting a 404 for that call. It’s really a simple attribute and you might want to recall how ActionMethodSelectorAttributes interact with the remaining elements of the platform.

And that’s all there is to say about this attribute. Stay tuned for more on the MVC framework.

The MVC framework: setting a timeout

luisabreu — Tue, 07 Apr 2009 20:58:11 GMT

In the last posts, we’ve taken a look at how we can add asynchronous action to a controller. Today, we’re going to dig a little deeper and see how we can specify a timeout that limits the maximum amount of time that the asynchronous operations can take to complete.

By default, you inherit a default timeout: all actions must complete under 30 seconds (as you can see, if you peek into the AsyncManager class). You can specify the timeout in two ways: by interacting directly with the AsyncManager’s Timeout property or by using one of the existing timeout attributes.

If you want to use an attribute, then you can simply decorate a method (or a controller class) with the AsyncTimeoutAttribute. This is an action filter attribute which receives an integer that defines the valid timeout for the current asynchronous request. If you don’t want to limit the asynchronously execution in time, then you can simply pass Timeout.Infinite(–1) to the constructor. Alternatively, you can also annotate the method/controller with the NoAsyncTimeoutAttribute (this attribute expands the previous one and passes Timeout.Infinite to its constructor).

And that’s all for today. Keep tuned for more on the MVC framework.

The MVC framework: the RequireSslAttribute

luisabreu — Mon, 06 Apr 2009 21:00:11 GMT

The RequireSslAttribute is a filter attribute which you can apply to a class or method and which is responsible for overriding the OnAuthorization method and seeing if the current request is being done over SSL. The filter exposes a single property, called Redirect.

When it detects that the current request is not under SSL, it checks the Redirect property: if it’s set to true, then it will build an https url based on the current request and redirect the user to that new url; if the Redirect property is set to false, then it will simply throw an exception.

And that’s all there is to know about this attribute. Keep tuned for more on the MVC framework.

The MVC framework: the “delegate” pattern for asynchronous actions

luisabreu — Sun, 05 Apr 2009 21:13:44 GMT

This is the last post in the asynchronous action pattern series. In this post, we’re going to present the (so called) “delegate” pattern. This is really similar to the “event” pattern. The difference is that, in this case, we return a parameterless delegate from our begin method which will be called when all the asynchronous operations end.

To illustrate this pattern, we’re going to update the previous example. Here’s the final code:

public Func<ActionResult> GetHtml(String url) {
var req = WebRequest.Create(url);
req.Method = "GET";
AsyncManager.RegisterTask(cb => req.BeginGetResponse(cb, null),
     ar => {
               var response = req.EndGetResponse(ar);
               using (var reader =
                      new StreamReader(response.GetResponseStream())) {
                  ViewData["contents"] = reader.ReadToEnd();
                }
              }
            );

return () => View(“Index”);
}

When compared with the “event” pattern, you can quickly see that:

the begin method returns a parameterless delegate which will be called when all the asynchronous operations end;
since we can’t pass any parameters to our custom callback method, we write the HTML directly to the ViewData dictionary;
we use a Lambda expression since the view we’re rendering doesn’t have the same name as the action method (if that was the case, we could simply return a reference to the View method, ie, we could simply write return View;).

And that’s all for today. More about the MVC framework on the next posts. Keep tuned!

The MVC framework: simplifying the “event” pattern

luisabreu — Sun, 05 Apr 2009 21:01:49 GMT

In the previous post, we’ve taken a look at the “event” pattern. In this post, we’re going to see how we can simplify the needed code for using this pattern. The AsyncManager exposes a RegisterTask method which simplifies the needed code when we decide to use this pattern. We’ll improve the previous example by using this method. Here’s the code:

public void GetHtml(String url) {
var req = WebRequest.Create(url);
req.Method = "GET";
AsyncManager.RegisterTask(cb => req.BeginGetResponse(cb, null),
    ar => {
               var response = req.EndGetResponse(ar);
               using (var reader =
                         new StreamReader(response.GetResponseStream())) {
                  AsyncManager.Parameters["contents"] = reader.ReadToEnd();
               }
             }
            );

}

public ActionResult GetHtmlCompleted(String contents) {
ViewData["contents"] = contents;
return View("Index");
}

As you can see, the code is really similar to the one we’ve shown in the other post. The main difference is that with this helper method you’ll only need to worry with setting up the asynchronous action.

And that’s all for today. On the next post, we’ll talk about the latest option for having asynchronous actions in MVC controllers.

The MVC framework: the “event” pattern

luisabreu — Sun, 05 Apr 2009 20:37:41 GMT

Today we’re going to keep looking at the MVC framework and we’ll see how we can use the “event” pattern for invoking an action asynchronously. This pattern is really simple. You start by adding two methods: the first is responsible for kicking off the asynchronous processing and the second will be called when all the asynchronous actions complete (as you’ll see, with this approach you can start several asynchronous actions). The ending method’s name should follow a specific convention: it must end with the word Completed (where XXX is the name of the action method that is exposed by your controller) and it should return the ActionResult object responsible for kicking off the view rendering phase.

When you opt for this approach, you’ll have to notify the framework whenever you start an asynchronous task (and you also need to signal its end). In practice, this means that you’ll have to increment the AsyncManager’s OutsandingOperations property whenever you start an asynchronous action. And then you’ll also have to decrement this property when that async operation is completes. Internally, this property delegates to a counter and when that counter reaches 0, the platform will automatically invoke your XXXCompleted method.

Your XXXCompleted method might also receive parameters that are automatically fed with the values that might have been added to the AsyncManager’s Parameters property. In practice, when the platform invokes the XXXCompleted method, it will try to match the expected XXXCompleted parameters with values that might exists on the AsyncManager’s Parameters property. Those parameters which don’t exist in that Parameters property get their default value (default(T)).

The restrictions presented for the IAsyncResult pattern applies to this option too. That means that filters must be applied to the begin method (and not to the end method) and that the end method must match the real method name (instead of an eventual alias name that might have been applied to that method). Enough theory…it’s time to show some code. We’re going to reuse the previous example and change it so that we apply this pattern:

public void GetHtml(String url) {
var req = WebRequest.Create(url);
req.Method = "GET";
AsyncManager.OutstandingOperations.Increment();
req.BeginGetResponse(
                (ar) =>
                {
                    var response = req.EndGetResponse(ar);
                    using (var reader = new StreamReader(response.GetResponseStream())) {
                        AsyncManager.Parameters["contents"] = reader.ReadToEnd();
                    }
                    AsyncManager.OutstandingOperations.Decrement();
                },
                        null);
}