A few people have asked me for a working web site with some of the code from my MasterPage: Tips, Tricks, and Traps article. This download is a web site based on the ASP.NET Personal Web Site Starter Kit and provides a number of the samples from the article.
Samples include a master page base class, and an HttpModule to assign the MasterPageFile property for .aspx web forms at runtime. There is an example of content page to master page interaction through a strongly typed Master property, and an example of master page to content page interaction via an event.
Joe Developer is working with a simple struct:
Joe's tech lead asked him to write a method that will return an array of 10,000 initialized points. Joe wrote following code.
The code doesn't create any runtime errors, but Joe is worried because his tech lead looked at the code and frowned. What could provoke such a reaction?
Hint: Joe's lead is a performance nut.
There is a queuing infrastructure in Windows Workflow that facilitates communications between workflows and the outside world. Event related activities, like the HandleExternalEvent and Delay activities, provide a formalized layer of abstraction over this queuing infrastructure. You might never need to know that a queuing service exists if you can get 100% of the job done with components from the base activity library.
If you need more flexible messaging, or like Harry, want to work with a low level API, you can use the queuing service to create queues and en-queue messages for your own purposes. Before jumping in, it's worthwhile to study how the built-in activities make use of workflow queues, particularly workflow queue names.
If we look at the correlated local service example in the Windows SDK, we'll find a Parallel activity with two sequences inside. Both sequences call a CreateTask method and expect a TaskCompleted event to arrive. A local service we've implemented has to raise this TaskCompleted event, but the event isn't delivered directly to the running workflow. Instead, the workflow runtime catches the event. The workflow instance might be unloaded from memory and living as a serialized blob in a database table. The runtime will reload the proper workflow and deliver the event.
If there are multiple workflow instances active, it's easy for the runtime to find the right instance because of the InstanceId property on all incoming event arguments (local service communications might define event arguments that derive from the ExternalDataEventArgs class).
But how does the workflow know what activity is waiting for the event? This isn't hard if there is only one activity waiting for an event, but in this sample we have two activities both waiting for the same event from the same service.The secret is in the workflow queue names the individual activities create to wait for the events. If we use GetWorkflowQueueData on the workflow instance, we can inspect the queue names. A queue name in the this SDK sample will look like the following:Message Properties
What we see is that the workflow queue "name" actually contains all of the information the runtime needs to deliver events to their proper destination. The name includes the interface and event name, as well as correlation values when the associated activities have correlation tokens.
Queue names in windows Workflow are more than just friendly identifiers. As Harry pointed out, they implement IComparable and are actually a key piece to how Windows Workflow works with data exchange services.
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:
Let's take these one at a time.
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.
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.
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.
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. .
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.
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.
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.
Back in the macro explorer, you should be able to right-click the macro to execute it.