I spent the summer as a hermit. Here are some events where I'll be presenting over the next three months.

VSLive! Boston (Oct 24 - Oct 27). On Wednesday afternoon, I'll show you how to bend master pages to do your bidding. There is some great ASP.NET 2.0 content in this show with the likes of Fritz Onion, Miguel Castro, Chris Kinsman, and more.

VSLive! Dallas (Nov 14 - Nov 17). One presentation on master pages, and one presentation to help make sense of web site projects, web application projects, and web deployment projects.

Central Penn Code Camp (Dec 2). I'll probably do one talk on an ASP.NET topic, and one introduction to Windows Workflow.

CMAP User Group (Dec 5). Every December, the central Maryland user group has a tips and tricks show. Different presenters each take 20 minutes and show you tools and time saving techniques you'll find useful in everyday development. Free pizza and door prizes, too!

BaltoMSDN User Group (Dec 13). If you are in Baltimore or Northern Maryland, come out and support the newest user group in the area. Topic TBA.

One misunderstanding I often see is "if I make this member static it will be thread safe". I think this misconception arises because of the boilerplate MSDN documentation that will often say: "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

When a .NET framework class appears with the above documentation, it means a developer took the necessary precautions to make the static member thread safe. Perhaps they added a lock, or used some other synchronization mechanism to ensure thread safety. See: Statics and Thread Safety Part I and Part II.

Marking a class member static doesn't guarantee thread safety. It is up to you to make the member thread safe.

There is one exception to this rule. It's a special case where the static / Shared keyword will guarantee threading magic. Do you know what that is?

People often ask what the aspnet_compiler tool can do. The usual answer is "pre-compile an ASP.NET 2.0 web site". The follow up question is: "What good does that do me?". MSDN says the advantages to compilation in general are:

• Performance
• Security
• Interoperability
• Stability

Let's take these one at a time.

Performance

I say the performance benefits to pre-compiling a site are negligible. Pre-compilation does save some work, but ASP.NET applications in general are slow starters. Think about all the work that happens when the first request arrives. A process has to start. An AppDomain has to load. The cache is empty. The database connection pool is empty. Even if you've precompiled, the JIT compiler has to step in and create native code.

I'm not saying you shouldn't pre-compile a site to save some time. Just don’t' count on seeing a significant reduction in start up time for all applications.

Security

The MSDN article I linked to says "Compiled code is more difficult to reverse engineer than non-compiled source code…". Compilation makes the job more difficult, but all someone needs is the right tools. If you are trying to hide secrets in your source code, then encryption, not compilation, is the way to go. If you want to protect intellectual property then look for good obfuscation tools. Just remember you can't stop reverse engineering, you can only slow it down.

I don't think of pre-compilation as a security benefit, but if you pre-compile an ASP.NET application without the updateable option, you will lock down the application in production. Pre-compilation can strip out all the markup in template files, and no one can easily hand-tweak stuff outside of the configuration management process.

Interoperability

I never thought of interoperability as a benefit of compilation, per se. It seems interoperability between languages is a feature of the platform, not any compiler. I think the documentation is stretching this a bit.

Stability

ScottGu refers to using pre-compilation for "deep verification". A pre-compiled ASP.NET application is stable and verified in the sense that you won't see runtime errors because of syntax problems in markup. If someone checks in a malformed server control tag, you can catch the problem during the build with a compiler error, instead of finding out about the problem in test or production. Stability is arguably the greatest benefit of pre-compilation, and I recommend pre-compiling a web site for this reason alone. .

Summary

When I heard about pre-compilation in ASP.NET 2.0, my thoughts circled around startup performance. As it turns out, pre-compilation will save not only CPU cycles but test and development cycles as well. Pre-compilation is worth the effort, primarily because it requires so little work to setup.

If you want an interactive and user friendly interface for pre-compilation, check out Rick Strahl's ASP.NET 2.0 Compiler Utility.

