Todd Bleeker

Note To Self: Reading and Writing Plain Text Email Messages in Outlook 2007

Paul Schaeflein — Tue, 03 Nov 2009 04:31:25 GMT

For years now I've been reading and writing messages in Outlook using plain text email. I know it is old school and there is a lot of FUD surrounding it but I still think it is a best practice. At worst it is my personal preference. However, whenever I build out a new laptop I have to once again remember where those pesky settings are to force Outlook 2007 to use plain text. Hence, this post:

Reading email in plain text:
Select Tools > Trust Center from the Outlook 2007 menu and click on the E-mail Security node. In the Read as Plain Text section, select both checkboxes. Click the OK button to save the changes and exit the dialog.

Writing email in plain text:
Select Tools > Options from the Outlook 2007 menu and click on the Mail Format tab. In the Message Format section, choose Plain Text from the dropdown list. Consolas Regular 10.5 is the default font which is currently my favorite (except for single quotes and commas it is clearly cleaner looking than the old Courier New) but if you click on the Stationary and Fonts... button you can choose whatever font you prefer. Click the OK button twice to save the changes and exit the dialogs.

That's all there is to it. Why these two options are so far apart is beyond me.

The unconverted masses will continue to send you HTML email, so you will occasionally need to see non-text content. Outlook 2007 makes that easy, in the message you are reading as plain text, simply click on the orange bar near the top of the message and select Display as HTML from the context menu:

God forbid, you may even find that you need to send an HTML message. Outlook 2007 also makes that easy, in the message you are writing as plain text, choose Options > HTML from the Format Group:

PS: Why does Microsoft insist on including a dash in the word email?

My Hyper-V VM Cursor Displays as Just a Dot

Todd Bleeker — Sat, 31 Oct 2009 11:42:41 GMT

Ever had the cursor in your Hyper-V Virtual Machine (VM) not render as an Arrow or an I-beam but simply as a dot?

The fix is not at all intuitive. No amount of fiddling with the mouse settings seemed to have any good affect. But if you Save the VM’s state then immediately (or in your own good time if you prefer) Start and Connect to the VM again. The cursor display is restored to conform to the settings.

That’s all that is required. Not sure why the cursor display gets messed up in the first place. So, if you have the ounce of prevention, please leave a comment…

Useful Trial Downloads for SharePoint Development

Todd Bleeker — Fri, 30 Oct 2009 03:49:57 GMT

Microsoft has several trial downloads that can be very helpful as we transition to SharePoint 2010 development...

General Developer Downloads:

Visual Studio 2010 Ultimate Beta 2 (SharePoint Tools hardcoded to the SharePoint 2010 Beta 2 release coming later in November)
Team Foundation Server (TFS) 2010 Beta 2
Visual Studio Team Explorer 2010 Beta 2
90-day Windows 7 Install bits
90-day Windows 7 VHD
Getting Started Developing on SharePoint 2010
SharePoint 2010 Technical Articles
SharePoint 2010 Developer Center
SharePoint 2010 Walkthroughs

Still tons of helpful downloads for Windows SharePoint Services 3.0 development too...

Microsoft Security Essentials

Todd Bleeker — Wed, 30 Sep 2009 23:33:29 GMT

If you have used Windows Defender and/or Windows One Care in the past, the long wait for the new, free Windows Security Essentials is finally here:
http://www.microsoft.com/security_essentials/

Now to go replace AVG and Windows Defender on all the desktops I’ve maintained over the years. Yikes!

SharePoint Post Build Events

Todd Bleeker — Fri, 04 Sep 2009 11:26:15 GMT

For those of you that want the simplest possible way to deploy SharePoint artifacts from your Visual Studio 2005/2008 projects to the locations where Windows SharePoint Services 3.0 (WSS v3) needs them without installing any external tools or altering Visual Studio, here is the entire corpus of my Post Build Events for the development deployment of all types of SharePoint artifacts:

:: Change directory to the root of the project
cd "$(ProjectDir)"

:: Recycle the application pool
:: IIS6:
REM %windir%\system32\cscript.exe %windir%\system32\iisapp.vbs /a "[AppPool]" /r
:: IIS7:
REM %windir%\system32\inetsrv\appcmd.exe recycle AppPool "[AppPool]"

:: Copy all files from the VS.NET Project's 12 folder to the WSS 12 Hive (including subdirectories)
REM xcopy "12" "%CommonProgramFiles%\Microsoft Shared\web server extensions\12\" /ys

:: Copy all files from the VS.NET Project's 80 directory to the Web Application IIS home directory
REM xcopy "80" "C:\Inetpub\wwwroot\wss\VirtualDirectories\[Site]\" /ys

:: Install (force/overwrite) DLL to the GAC
REM %WindowsSdkDir%bin\GacUtil.exe" /if "$(TargetPath)"

:: Create a WSP CAB
REM MakeCAB /f "WSP.DDF"

Be sure to replace the [AppPool] and [Site] placeholders with the actual values you are using to test.

Simply run these commands in the Post Build Events of your Visual Studio project and unREM the lines that you need for any given developer deployment scenario. I believe that these commands will work in every operating system version, every Visual Studio version, and every IIS version. The only potential problem would be whether Visual Studio 2005 defines the %WindowsSdkDir% variable or not; however, I no longer have an environment that I can test that out on.

Just to be clear, these are only to be used on a developer machine. You should _always_ use a Windows SharePoint Services Solution Package (WSP) CAB to deploy to any environment other that your local developer environment.

HTH,

slooF lirpA Web Part

