Zubair

I am always curious to know about what goes into building a terribly good software, the time, the energy, the focus, the commitment, the passion…….specially something which really impresses me or something I really like.

Read this excellent post from Scott Guthrie describing how tests are run under Microsoft for any upcoming product and specifically ASP.NET 2.0 and Visual Web Developer, for example here is an excerpt from his post.

“My team uses an internally built system we affectionately call “Maddog” to handle managing and running our tests. Post Whidbey my team will be looking to transition to a VSTS one, but for right now Maddog is the one we use.

My team currently has 4 labs where we keep approximately 1,200 machines that Maddog helps coordinate and keep busy. The machines vary in size and quality – with some being custom-built towers and others being rack-mounts. Here is a picture of what one row (there are many, many, many of them) in one of labs in building 42 looks like:
”

The magic happens when we use Maddog to help coordinate and use all these machines. A tester can use Maddog within their office to build a query of tests to run (selecting either a sub-node of feature areas – or doing a search for tests based on some other criteria), then pick what hardware and OS version the tests should run on, pick what language they should be run under (Arabic, German, Japanese, etc), what ASP.NET and Visual Studio build should be installed on the machine, and then how many machines it should be distributed over.

Maddog will then identify free machines in the lab, automatically format and re-image them with the appropriate operating system, install the right build on them, build and deploy the tests selected onto them, and then run the tests. When the run is over the tester can examine the results within Maddog, investigate all failures, publish the results (all through the Maddog system), and then release the machines for other Maddog runs. Published test results stay in the system forever (or until we delete them) – allowing test leads and my test manager to review them and make sure everything is getting covered. All this gets done without the tester ever having to leave their office.”

Now that’s awesome, read the post for some more insights that we would probably don’t know otherwise.

In his latest article on MSDN, Dino Esposito discusses when it is useful to have Cookieless sessions in your ASP.NET application such as:

“With cookieless sessions, you can now deploy stateful applications that work regardless of the user’s preferences about cookies. As of ASP.NET 1.x, though, cookies are still required to implement forms authentication. The good news is that in ASP.NET 2.0 forms authentication can optionally work in a cookieless fashion.”

and discusses when it can be a problem to use Cookieless sessions:

• “Connect to a Web site that uses cookieless sessions—for example, MapPoint—and get a map. At this point, the address is stored in the session state.
• Grab the URL up to the page name. Don’t include the query string but make sure the URL includes the session ID.
• Save the URL to a file and copy/send the file to another machine.
• On the second machine, open the file and paste the URL in a new instance of the browser.
• The same map shows up as long as the session timeout is still valid.
  
  With cookieless sessions, stealing session IDs is easier than ever. “

Read the complete article here

Found this excellent tool known as SW Explorer Automation (SWEA). SWEA creates an object model (automation interface) for any Web application running in Internet Explorer. The tool can be helpful in debugging and testing a data driven ASP.NET applications. It easily automates tedious form filling. The tool records the automation script and generates C# or VB.NET code from it.Dont know what I mean. Check out the online demo
Click here to view the website, Download Developer’s guide, Download API Reference

Nikhil Kothari (Lead Developer ASP.NET Team) has written a new Browser Helper Object (BHO) which displays it to the developer when an ASP.NET application is running in Debug Mode, aswel as the ability to View/Hide Trace Information and Show/Hide View State Information with a click of a button.

Here is an excerpt from his blog:

“…such as the ability to hide trace information from the page (useful if that interferes with your page layout), and view it in a separate window, as well as the ability to see view state in a decoded form. The latter is especially useful for control developers to analyze their view state and control state usage. I already spotted a couple of things we could potentially pack better in GridView.”

More Information, screenshots and download on Nikhil’s blog

The pressure cooker of The Code Room is back, this time coming from the Westfield Mall in Seattle. Four experts on Windows Embedded, Compact Framework, and ASP.NET are challenged with building a fully functioning kiosk that can be accessed from a Bluetooth phone application to search for products available in the mall and then use the phone to take a picture of the product and send it to the users MSN Spaces site.

Watch this 2nd Episode
First Episode