So it probably took me 15 seconds to track down this error in my code, and those wasted seconds, while very minor, are exactly why I wish Visual Studio or ReSharper or some program would alert me to what I've mistakenly done. It is easy with some methods to throw away a return value without noticing.
If I am calling a method which has a return value I am ignoring, it might be nice if it made it a little more obvious I am doing so. Perhaps an underline with a note explaining that I am not processing a return value. Sure lots of people ignore return values all the time, but they really shouldn't be. The return value probably exists for a reason.
As an example assume you want to get a substring.
string myString = "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize";
myString.Substring(5,10);
Console.WriteLine(myString);
Looking at that code it is pretty easy to miss the fact that I am not doing anything with the return value. Right now the value written to the console is "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize". I am just ignoring the value that substring is returning. This means I am not actually doing anything. I am just printing out the original string. What I really should have written is this.
string myString = "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize";
myString = myString.Substring(5,10);
Console.WriteLine(myString);
It wouldn't be that difficult for a program to detect unused return values. I am already informed when I don't use variables. Since plenty of plug-ins for visual studio already read method signatures, one of them could easily detect that I am ignoring the return value of that method. Ah the little things. Not too big a deal, but kind of annoying since I executed my program once and had to look to see why my code didn't work as expected.
Maybe some program does mention this already, or maybe there is some setting I need to enable to do this. Please let me know if you know of one.
Earlier today I read a very interesting blog post from Steve Smith. I use FireBug for all of my debugging purposes in Firefox. I wish that IE had a tool as amazing as FireBug. Sadly, I know of none. I had a similar desire for Firefox, because I use Fiddler with IE. That I knew of it wasn't possible to use Fiddler with Firefox. That always annoyed me, because Fiddler is a powerful tool for analyzing HTTP traffic.
It seems Steve was under the same impression as I was. Luckily someone pointed out to him that Firefox can be manually configured to work with Fiddler. Check out Steve's blog post where he details how to configure Firefox to use Fiddler. Steve has some screen shots and details the steps pretty well.
Thank Steve for posting this!
Thank Ivo Evtimov for telling Steve about it!
Just in case you missed the blog post from Scott Guthrie yesterday, I will post this.
Scott Guthrie's MVC Beta Announcement
ASP.NET MVC Beta Download
One of my favorite little added bonuses of using IDEs is that I get a lot of helpers that generate code and files for me. If I call a method that doesn't exist I am able to have a stub of the method automatically generated. In the ASP.NET MVC beta they've added a new menu for adding views.
The Add View window it brings looks extremely useful. I look forward to using that to create my views. It handles strongly-typed views and MasterPage selection.
Overall it looks like a nice release.
For those of you who want to deploy using ASP.NET MVC keep in mind that Scott says this in his post.
Today's ASP.NET MVC Beta release comes with an explicit "go-live" license that allows you to deploy it in production environments. The previous preview releases also allowed go-live deployments, but did so by not denying permission to deploy as opposed to explicitly granting it (which was a common source of confusion). Today's release is clearer about this in the license.
Good day and enjoy ASP.NET MVC's newest release.
One thing I probably say too often when working on code with other people is, "That's a new error. We're making progress." I take a bit of crap from a coworker of mine because of this. He thinks it is quite funny that new error messages are what I consider to be progress. After tracking down a bug creating some exception, it is nice to get a different message. This is of course as long as the newly written code didn't create the new error message. The idea when I say this is that I have removed a roadblock and gotten to the next one.
Perhaps we can make some analogy here about a hurdle runner jumping over a hurdle only to get to another one. Someone might say that it is bad that he is at another hurdle, but I prefer to say that it is great because he has made progress and is closer to reaching the finish line. Maybe he has one hurdle left, maybe twenty. It doesn't matter really as long as he is closer to the goal.
So leave me alone about the new error message thing being progress..... Ed.
A while back, I was asked a question by one of the junior developers here at Lake Quincy Media. I had him working on a little feature on an ASP.NET site which could be easily handled using Session. "Where is session stored, on the server or the client?" he asked. As a quick response I said that it's stored on the server. He followed that by saying, "So it doesn't use a cookie?"
And that was all it took to set me on one of my usual lengthy explanations of how a piece of functionality actually works.
How is ASP.NET Session stored?
In ASP.NET, session data is stored on the server. It is stored in a per-user basis and maintained only for a limited period of time. Anyone who has used sessions knows that it is accessed during server-side code execution and is accessed using strings as keys. So we know that Session data is stored as key-value pairs. The following is basically how we access the session information. In this code I store a string in Session and pull it back out from session.
string name = "Brendan Enrick";
Session["fullName"] = name;
string nameFromSession = Session["fullName"] as string;
Pretty simple really. It is a nice way to store data for a user during this visit to the site.
How are users associated with their session?
In the default scenario for ASP.NET Session, cookies are used. No, the data is not stored in the cookie. When a Session is started on the site, the user is given a cookie (yummy cookie) which contains a unique identifier for accessing the session. While the user navigates around the site, the browser sends the cookie information to the server. This is what keeps the user associated with his session. Each time the server receives the cookie from the user so when your code requests data from session, it is pulling the data from the session associated with that user.
Can cookies be avoided?
Yes, it is possible to avoid using cookies. Session is able to run without cookies by setting a boolean property in the web.config file to true. The property is called cookieless and it is on sessionState. When session is not using cookies it instead places the SessionId in the url the user requests. Internal links on the site contain the unique session id so that the processing which occurs on the server is able to access the correct session values. I prefer not using this method because it just makes URLs all over the site look terrible.
How long are values saved in session?
By default the timeout for session in ASP.NET is 20 minutes. This means that the session will expire 20 minutes after the user last accessed the site, so as long as the user continues using the site it will not expire. If the user waits 25 minutes before clicking a link, the session will have expired. It is easy to adjust the length of time before sessions expire. In the web configuration file you can simply adjust the value for timeout on the sessionState element.
<sessionState cookieless="false" timeout="45" />
And this is why asking me questions can be a bit crazy. I'll first go on a lecture about the topic and then eventually I'll publish a blog post so I don't have to lecture again. Now if someone asks me that question I'll send him here.