Todd Bleeker — Wed, 01 Apr 2009 10:21:00 GMT

One of my favorite SharePoint April Fools gags is to alter the direction that HTML is displayed on a popular SharePoint page. I've encapsulated that code into a simple Content Editor Web Part I've called slooF lirpA (April Fools backwards).

Download the slooF lirpA Web Part DWP and Import it onto a SharePoint page to see this kind of result:

Open Windows SharePoint Services Solution Packages (WSP CABs) in Windows Explorer

Todd Bleeker — Wed, 18 Mar 2009 16:41:00 GMT

Wouldn't it be nice if you could double click on a Windows SharePoint Services Solution Package (WSP) CAB in Windows Explorer and it would open just as if it had a CAB extension. This can be done by simply associating any file with a WSP extension to open in the Cabinet File Viewer Shell Extension. The net requirement is just a few Windows Registry entries:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.wsp]
@="CLSID\\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}"
"InfoTip"="Contains compressed files"

[HKEY_CLASSES_ROOT\.wsp\PersistentHandler]
@="{098f2470-bae0-11cd-b579-08002b30bfeb}"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wsp]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wsp\DefaultIcon]
@="cabview.dll,0"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wsp\OpenWithList]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.wsp\OpenWithProgids]
"CLSID\\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}"=hex(0):

To make it simple, I've created two .reg files in a downloadable WSPCabinetFileViewer.zip:

1. WSP Cabinet File Viewer.reg: Set the registry settings needed to open a WSP cab within the Windows Cabinet File Viewer Shell Extension of Windows Explorer just like a file with a CAB extension.

2. WSP Cabinet File Viewer - Undo.reg: Remove the registry setting added to open a WSP cab within the Windows Cabinet File Viewer Shell Extension of Windows Explorer.

Steps to try this out:

Download and expand the zip
To "install", double click on WSP Cabinet File Viewer.reg
Reboot if you are running Windows Server 2008
Try to open a WSP file in Windows Explorer
See the files contents
To "uninstall", double click on WSP Cabinet File Viewer - Undo.reg

It really is that easy. I have tested these .reg files on Vista Ultimate, Windows Server 2003, and Windows Server 2008. Only Windows Server 2008 required a reboot to see the effects.

Add an Essential Toolbar to the 12 Hive on the Windows Startbar

Todd Bleeker — Wed, 18 Mar 2009 14:35:14 GMT

A few years ago, I described how to add this toolbar to the Windows Startbar in my book: Developer's Guide to Windows SharePoint Services 3.0

But, it bears repeating here. The 12 Hive is where anything and everything SharePoint gets it genesis. You may note that this it the tag line for my blog.

The 12 Hive is located on the file system of each server where SharePoint is installed at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\. The 12 Hive contains the definition of the core assets that SharePoint presents for users to create and activate, so it is very helpful for developers to have quick and easy access to the files in this folder. Use the following steps to add a 12 toolbar to the Startbar.

Right-click on the Windows Startbar and choose Toolbars > New Toolbar...
Expand My Computer (listed as the Machine Name)
Expand Local Disk (WSS v3 is installed on the C: drive)
Expand Program Files
Expand Common Files
Expand Microsoft Shared (after expanding, type the letter "w" three times to swiftly move to the next folder to expand)
Expand web server extensions
Select the 12 folder
Click the OK button

The result should be a menu that flys up from the Startbar that looks something like this:

Cool!

Get Public Key Token of Strong Named (Signed) Assembly Using VS.NET Tools Menu

Todd Bleeker — Tue, 17 Mar 2009 15:48:15 GMT

I've been explaining this tip in Mindsharp’s SharePoint Developer training for years and I've had people ask me repeatedly to blog it, so here goes.

Both Visual Studio (VS.NET) 2005 and 2008 make it quite easy to sign .NET assemblies with a strong name key (SNK) public key/private key pair directly from the Properties of the project.

However, after the assembly is compiled, nothing in the default VS.NET IDE can obtain the public key that was embedded within the assembly. So, the command-line Strong Name Tool (sn.exe) is often used to peek into the assembly for the public key token and the public key blob using the following command (run within a VS.NET Command Prompt):

sn -Tp [pathToAssembly]\[assemblyFileName]

While this is not difficult, it is terribly inefficient. Not only does it require the developer to open a command window, but also:

Remember the command,
Remember the parameters,
Use the correct case of those parameters (the T must be uppercase, the p must be lowercase),
Locate or type the full path to the assembly (in double quotes please), and
Execute the command

What’s worse, VS.NET knows exactly where the assembly was created; it just does not provide an interface to peek into the assembly to see the public key token and the public key blog.

It is also possible to drag (or GacUtil.exe) the DLL into the GAC to see the public key token (not the public key blob); Red Gate’s .NET Reflector can also show an assembly’s public key token.

However, there is hope. VS.NET allows developers to setup "External tools". The Strong Name Tool (sn.exe) is an external tool. So, with a little configuration of the IDE, a Get Public Key menu option can be added to the Tools menu.

Optionally, a Get Public Key icon can even be included directly on the toolbar. Then, just click the icon to get the public key token and the public key blob from any compiled assembly that is in focus in the Solution Explorer.

You can find a step by step explanation showing how to add the menu option and the toolbar option in the the PDF that I published privately last year. Be aware, the paper describes steps for VS.NET 2005 but VS.NET 2008 installs sn.exe in a different location than VS.NET 2005:

Make sure to use this VS.NET 2008 location when creating the Get Public Key External Tool.