The MonthCalendar control's BoldedDates functionality doesn't appear to work properly on Windows Vista. The dates added to any of the BoldedDates, MonthlyBoldedDates and AnnuallyBoldedDates collections are rendered just the same as those not added to any of the collections. The same code works just fine on Windows XP and causes those dates to be rendered bold. The only workaround i've managed to find is disabling visual styles in the application, i.e. commenting out the first line in the Program.Main() method of a new Windows Application:

Application.EnableVisualStyles();

The Xbox 360 Dashboard update released on 4th December 2007 added support for playing DivX and XviD videos natively, i.e. without installing Transcode 360 for Windows Media Center. Unfortunatelly this only works for media played directly from the dashboard and not within Media Center Extender. Since I didn't want to copy my videos to CDs, DVDs or other external devices, the only thing left to do was to setup Windows Media Player media sharing which I never had to use before.

This turned out to be more difficult than I expected - the reason being that the media I wanted to share wasn't stored locally but on a separate file server. By default such media is not shared and there are few steps one has to follow to make this work, as thoroughly explained here:

• Enable remote content sharing by adding the following entry into the registry:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Preferences\HME]
  "EnableRemoteContentSharing"=dword:00000001
• Grant anonymous users access to the shared folders on the file server by adding the read permission on the folder and on the share to the ANONYMOUS LOGON user
• Modify the file server's group policy to allow anonymous access to the selected shares by listing them in the Network access: Shares that can be accessed anonymously policy in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options branch of the group policy tree (just run gpedit.msc to start the Group Policy Object Editor)

In my opinion RSACryptoServiceProvider class is seriously under-documented in MSDN. Since there is also no abundance of examples on the web, I spent more time than I should figuring out how to use it correctly. For future reference I'm listing below the solution to two problems I had.

The maximum byte array length for encrypting without OAEP padding is Modulus size - 11 which is written somewhere in the Encrypt() method documentation. If you pass it a larger array it will return a not so informative Unspecified error. To encrypt a larger chunk of data you have to split it in smaller parts, encrypt them individually and concatenate them back together. You have to do the same when decrypting the data, with the only difference that each part has the size of Modulus in stead of Modulus - 11. To get the modulus size you can use the following piece of code (rsa is an instance of RSACryptoServiceProvider):

RSAParameters rsaParams = rsa.ExportParameters(false);
int modulusSize = rsaParams.Modulus.Length;

Each time you instantiate RSACryptoServiceProvider it generates a new pair of keys. If you want to use existing ones, you can import them by calling:

rsa.FromXmlString(key);

The key parameter is a string with the XML representation of the keys. You can get it by calling the ToXmlString() method once and storing its results. It's only parameter specifies whether to also export the private key. I guess I don't have to remind you that you need the private key only for decryption and that you should always keep it private for the encryption to make any sense at all.

Is the code below correct? Will inputString and outputString be equal?

string inputString = "The text to compress and decompress";
byte[] inputArray = Encoding.UTF8.GetBytes(inputString);

MemoryStream stream = new MemoryStream();
DeflateStream compressionStream =
    new DeflateStream(stream, CompressionMode.Compress);
compressionStream.Write(inputArray, 0, inputArray.Length);
compressionStream.Flush();

stream.Position = 0;

DeflateStream decompressionStream =
    new DeflateStream(stream, CompressionMode.Decompress);
byte[] outputArray = new byte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length);
string outputString = Encoding.UTF8.GetString(outputArray);

Console.WriteLine(outputString == inputString);
Console.ReadLine();

As it turns out, they won't. The reason for it being that compressionStream.Close() was not called before reading from stream started. Calling compressionStream.Flush() is not enough in this case. I haven't managed to find this documented anywhere but the example in the DeflateStream documentation does it correctly. You can find the fixed code below. Notice the additional last parameter in the first call to the DeflateStream constructor. Without it stream will also be closed when compressionStream gets closed.

string inputString = "The text to compress and decompress";
byte[] inputArray = Encoding.UTF8.GetBytes(inputString);

MemoryStream stream = new MemoryStream();
DeflateStream compressionStream =
    new DeflateStream(stream, CompressionMode.Compress, true);
compressionStream.Write(inputArray, 0, inputArray.Length);
compressionStream.Close();

stream.Position = 0;

DeflateStream decompressionStream =
    new DeflateStream(stream, CompressionMode.Decompress);
byte[] outputArray = new byte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length);
string outputString = Encoding.UTF8.GetString(outputArray);

Console.WriteLine(outputString == inputString);
Console.ReadLine();

Thanks once again to my coworker for suggesting this when I was already running out of ideas.

Not so long ago I've been called to my boss's office to prevent him losing unsaved work in a PowerPoint presentation. It turned out that when he tried to save the file to a new location the message box with the overwrite warning for some reason didn't render completely and it was impossible to close it. As it turned out at the end I could have just killed the application and restart it, since the AutoRecover feature kicked in and offered a version of the file with all changes applied.

But just to be on the save side I wanted to copy the AutoRecover files to a save location before actually killing the application. But unlike Word or Excel where the location of these files is set in the options, PowerPoint does not have such an option. After some googling I finally stumbled across a page, correctly stating that the files are stored in the %temp% folder and named ppt*.tmp. I decided to publish this info here just in case I need it again.