USNAF - Microsoft's National Architect Forum

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/usnaf__microsofts_national_architect_forum.htm]

I just got back from Microsoft's National Architect Forum in Vail, Colorado - and wow! To be at a conference with 200 top architects was humbling. There are several big things I saw:

1. Microsoft is really maturing on Enterprise Architecture and agile processes.
2. Paul Glen spoke (author of the great book Leading Geeks). A lot of good insight about how to manage geeks.
3. There's a lot of good architects out there.

Perhaps the easiest thing to describe was Paul's closing speech. He had several good points from his book:

• Geeks are different than other people because their productivity is based on thinking not behavior.
• Power is useless with geeks because power only controls behavior, but Geeks deliver productivity via thought.
• "Geekwork" is different than normal work. For example, in geekwork because technology moves so fast, the moment you step away from implementing code to become a manager, technology moves on. Therefore managers often know less about direct coding than the geeks they manage. In most other fields, managers know more than the people they manage.

Viewing the source of an Html File, even with the ContextMenu disabled

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/viewing_the_source_of_an_html_file_even_with_the_contextmenu.htm]

In IE, you can view the source of any file through either the context menu or tool bar. However, sometimes there are design reasons to disable or hide these. For example, you can prevent the content menu by putting this in the a script in the HTML body:

document.oncontextmenu=new Function("return false");

And you can hide toolbars by opening up a new window and passing in the appropriate options:

window.open(...);

However, even if a site does this, you can still view the source through the VS.Net debugger. Simply start debugging one of your own apps, then navigate to the target site in the address bar, and you'll see full source in the Script Explorer window.

ASP.Net 2.0 Callbacks: Using callbacks to create a rich Web UI

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/aspnet_20_callbacks_using_callbacks_to_create_a_rich_web_ui.htm]

I just had an article on ASP.Net 2.0 Callbacks published in .Net DJ. It provides a basic intro, and some more advanced uses like handling multiple callbacks and passing multiple data values.

Hashtables in JavaScript

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/hashtables_in_javascript.htm]

As a bit of trivia for the day, JavaScript can handle pseudo-hashtables, via the Array object. You can reference the item with its key, and enumerate through all the objects.

function DoHashTest()
{
  var h = new Array();
  h["aaa"] = "Aardvark";
  h["bbb"] = "Babboon";
 
  var s = "";
  //This won't work, length will be 0.
  for (var i = 0; i < h.length; i++)
  {
     s += h[i];
  }

  //Cycle through like a hash:
  for (var i in h)
  {
    s += i;
  }
}

MSBuild error MSB3073 "The batch file cannot be found"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/msbuild_error_msb3073_the_batch_file_cannot_be_found.htm]

We've migrated to MSTest, and are running tests through MSBuild. I came across an interesting issue (that seems like a bug).

Normally I would expect that if the test passes in Test Viewer (the UI), then it would also pass when I run it in MSTest from the command line, and it would still pass when I call it from MSBuild. However, I found this not always so.

One of my tests wrote out files to the temp directory, as generated by "System.IO.Path.GetTempPath()". I then cleaned up the test output by deleting the directory, and recreating it. This worked fine in both UI, and MSTest, but failed in MSBuild with the following error:

Run Configuration: Default Run Configuration
The batch file cannot be found.
C:\myProject\myBuild.msbuild(21,5): error MSB3073:

The command ""C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MsTest"
/testcontainer:C:\myTests.dll /resultsfile:myOutput\UnitTests.trx" exited with code 1.
Done building target "UnitTest" in project "myBuild.msbuild" -- FAILED.

By appending a sub directory to the temp directory, like "System.IO.Path.GetTempPath()" + "temp\", the tests all passed again. My guess is that MSBuild sent something to this output directory that my cleanup method was inadvertently deleting.

JavaScript Debugging in 2005

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/javascript_debugging_in_2005.htm]

I had written about JavaScript debugging in 2003 with the Running Documents Window. In 2005 they do things a little differently. Instead of the running documents window, there is the script explorer.

One immediate perk is that the script explorer has source code color-coded, whereas the running document window did not.

Check out Microsoft's Jerry Orman's blog to see how to debug in VS2005.

Pair and Triplet classes

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/pair_and_triplet_classes.htm]

There are some Framework classes out there that are useful, but infrequently used. In my experience, System.Web.UI.Pair and System.Web.UI.Triplet are two such examples. These provide basic utilities (like serialization) to store two or three related objects into single object. They have predictable members, for example Pair has a "First" and "Second" property that can be set either in the constructor or once instantiated.

They're simple classes, but are easy and helpful to use in web applications. Of course you could write your own container, but this saves you the step.