Eric Lippert is starting a series of articles about future changes in the C# method type inference specification and the implementation. He plans to write about the following points:

• What did method type inference look like in C# 2.0? Why was it inadequate for LINQ?
• How did we attempt to modify and ultimately rewrite the specification for C# 3.0?
• Where did we go subtly wrong in the specification and the implementation

The first 2 articles are posted on his blog:

0. Method Type Inference Changes, Part Zero
1. Method Type Inference Changes, Part One

class Program {
    static void Main(string[] args) {

        string[] strings = { "aa", "bb", "c", "dddd", "eeee", "f" };

        // use a class which implements IComparer
        // This works best when you want to re-use sorting logic
        //  or need to store state between using the comparer.
        Array.Sort(strings, new StringLengthComparer());

        // The following two methods only differ in syntax, both use a delegate.

        // use an anonymous method
        Array.Sort(strings, delegate(string x, string y) { return x.Length - y.Length; });

        // use a lambda expression
        Array.Sort(strings, (x, y) => x.Length - y.Length);

    }

    class StringLengthComparer : IComparer<string> {

        public int Compare(string x, string y) {
            return x.Length - y.Length;
        }
    }
}

Note: The array is sorted on the length of the strings, if you want to sort the strings in the array based on the content use an instance of the StringComparer class.

A little older, but Eric Lippert has a series of interesting posts about immutability in C#. What it is and why it's important and a number of sample immutable collections:

1. Immutability in C# Part One: Kinds of Immutability

2. Immutability in C# Part Two: A Simple Immutable Stack

3. Immutability in C# Part Three: A Covariant Immutable Stack

4. Immutability in C# Part Four: An Immutable Queue

5. Immutability in C# Part Five: LOLZ!

6. Immutability in C# Part Six: A Simple Binary Tree

7. Immutability in C# Part Seven: More on Binary Trees

8. Immutability in C# Part Eight: Even More On Binary Trees

9. Immutability in C# Part Nine: Academic? Plus my AVL tree implementation

10. Immutability in C# Part 10: A double-ended queue

11. Immutability in C# Part Eleven: A working double-ended queue

This class is an addition to the html- and url-encoding in the HttpServerUtility class. Where the methods in the base framework, only encode a limited number of characters. The classes in the AntiXss class encode everything, that is not explicitly allowed. These means that everything but the following characters are encoded in most cases: a-z, A-Z, 0-9, (comma), (period), (dash), (underscore) and (space). 

[download: Microsoft Anti-Cross Site Scripting Library V1.5]

A nice series of posts about Covariance and Contravariance in a hypothetical future version of C# by Eric Lippert.

1. Covariance and Contravariance in C#, Part One
2. Covariance and Contravariance in C#, Part Two: Array Covariance
3. Covariance and Contravariance in C#, Part Three: Member Group Conversion Variance
4. Covariance and Contravariance in C#, Part Four: Real Delegate Variance
5. Covariance and Contravariance In C#, Part Five: Higher Order Functions Hurt My Brain
6. Covariance and Contravariance in C#, Part Six: Interface Variance
7. Covariance and Contravariance in C# Part Seven: Why Do We Need A Syntax At All?
8. Covariance and Contravariance in C#, Part Eight: Syntax Options
9. Covariance and Contravariance in C#, Part Nine: Breaking Changes
10. Covariance and Contravariance in C#, Part Ten: Dealing With Ambiguity

Eric added another part:

11. Covariance and Contravariance, Part Eleven: To infinity, but not beyond

[Update: the results in this post about the performance of a memory stream, when changing the initial capacity are wrong. You can find the correct results in this new post.]

WCF (Windows Communication Framework) introduces additional XmlWriters for more efficient serialization of the messages send between nodes. These writers derive from the abstract XmlDictionaryWriter class and wrap the functionality of existing System.Xml. (For more information visit Justin Smith's post or watch Doug Purdy's COM326 presentation from PDC 05.

I was interested in the performance of the basic UTF-8 text writer and the binary writer for writing content heavy Xml. In this scenario an XmlDictionary won't give much benefit, since in my experience a dictionary will only reduce the size of the tags and not the actual content. More specifically I was interested in the difference in size and the speed of writing of xml files of various sizes.

On to the actual testing: I used the 138 feeds from my blogroll, that do not have a doctype in their feeds, since the XmlDictionaryWriter doesn't support writing those. After loading the feeds in an XmlDataDocument they are saved to the different streams and the size of the streams and the time it takes are written to a log-file for analyzing. Finally the whole process is repeated for a number of initial sizes for the MemoryStream (256 - 524288 in powers of 2).

The results: compression xml files makes them smaller, but it takes longer to write them.

 As you can see the difference between the text writer the binary writer are small, looking at the averages for all files.

When looking at the bytes written / tick you'll see that the binary writer is generally faster for uncompressed files smaller than 8192 bytes and negligible slower for compressed files. Another thing to notice is that the writing speed increases for uncompressed streams as the files get bigger, while it drops a little for compressed streams. The fact that the writing speed drops for the biggest files is probably caused by the mem copy which occures when the memory stream has to increase it's capacity. 

 The initial capacity doesn't seems to influence the throughput of the memorystream in a significant way, but this may be related to the data I used to test.

[Download solution for VS 2008]

Notes:

1) According to the MSDN library the compression algorithm the DeflateStream uses is the same the GZipStream uses, so performance should be similar.

