Sean's Blog

When sending emails to users of your system, it’s important that clients be able to read your messages. Even with modern technology advancements, not all email clients support HTML –some users actually prefer text messages. For this reason, it is important that we deliver content that a standard email (non-HTML) client can read. One way of doing this is by delivering a multi-part MIME message with alternate body parts –one part being a standard email, and another being an HTML message. It is then up to the email client to display the richest part that it can render.

Starting with 2.0, the .NET Framework includes an AlternateView class, exactly for this purpose. Following is the code necessary to send a multi-part MIME message containing both standard and HTML parts:

static void SendMessage()
{
    SmtpClient client = new SmtpClient("alt1.gmail-smtp-in.l.google.com");
    MailMessage message = new MailMessage();
    AlternateView plainMessage = AlternateView.CreateAlternateViewFromString("This is a plain text message.", null, "text/plain");
    AlternateView htmlMessage = AlternateView.CreateAlternateViewFromString("This is an <b>HTML</b> message.", null, "text/html");

    // Basic message properties
    message.From = new MailAddress("me@myaddress.com");
    message.To.Add("me@gmail.com");
    message.Subject = "Alternate View Test";

    // Add the alternate views to the message
    message.AlternateViews.Add(plainMessage);
    message.AlternateViews.Add(htmlMessage);

    client.Send(message);
}

C# 3.0 brought with it a plethora of great additions, such as LINQ, lambda expressions and anonymous types. With the inclusion of LINQ, Microsoft decided that it was often difficult to determine the return type from a LINQ expressions. As such, they opted to include the var keyword, which is used to implicitly define a type. The type is determined by the compiler at compile time, making it strongly typed, so it is not analogous to the Visual Basic variant type. While this has some value in aiding in building LINQ expressions, I often find the use of the var keyword to be unclear (in my opinion) when used to define variables. In C# 3.0, for example, the following code is completely legit:

static void Main()
{
    var myInt = 10;
}

The code above defines an integer named myInt. While this particular example may be clear, I have found other situations where the use of the var keyword has made code less readable.

static void Main()
{
    var myEmployee = new Employee();
}

Still not terribly unclear because the type is on the same line. But we’re starting to get unclear because my eyes start at the left to determine the type. But what if the type isn’t on the same line? What if it’s the return value of some method in another class?

static void Main()
{
    var myEmployee = new Employee();
    var i = myEmployee.GetSomething(); // Unclear
}

What does the type above return? We could argue that the name GetSomethig() isn’t explicit enough. That’s a valid argument, but are all methods inherently named explicitly enough to determine the type returned? Absolutely not. As a result, I find myself having to reach for the mouse to hover over the the method to see a tooltip that I can use to make that determination. It slows me down. Is it that difficult to explicitly declare the type of your variable ahead of time? It makes maintenance and readability a lot easier.

If you're trying to impersonate a Windows identity in an Excel Services UDF, make sure to configure the Excel Service access mode to delegation, rather than the Trusted Subsystem model (default).  This can be done with the following commands:

stsadm -o set-ecssecurity -accessmodel delegation -ssp sspname
stsadm -o execadmsvcjobs
iisreset

Failing to do so could result in hours of frustration! Specifically, if you always go down the error path in the following code, this is likely the problem:

if ((wi = Thread.CurrentPrincipal.Identity as WindowsIdentity) == null)
{
throw new InvalidOperationException("An error occurred during the Impersonation process");
}

This next post might be rather obvious to most of you, but I figured I wasn't the only one that didn't know how to do this.  I was recently working with a new ASP.NET MVC project and got tired of typing out the fully qualified class names.  This seems like something that would be rather common, but a quick Google search didn't turn up anything useful.  I figured that there had to be a way to import a namespace, so intellisense to the rescue, I noticed that there was an <%Import %> directive.  Sure enough, that did the trick.

<%@ Import Namespace="SubSonic" %>

I was recently working on an application that was known for throwing random exceptions at various times for no apparent reason.  Frustrated, I wrote this snippet of code to ease the tension.  I just thought I'd share it with you.

Program.cs
using System; using System.Collections.Generic; namespace RandomConsoleTests { class RandomConsoleTests { static void Main(string[] args) { ThrowRandomException(); } public static void ThrowRandomException() { throw ExceptionFactory.CreateRandomException(); } } }

