A quake of magnitude 6.8 hit the north-west coast of Japan this morning at 10:13h. I felt it, and it felt stronger than both previous quakes I've felt, which is something considering the epicentre was five times further away than the previous times (some 250km). The JMA seismic intensity of the quake was 6 at the epicentre (on a scale that goes to 7), and 2 over here.
This image, taken from the Japan Meteorological Agency's website, shows how the quake was felt in most of central Japan:
No damage was done over here, but in the north-west there were numerous injerous and MSNBC even reports two deaths.
Yikes!
A long time ago, after Visual Studio 2005 had just been released, I created the Visual Basic 2005 XML Comment Checker. This application aimed to fix the fact that the VB compiler, which now for the first time supported XML comments, did not warn you if you left publicly visible members uncommented.
I have now rewritten and extended this application to provide far more extensive checks, making it useful for C# programmers as well as VB programmers. The application is geared towards making sure your comments are up to scratch if you intend to build documentation using Microsoft Sandcastle. It checks whether required sections are present, whether parameters, generic arguments, return values and exceptions are properly documented, and it checks for certain keywords that Sandcastle allows to be put in a <see langword="..." /> element to automatically customize them to the current documentation language.
Best of all, it's fully configurable, though the CommentChecker.exe.config file and the command line arguments.
I just got back (well, actually I got back a while ago but I've been downstairs so I just got back in my room) and I thought I'd drop a quick note about today before going to sleep.
Today I had two major events: the TOEFL test and the Japan Philharmonic concert.
About the TOEFL I can be brief. It was long, it was boring, but I think it went well. I was finished well ahead of everyone else and fortunately they let you leave immediately. It still took me nearly three hours. No surprises here though. I'll get the result in fifteen days, or so I've been told.
Then the concert. As I said previously, this was the first time I've been to a classical performance. I can tell you though, it will not be the last. It was amazing! My seat was on the third floor almost entirely in the back, but I still had a very good view (the way the hall was constructed I don't think there were any really bad seats).
They played two pieces, both by Rachmaninov: Piano Concerto no. 3, and Symphony no. 2, in that order. The first is a favourite piece of mine, and this was an excellent performance. The pianist, Koyama Michie (Japanese name order, so Koyama is her last name), is my new hero. She put such energy, such zest into this piece, it was almost like she was performing a play behind her piano at times. She also made it look and sound so effortless, and that's saying something since Rachmaninov's piano work is the most complicated I know. It was very obvious she enjoyed the piece a lot, and that the audience enjoyed it a lot as well. When they started the final parts of the third movement, nearing the end, I was hoping they'd reveal a previously unknown fourth movement or something, I didn't want her to stop! But after 45 minutes it was over, and followed by a well deserved round of applause that lasted nearly 10 minutes. She came back on stage five times because people just wouldn't stop applauding. :)
I've got several different performances of this Piano Concert on my computer; this is now my favourite one (ok, so I'm biased cause I saw it live, who cares :P )
Then there was a fifteen minute intermission, followed by the Symphony No. 2. They played the 60 minute symphony in its entirety (it is often shortened). It was definitely very good, but Rachmaninov without piano is like a café without beer. Nothing bad about their performance, I just like the first piece better than this one. Still, I enjoyed it a lot.
Random notes:
There's a few things for your application in Windows Vista that you can control using a manifest. Perhaps the most well-known use for manifests is to specify the use of the comctl32.dll version 6, which is needed to use visual styles with your application. I'm not talking about this though, as this has been the case since XP, and there's no problem here with .Net since you can (and probably do) use Application.EnableVisualStyles() instead of a manifest.
Vista also offers some other stuff which you can control with manifests: requested execution level and high-DPI compatibility (aka DPI awareness).
The first you'll probably know: with UAC enabled, applications running on Vista don't get admin privileges by default, even if the current user is a member of the Administrators group (a good post about how this actually works can be found here). If you do need admin privileges, the application must be elevated. You can do this manually by right-clicking the application executable or shortcut and choosing "Run as administrator". Additionally, Vista uses some heuristics to automatically prompt for elevation for some apps.
But the recommended approach to doing this is by specifying the "requestedExecutionLevel" attribute in your application's manifest. You can use the "requireAdministrator" value to force elevation, but even if you don't need elevation it has benefits to use a manifest (specifying "asInvoker" to indicate you don't need anything special in this case). If you do this, you're sure that Vista's heuristics will never accidentally elevate your application when it doesn't need to be. Additionally, using a manifest will disable file and registry virtualization (a technique that allows badly behaved applications to think they can write to protected locations such as Program Files or HKEY_LOCAL_MACHINE, when in fact they can't; the writes are redirected to a virtualized location). Disabling virtualization helps enforce that your app behaves properly (since writes to those locations will now actually fail instead of be redirected) and makes sure it behaves consistently on x64; a .Net 2.0 application (compiled with the default "Any CPU" setting) when run under an x64 version of Windows will run as a native x64 application, and x64 processes never use virtualization.
The second, less well-known thing you can do with manifests in Vista is mark your application DPI aware. There are two ways to do this: by using the SetProcessDPIAware() function in the Win32 API, or by using a manifest. In my experience, the former method will break .Net's automatic scaling in some circumstances, no matter how early you call the function. The manifest approach doesn't have this problem. If your application is not marked DPI aware, it will be scaled by the Desktop Window Manager under non-standard DPI values, leading to reduced image quality (most notably, fuzzy text). Of course, only mark your application as DPI aware when it actually is DPI aware: be sure to test your application with different DPI settings!
A manifest that controls these two settings is shown below:
<?xml version="1.0" encoding="UTF-8"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <asmv2:trustInfo xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"> <asmv2:security> <asmv2:requestedPrivileges> <asmv2:requestedExecutionLevel level="asInvoker" /> </asmv2:requestedPrivileges> </asmv2:security> </asmv2:trustInfo> <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>
Now there's two ways you can include this manifest: as an external file named "YourExecutable.exe.manifest" or by embedding it into your executable. I vastly prefer the latter method since it eases deployment.
This is where it gets tricky (and also .Net specific; everything I've said so far applies to both native and .Net apps). Where Visual C++ automatically embeds manifests in executables, the C# and VB compilers do not offer this possibility. Fortunately, we can embed the manifest ourselves, using mt.exe (which is shipped with Visual Studio, and also with the Windows SDK):
mt.exe -manifest YourExecutable.exe.manifest -outputresource:YourExecutable.exe;#1
Looks simple enough. But wait! If the assembly was strong named, embedding the manifest invalidates the hash and thus breaks the executable (the latest version of mt.exe will warn you of this). The solution is to re-sign with sn.exe (comes with the .Net Framework SDK):
sn.exe -Ra YourExecutable.exe YourStrongNameKey.snk
Now wouldn't it be nice if this could be done automatically? Fortunately, it can, using build events. Build events can be found in the project properties in Visual Studio. For C# projects, it's a separate tab in the list on the left ("Build Events"). For VB projects, use the "Build Events" button at the bottom of the "Compile" tab. Set the post-build event command line to the following:
"$(DevEnvDir)..\..\VC\bin\mt.exe" -nologo -manifest "$(ProjectDir)app.manifest" -outputresource:"$(TargetPath);#1"
"$(DevEnvDir)..\..\sdk\v2.0\Bin\sn.exe" -q -Ra "$(TargetPath)" "$(ProjectDir)strongnamekey.snk"
You may need to adjust the paths of mt.exe and sn.exe depending on your Visual Studio installation. You will also need to modify the name of the strong name key file and manifest file.
There's one thing left. If you use the latest version of mt.exe, it will now perpetually warn you about the need to re-sign your assembly, which Visual Studio picks up on and shows in the Error List. To prevent that, check the "Delay sign only" box on the "Signing" tab of the project settings. Now your assembly will not actually be signed when mt.exe is run, so there's no warning. Sn.exe will correctly sign it afterwards.
It's official: I've been spoiled by the niceties of .Net. In yesterday's IXMLHTTPRequest example, I made a very stupid mistake.
What I did is a mistake that every COM programmer should be aware of: I created a circular reference. Since COM is reference counted, circular references create memory leaks. For those who're not familiar with this particular problem (perhaps because they've never used a reference counted system), here's what happens: when object A is created, its reference count is 1. A creates object B and holds a reference to it; its reference count is also 1. B takes a reference back to A, so its reference count becomes 2. Now the original creator of A is done with it, and releases it: the count for A is now one. But because B still holds a reference to A, its count doesn't reach zero until B is destroyed. But B will not be destroyed until its own count reaches zero, which won't happen until A is destroyed. Neither A nor B ever gets destroyed, so you get a memory leak.
In my case, the event sink object held a reference to the IXMLHTTPRequest, which held a reference to the event sink. In my sample, this wasn't much of a problem since the objects would get forcably released when CoUninitialize was called, which happened only a few nanoseconds after we were done with the objects. But in a real application, this can be a problem.
The solution is fortunately very easy: cheat with the reference count. By having the event sink not call AddRef on the request, the problem disappears. And since we can ensure that the event sink object will never use request object after it's been freed, this is safe.
I've updated the sample code. In addition to this change, I've also made the reference counting of the event sink object thread safe, since it was being used on more than one thread.
Subscribe