2) My data is not your data; you should always do your own testing and decide of the performance and the size are right for you.

Although generally a bad idea [0], there is another problem. The System.Web.Caching.Cache doesn't call dispose on the items removed from the cache, causing a resource leak. To prevent this resource leak, add a CacheItemRemovedCallback in which you dispose of the object.

// add the item to the cache, note the callback

HttpRuntime.Cache.Add("myKey", myClass, null, DateTime.Now.AddSeconds(5), 
     Cache.NoSlidingExpiration, CacheItemPriority.Default, 
     new CacheItemRemovedCallback( OnRemoved ) );

// callback function

void OnRemoved( string key, object value, CacheItemRemovedReason reason ) {

     IDisposable disposable = value as IDisposable;
     if (disposable != null) {
          disposable.Dispose();
     }
}

[0] Should you really be caching an object containing unmanaged resources, which usually are scarce?

public class A {
    public virtual void AA(){}
}

public abstract class B : A{
    public abstract override void AA();
}

This is a short walkthrough on how to get the REST and POX sample from the Vista SDK to work on IIS. I assume VS 2005 with SP 1 and IIS 5.1, but the changes required on IIS 6 are the same.

Before we begin make sure you have .Net 3.0 installed and either the Vista SDK or the WCF Samples. And IIS, with the mappings for Asp.Net and WCF.

The sample we'll modify to work with IIS is located in "TechnologySamples\Scenario\PoxMessaging\CS" directory. And since there are no code changes the VB sample should work too.

First load the solution and make sure the it actually compiles and works, so we have a known base system we can work from. Do this by first starting the server and next the client, if you don't get any un-handled exceptions, then everything works, so we're good to go.

Next create a new Web Application Project, names ServiceHost in the solution and make sure it uses IIS for hosting in the Properties Web tab.

Remove all files VS created in your new project, except for the web.config and copy all files from the service project, except for program.cs and app.config. Finally add a reference to the System.Runtime.Serialization and the System.ServiceModel assemblies. Now the project should compile, but won't do anything interesting.

To register the endpoint, we have to copy the serviceModel configuration from the app.config in the service project to the web.config. So add the following to the web.config file:

 










contract="Microsoft.ServiceModel.Samples.IUniversalContract" />

This is the same as the config in the app.config, with the baseAddresses node removed, since those are supplied by IIS.

Now add a new file to the web project named: "customers.svc" with the following content:

<%@ ServiceHost Language="C#" debug="true" service="Microsoft.ServiceModel.Samples.CustomerService" %>

Save all files and if you surf to http://localhost/servicehost/customers.svc/customers/1 , you should see the following:

http://tempuri.org/Customer" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

Do note how the "/customers" part maps to the endpoint you specified in the web.config and the "/1" to the id of the customer. If you leave off the "/1" you should get a list of customers.

Which indicates the GET HttpMethod is working, to get the other methods working, we have to make some changes to the IIS configuration. In the properties of the ServiceHost virtual directory in IIS, click the Configuration button.

Now find the .svc mapping in the Application Mappings, click Edit and select "All Verbs".

That's all there is to it. To test it you'll need to make some changes to the client project, to make sure it uses the correct URLs to access the service. See the attached solution for details.

 POX-REST-IIS-Sample.zip (11.69 KB)

They have been around for a bit, hiding as delegates, but they're getting some much deserved attention from Joel [0] and Raymond [1].

Joel is critical about the implementation in C#; while Raymond Chen is starting a series about their implementation and subtle errors. I'm not sure I can totally agree with Joel, since I like the obviousness (and typesafe-ness) of defining delegates and calling them as methods, while the compiler handles the plumbing.

links:
[0] Can your programming language do this?
[1] The implementation of anonymous methods in C# and its consequences (part 1)

[update 2006-08-05]

Ramond added 2 new entries to his anonymous methods series:

The implementation of anonymous methods in C# and its consequences (part 2)
The implementation of anonymous methods in C# and its consequences (part 3)