ExceptionFactory.cs
using System; using System.Collections.Generic; using System.ComponentModel; using System.Configuration; using System.Configuration.Provider; using System.Data; using System.IO.IsolatedStorage; using System.Net.Mail; namespace RandomConsoleTests { public static class ExceptionFactory { public static Exception CreateRandomException() { Random rand = new Random(); switch (rand.Next(0, 20)) { case 0: return new ApplicationException(); case 1: return new ProviderException(); case 2: return new SettingsPropertyIsReadOnlyException(); case 3: return new SettingsPropertyNotFoundException(); case 4: return new SettingsPropertyWrongTypeException(); case 5: return new IsolatedStorageException(); case 6: return new SmtpException(); case 7: return new SystemException(); case 8: return new AccessViolationException(); case 9: return new AppDomainUnloadedException(); case 10: return new ArgumentException(); case 11: return new ArithmeticException(); case 12: return new ArrayTypeMismatchException(); case 13: return new BadImageFormatException(); case 14: return new CannotUnloadAppDomainException(); case 15: return new KeyNotFoundException(); case 16: return new WarningException(); case 17: return new TimeoutException(); case 18: return new OutOfMemoryException(); case 19: return new DataException(); case 20: return new InvalidOperationException(); default: return new Exception(); } } } }

