Let’s say you want to add an AssemblyVersionAttribute to a web project. The usual practice is to add a file to the project with the name AssemblyInfo.cs. The AssemblyInfo.cs file will live in the App_Code folder, because that is the only location the new web project model will allow stand-alone code files. The contents might look like:

Next, a web form to display the version number:

The above web form will happily display the version number as 0.0.0.0 because App_Code compiles into a different assembly than the web form. The App_Code assembly will have the version number we need. The ASP.NET compiler doesn’t assign a version number to the dynamically generated assemblies for web forms. This is true in 1.1, too, it’s just that we usually asked for the version number from a code-behind file, and all the code-behind files compiled together into a single assembly.

There are a couple approaches to getting the version number from the AssemblyVersionAttribute in App_Code. One approach would be to substitute the following in our earlier code:

I think an even better approach is to use the Web Deployment Project, which can merge all assemblies into a single assembly, and copy assembly level attributes over, too. If you are using the newer Web Application Project model, then any code in a code-behind file will be able to see the version in an AssemblyVersion source file.

Smart tags appear in Visual Studio when the IDE thinks it can help you make quick work of a common task. I use the feature quite a bit, particularly for rename refactoring, implementing interfaces, adding using declarations, and generating method stubs.

One way to open a smart tag is to hover the mouse over a 1 pixel hotspot that lives somewhere in the vicinity of the smart tag indicator.

Fortunately, Visual Studio assigns the same keyboard shortcut to open a smart tag as Office apps: Shift+Alt+F10. The keyboard is a better approach, but Shift+Alt+F10 is one of those piano virtuoso maneuvers. Splay your fingers, point your wrists outward, and attack the keyboard with a flourish. Actually, it’s not a bad exercise to avoid carpal tunnel. On my laptop, I sometimes open the smart tag, I sometimes turn off the LCD.

When I went into the Customize menu to assign a new keyboard shortcut, I found there is already an alternate shortcut assigned: Ctrl+. (see Tools -> Customize -> Keyboard -> and show commands for View.ShowSmartTag).

Ctrl+. is a better shortcut to open a smart tag, but I’m still waiting for the day when I can blink at the screen and get a reaction.

I’ve pounded on Visual Studio 2005 a lot this month. Overall, I’ve been happy with the IDE, and find myself more productive.

Stability: Good
Frans has been able to crash the IDE with a brace and with a mouse click. I’m happy I have not found any major problems. I did have a spectacular crash one afternoon with the old “Unexpected error encountered. It is recommended that you restart the application as soon as possible” message (HRESULT: 0x80131527 File: vsee\internal\vscomptr.inl Line: 473). Restarting was not an option as the message kept coming back. I had to kill the IDE, but didn’t lose any work.

One area I’ve found to be extremely delicate is the scripting engine integration. I have a few macros I use with Visual Studio. One of the macros uses the clipboard API. I’ve seen the macro crash vsmsvr.exe with a call to GetClipboard on several occasions. When vsmsvr.exe crashes unexpectedly, I can never get devenv.exe to accept input focus, and have to kill the IDE. The Windows clipboard seems fragile when I have both a remote desktop and virtual PC running.

Performance: Fair
Performance can drag at times. Refactoring operations on large projects are slow. My devenv.exe process has been hovering around 250MB of VM. Source control operations can also be slow. View pending check-ins can take forever when it needs to scan thousands of files, and simple add and delete operations often seem to hang the IDE for a few seconds at times.

Visual Studio 2005 ships with a few handy visualizers for debugging. A visualizer presents a tailored view of an object, which is useful when an object is too complex to fit in a watch window or data tip. Custom visualizers can plug into Visual Studio, see “How To: Write a Visualizer” as a starting point.

I’ve packaged up a couple custom visualizers I’ve used recently into a project: WebVisualizers.zip. The ControlTree visualizer shows the hierarchical relationship of web controls, starting with the visualized control at the top. For instance, if you hover over a this reference inside a web form class, and click the magnifying glass that appears, you’ll see all the controls on a form.

Controls implementing the INamingContainer interface appear in red. This visualizer was helpful in tracking down a misuse of FindControl. The second visualizer in the project will display an HttpCookieCollection in a grid view.

To install the a visualizer you have to build the source code. You can build with  Visual Studio, or from the command line “msbuild OdeToCode.WebVisualizers.csproj”, assuming msbuild.exe is in the path. Copy the .dll from underneath the bin directory into “MyDocuments\Visual Studio 2005\Visualizers”. VS.NET will automatically load the assembly when debugging, and inspect the metadata inside to know what types to visualize. Note: custom visualizers won't load for a web site running at less than full trust.

These Visualizers here are relatively simple. Brett Johnson wrote a visualizer for the ASP.NET cache, and a wicked-cool visualizer to render controls.

A colleague once told me configuration management is to software development what oxygen is to a human. When the proper CM practices are in place, no one notices. When configuration management is non-existent or lacking, the development process chokes. The trick, as always, is to find the right level of process and auditing for the development task at hand.

Adam Barr gives us a look at what happens on the extreme end of the spectrum with the release of new Monad bits. Not only is Microsoft big (debug and release builds have to run a gauntlet of tests on 3 platforms x 3 architectures), but they are also understandably paranoid (you need three employees with cardkeys and PIN numbers to have an independent team sign bits with the Microsoft private key). Read the rest of the process in Adam’s post “Putting Out A New Release of Monad”.

One of the tools in the process that caught my eye was APIScan. APIScan ensures a product uses only publicly documented Windows APIs. This sounds crazy unless you remember the hidden API fiasco during the bubble years. The hidden APIs became a part of the anti-trust case, which added legal complexities to Microsoft’s CM process. A quick search finds this report on the website of the U.S. Department Of Justice. The report is an update on Microsoft’s compliance in the U.S. v Microsoft case, and mentions APIScan as a tool “to identify all APIs that must be disclosed in accordance with Section III.D”.

Aside: the report also documents that the Platform and Services division at MS offers quarterly ‘anti-trust’ training. Wow – that’s a triple shot espresso mocha session, if ever I heard one.

Next time I have to tweak a script for the build engine, I’ll remember things aren’t all that bad.

The ASP.NET IIS Registration Tool (Aspnet_regiis.exe) can encrypt and decrypt sections of web.config. There is no special code required in an application, as ASP.NET 2.0 will magically decrypt sections at runtime.

The tool and runtime can also work together to encrypt and decrypt custom configuration sections. So if I have the following in web.config:

All I need to do from the command line, is:

It’s easier than a double pirouette…

I received a nice package in the yesterday. The package was from Judy Calla, who was an organizer at the recent Central Penn Code Camp. The package contained 30 session evaluations with feedback on my presentation.

This was the first Code Camp that sent evaluations back to me. I wish more Code Camps could follow up with feedback to presenters. I’m always looking at ways to improve, be it in software, speaking, writing, hitting balls, or home improvement projects with power tools (also known as destruction of property, to those who witness the debacle).

The first place I looked on each evaluation was the “What needs improvement” line. Three people thought I could slow down the presentation pace. Pacing is one area I need to improve. I also need to break the habit of using shortcut keys when doing a demo. From first hand experience I can tell you shortcuts make a demo hard to follow.

Two people dinged me for “demo setup”. This was the second time Virtual PC bit me in a presentation. I’m thinking about using a dual boot setup instead of Virtual PC for future presentations, although these problems only happen when in front of a crowd.