Daniel Cazzulino's Blog

I’m not advocating *private* reflection (invoking private/internal fields, properties and methods), but we all know that there are those corner cases where you just can’t avoid it. And there’s a whole lot of scenarios when there are legitimate uses of reflection itself that can also leverage this very cool dynamic syntax (i.e. invoking generic methods where you don’t know the type at compile-time, etc.). In these cases, your code goes from pristine-looking C# to crappy unreadable reflection code.

David Ebbo has explained quite a bit already why this might be needed and how it can be used.

This is a pretty handy tool to have for those rare cases, and it’s pretty small, making it ideal for a ...

Read full article

From the documentation:

How to contribute

NETFx relies on the CodePlex mercurial fork/pull process for contributions. The explanation on how to contribute to NuGet applies roughly in its entirety to NETFx.

Install the NETFx Contributor VSIX from the Extension Manager.

Restart VS, and now you’ll get the NETFx Extension template:

Things to note:

• The Location MUST be under the netfx\Extensions folder
• The directory structure following Extensions is used to make up your extension id, in the above case, it will be “netfx-System.Net.Http.HttpResponseExtensions”
• UNCHECK the “Create directory for solution” option, or otherwise you’ll end up with a duplicate name in the package ID and the folder structure. If you make this mistake (I do it all the time ...

Read full article

From the project home page:

What

Lightweight NuGet packages with reusable source code extending core .NET functionality, typically in self-contained source files added to your projects as internal classes that can be easily kept up-to-date with NuGet.

Why

Who doesn’t have an ever growing and ever less cohesive miscellaneous collection of helpers, extension methods and utility classes in the usual “Common.dll”? Well, the problem is that there’s really no good place for all that baggage: do we split them by actual behavioral area and create “proper” projects for them?

In most cases, that’s totally overkill and you end up in short time with the same pile of assorted files as you try to avoid setting up an entire new project to contain just a couple cohesive classes....

Read full article

In previous versions of the Web API, you could query your REST endpoints that exposed an IQueryable<T> server-side, kinda “Linq to WCF” as @gblock said. This was immensely useful and an important driver (among others) for me to move away from Astoria ADO.NET Data Services. That functionality is gone now (vote to get it back!).

So I was wondering how to bring it back. Would I need to refactor the monstrous (as in big, not ugly) OData client source to reuse just the Uri query translator? This started to look like a daunting task....

Read full article

Given the many cross-cutting concerns you can cover using the new Web API pipeline,  it’s not a bad idea to have a bunch of integration-style tests that cover the actual running service end to end.

This is pretty straightforward nowadays: create the service host, open, close on cleanup. Add the Http host configuration from the new APIs on top and that’s about it.

The following code is using a little helper class (in the spirit of a true NETFx nuget) that makes this slightly easier:

[Fact]
public void WhenHostingService_ThenCanInvokeIt()
{
    using (var webservice = new HttpWebService<TestService>(
        serviceBaseUrl: "http://localhost:20000",
        serviceResourcePath: "test",
        serviceConfiguration: HttpHostConfiguration.Create()))
    {
        var client = new HttpClient(webservice.BaseUri);

        // Builds: http://localhost:2000/test/23
        var uri = webservice.Uri("23");
        var response = client.Get(uri);

        Assert.True(response.IsSuccessStatusCode, response.ToString());
        Assert.True(response.Content.ReadAsString().Contains("23"));
    }
}...

Read full article

There is an aging post by Christian on how to use the awesome Json.NET library as a default serializer for the new WCF Web Api.

Rather than having two media type formatters (in the latest bits lingo), I wanted to have a single one and have it pick the flavor of Json/Bson on the fly depending on the accept header on the request. This makes configuration simpler as you have to add only one formatter to the pipeline:

var config = HttpHostConfiguration.Create();
config.Configuration.OperationHandlerFactory.Formatters.Insert(0, new JsonNetMediaTypeFormatter());...

Read full article

The new configuration model in the latest WCF Web APIs allows extending the service instantiation via what is called a resource factory.

For Autofac, I wanted to support a per-request lifetime scope, so I used the concept of instance context extensions in the Web APIs to place our scope so that it can be disposed on release.

public class AutofacResourceFactory : IResourceFactory
{
    private IContainer container;

    public AutofacResourceFactory(IContainer container)
    {
        this.container = container;
    }

    public object GetInstance(Type serviceType, InstanceContext instanceContext, HttpRequestMessage request)
    {
        // Begin lifetime scope when the service is instantiated.
        var lifetime = this.container.BeginLifetimeScope();
        // Hold the lifetime as an extension in the instance context
        instanceContext.Extensions.Add(new AutofactLifetimeExtension(lifetime));

        return lifetime.Resolve(serviceType);
    }

    public void ReleaseInstance(System.ServiceModel.InstanceContext instanceContext, object service)
    {
        var extension = instanceContext.Extensions.OfType<AutofactLifetimeExtension>().FirstOrDefault();
        // If we find our extension there, dispose it so the lifetime gets disposed.
        if (extension != null)
            extension.Dispose();
    }

    private class AutofactLifetimeExtension : IExtension<InstanceContext>, IDisposable
    {
        private ILifetimeScope lifetime;
        private bool isDisposed;

        public AutofactLifetimeExtension(ILifetimeScope lifetime)
        {
            this.lifetime = lifetime;
        }

        public void Attach(InstanceContext owner)
        {
        }

        public void Detach(InstanceContext owner)
        {
            Dispose();
        }

        public void Dispose()
        {
            if (this.isDisposed)
                return;

            this.lifetime.Dispose();
            this.isDisposed = true;
        }
    }
}...

Read full article

By default, when you implement an interface in a class, you get the following for properties:

public string ClassName
{
    get
    {
        throw new NotImplementedException();
    }
    set
    {
        throw new NotImplementedException();
    }
}

But of course the typical thing to do is to implement them as automatic properties. You have two options at this point: modify the default expansion snippet, or do a find & replace with a regex.

How to change the default property stub expansion

Open the PropertyStub.snippet from C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC#\Snippets\1033\Refactoring\PropertyStub.snippet, and change the <Code> from:...

Read full article

Every now and then, when trying to do something in MSBuild, I hit a roadblock (or maybe just some unintuitive “feature”) and I’m left thinking “gosh, now I have to create a custom MSBuild task for this one-liner that is SO trivial in plain C#!”.

Well, no more with MSBuild 4.0. You can now write inline tasks in plain C# which can of course have input and output parameters.

For example, I needed to checkout a file from TFS before some task run and tried to write it. Checking out from TFS can easily be done with an Exec task:

<Exec Command=""$(VS100COMNTOOLS)..\IDE\tf.exe" checkout $(ExtenderNamesTargetFile)"
      WorkingDirectory="$(MSBuildProjectDirectory)" />...

Read full article

It’s quite common to refer to $(DevEnvDir) in a project, such as to specify the path to a referenced assembly, or to execute a tool on a build event or a target. It’s right there in the UI after all, why not use it?

Well, turns out that the variable is not defined when the build is run by Team Build, so it resolves to *Undefined*. Yuck.

This adds yet another reason in favor of using the less obvious $(VS100COMNTOOLS) environment variable.

Just replace all occurrences of $(DevEnvDir) with $(VS100COMNTOOLS)..\IDE\ and you’re good.

Read full article