If you install the Commerce Server starter site on a port other than port 80, you will run into a couple of issues.  The problem is that Microsoft coded the site to drop the port number.  To correct the problem, open the App_Code\SiteContext.cs file and comment out the following line of code (it's on line 247, for me):

builder.Port = -1; // Removes the port setting from the site.
Add the following line of code in its place (note, update port numbers to match your sites configuration):

builder.Port = secure ? 8443 : 8080;
UPDATE:

The User\Login.aspx.cs file also needs to be updated.  Located the following line in the OnInit() method and change the -1 to match the port number for which SSL is configured to run on your site:

builder.Port = -1; // Change this to your sites SSL port

Hope that helps...

It seems to me that one of the most underused features of the C# (or Visual Basic) language is the structure.  Developers are often lead to believe that use of classes yield performance benefits.  While this is often the case, structures have their own set of advantages that, when used in the right situation, will yield important, and sometimes substantial performance benefits.  This blog post is intended to help demystify some of the confusions between structures and classes.

In their simplest form, classes and structures in C# are very similar.  In fact, often times, you may simply replace the class keyword with the struct keyword, and your classes can instantly be converted into a struct:

public class Person
{
}

public struct Person
{
}

Indeed, from the standpoint of a text editor, these two entities are identical except for the class and struct keywords.  At the system level, however, these two entities behave very differently.  As most C# developers know, the biggest difference between the two entities is that the class is a reference type, whereas the struct is a value type.  A slightly more educated C# developer would also point out that the struct is stored in the stack, whereas the class is stored in the heap.  This is an important concept to understand because it is this reason that structures have the potential for increased performance in some situations, but also one of their biggest drawbacks, in other situations.

By being stored in the stack, the runtime (CLR) can create, read, update and remove value types very quickly, with minimal overhead.  It is important to note, however, that the stack is limited.  In fact, you should never create a value type with an instance size greater than 128 bits (16 bytes).

In contrast to value types, reference types store a pointer in the stack that points to an object found in the heap.  By storing reference types in the heap, the amount of memory is limited to the available physical RAM found in the computer that the code is executing on (there is, of course, the concept of swapping, which increases the theoretical limit of available memory; however, that goes beyond the scope of this article).  Following is a simple example of objects types stored in the heap (please excuse the artwork, I'm certainly not a designer):



From looking at this simple diagram, it should  be obvious that  accessing something from the stack can be faster than accessing something from the heap.  This is because the processor has direct access to something stored on the stack, whereas it has to do a lookup and then 'fetch" of anything found on the heap.  There is actually more to it, but for the sake of simplicity, I'll leave it at that.

Another important concept to realize is that, because they are stored in the stack, value types create a second copy of the value when they are copied.  That is, the stack will contain two or more instances of the value each time it is copied.  Reference types, on the other hand, are not copied.  Instead, only the pointer is copied.  In other words, when you copy a reference type, the object itself is not copied, only the pointer is copied.  This obviously has its benefits; especially for large objects.

So then, the important question is, when should you use a structure versus a class?  Following is a simple list of requirements that should help you decide when to use a structure.

• Represents a single value
  
• Will not be changed after its creation
• Will not be cast to a reference type (for more information, read up on boxing and unboxing)
• Has an instance size less than 128 bits (16 bytes)

If your entity does not meet those requirements, your best choice is going to be the use of a class.

For more information on the differences between classes and structures, be sure to check out Microsoft's page.

Update:

Rick Minerich has posted a terrific series of articles related to memory management. I highly recommend reading all three, but for those of you that would like to jump straight ahead to managing the size of the stack, please jump to part 3:

Part 1 – Basic Housekeeping
Part 2 – Improving Performance Through Stack Allocation
Part 3 – Increasing the Size of your Stack

If you are attempting to access a blocked file type in SharePoint 2007, you will receive the following error:

The following file(s) have been blocked by the administrator

The following describes how to resolve the issue:

1. Browse to the Central Admin site
2. Select the Operations tab
3. Under the Security Configuration section, click the link for Blocked file types
4. Select the Web Application that you would like to modify from the drop down list
   
5. Each blocked file extension displayed in the list is blocked by SharePoint.  To enable the blocked file extension, simply remove it from the list.

Hope that helps!

If you've ever attempted to programmatically add a DOM event to the <body> tag in your ASP.NET application, you have probably noticed that there isn't an easy way to do so.  The problem is that there is no way to get a reference to the body tag in the code behind.  A simple solution might be to add the ID and runat="server" attributes to the body tag.  This would be a nice little trick to get a reference to the <body> tag in the code behind of the current page, but what if, for example, a control you were writing required some client-side garbage collection when the user leaves the page?  The DOM onunload event would be a nice place to start, but this attribute is applied to the <body> tag.  Forcing anybody that uses your control to add the appropriate attributes to their body tag is asking a bit much, not to mention error prone.  A control should provide the implementation for everything that is required for it to operate so that the client need not worry about the details.

We obviously have the tools necessary register a startup script; however, there isn't anything available that will register a script that is run when the user leaves the page.  Or is there?  After a little bit of brainstorming, I came up with a simple solution that I think solves the problem.  The solution: Use JavaScript to programmatically wire up the DOM onunload event!


Page.ClientScript.RegisterStartupScript(typeof(MyControl), "Unload.js", "<script type=\"text/javascript\">window.onunload = function () { alert('Dont leave me!!!'); };</script>", false);

In short, this code snippet registers a startup script that configures the DOM onunload event.  When the browser loads the page, the JavaScript is executed, thereby registering the appropriate onunload event, which is run when the user leaves the page.

This code could easily be modified to be more friendly towards any other onunload events that might already be wired up; or, to add any other attribute to the <body> tag by using JavaScript.

Hope this helps...

I recently had an issue while trying to configure the authentication provider for a SharePoint 2007 site.  Regardless of the authentication provider that I selected, clicking the save button would result in the following error:

An object of the type Microsoft.SharePoint.Administration.SPWebApplicationProvisioningJobDefinition named "Provisioning 1aa06c49-f543-41c2-b3f6-ce7884a9b71d" already exists under the parent Microsoft.SharePoint.Administration.SPWebService named "".  Rename your object or delete the existing object.

After coming up short on answers from multiple Google searches, I dug into the Timer job Status page under the Operations tab of Central Administration and noticed that for every attempt I made to configure authentication for a site that there were two jobs being created.  One job would pass while the other would fail.  Previously unknown by me, the SharePoint site had been configured in a Server Farm configuration, so the two jobs that I saw coincided with the two servers in the farm (the job had to be provisioned to each server in the farm).  After a quick investigation, it was determined that the two servers were running different versions because a hot fix had been applied to one, but not the other.

In my situation, this was a new SharePoint install and, not being familiar with configuring SharePoint in a server farm, I was able to temporarily remove the second server from the farm and move forward without any errors.  The real test, however, would be to apply the patch to the second server and go through the process again.

There were other constraints, beyond the scope of this post, that made temporarily removing the second server more ideal than simply applying the patch to see where it got me.  I will update this blog when I have added the second server back into the equation.