Web Deployment Projects can do pre-compilation (and a whole lot more), using a standard MSBuild project file.

If you just want to add a quick pre-compilation step to your Team Foundation Server build, use the AspNetCompiler task in the AfterCompile override in TfsBuild.proj:

Last year I wrote a little macro to generate a web.sitemap file for ASP.NET 2.0. A few people have been asking about support for Web Application Projects, so I've updated the macro.

Download.

This macro walks through the directories of a web project and adds all the content pages to a ASP.NET 2.0 site map file. If you use URL re-writing or virtual path providers, it won't be able to see those URLs. Chances are you'll need to hand tweak the file afterwards as the macro isn't intelligent enough to devise a good title for each page, but it can save a lot of typing to get started.

To install:

1. Open the macro explorer (Alt+F8).
2. Right click a macro project and select "New Module…"
3. Name the new module SiteMapMacro
4. Right click the new module and select "Edit". Clear existing code.
5. Paste the code from the download into the new file.
6. In the Project Explorer, right click References and add a reference to System.Xml.dll. Close the editor.

Back in the macro explorer, you should be able to right-click the macro to execute it.

I wasn't paying attention when I typed:

mstsc /v:name.domain.net /console

Unfortunately, I was already sitting in front of the very machine I was trying to reach with terminal services. I took over the console, all right - the screen blacked out. I couldn't get Ctrl-Alt-Delete to provoke a response. If it wasn't for the lights on the case I'd have thought the computer died.

It takes 30 seconds or so for the un-credentialed new connection to timeout and return control to the real console.

It's a very long, worrying 30 seconds, though. I just wanted to share my anxiety.

Vivek points out some surprising behavior with master pages.

Let's say we want to disable ViewState for all pages by default. All we need is an entry in web.config:

When the ASP.NET runtime generates code for a web form, it will disable ViewState using generated code. The code in the Temporary ASP.NET Files directory for an .aspx will contain a snippet like the following:

At some point, we may run into a page that requires ViewState. Arguably, we could say that something on the page should be re-written to use ControlState (required) instead of ViewState (optional), but it's easy to override the default configuration on a page by page basis in the @ Page directive:

This works - the @ Page directive overrides web.config and EnableViewState=true appears in the generated code….

… but there is a catch.

From what I can tell - some of the same goo responsible for the parsing and code generation of .aspx files also parses and generates the code for .ascx, and .master files. This goo will read the web.config setting and place EnableViewState=false in the code generated for master pages (and user controls, too).

For ViewState to be available to a control, it's parent must have ViewState enabled. Since a master page injects itself as the direct child of the Page object, having ViewState disabled in the master page shuts off ViewState for everything inside the Page.

With ViewState effectively disabled, it appears as if the @ Page directive isn't overriding web.config. It turns out that the @ Page directive does work as we expect. What we don't expect is that the MasterPage would pick up a configuration settings from the <pages> section of web.config and kill ViewState. But should we? The documentation for the <pages> element says:

"Globally defines page-specific configuration settings, such as ASP.NET directives for pages and controls that are within the scope of the configuration file."

Perhaps ASP.NET is working as designed, but I'd say the behavior is not intuitive in this case.

The Web Client Software Factory dropped a new build yesterday. This is the first build I've downloaded. I spent about 30 minutes perusing the documentation and reference implementation, and I am shocked!.

My expectations were to open this package and find yet-another-data-access-layer-approach. Ho hum.

Instead, this factory positions itself to address leading issues in today's web development practices.

Some highlights:

• The reference implementation uses a model-view-presenter with controller (MVPC) pattern to maximize the testability of code, and centralize control flow and business logic.
• The docs explain how to implement MVPC using the canonical definition of test-driven development. Write your tests first. Red - green - refactor.
• The project uses "Page flow". Page flow models a user's path through a multi-page task using a Windows Workflow state machine and custom Page activities.

I plan to spend some more time with the factory and keep an eye on the weekly releases.