Daniel Cazzulino's Blog

The new VSIX projects contain a manifest that is by default opened with a designer. No matter how many times you specify that you want to open it with the XML editor by default, VS will continue to open it with the designer.

The only way to force the change is to manually modify the .csproj as follows:

<ItemGroup>
  <None Include="source.extension.vsixmanifest">
    <SubType>DesignerCode</SubType>
  </None>
</ItemGroup>

(on Beta1, the manifest file name would be just extension.vsixmanifest)

Read full article

Last time I announced Linq to Mocks, some said Moq didn't actually have anything to do with Linq. Despite the heavy usage of lambda expressions and expression trees, the "q" in Linq is for "query" after all. And they were right, of course, but it was fun anyway, and the name is definitely cool IMO :).

But this time around, I'm happy to say that it's finally true. What the next version of Moq (early beta readily available now) allows you to express in a very declarative way essentially is:

from the universe of mocks, get me those that behave like this

Rather than procedurally defining how the mock will behave, its specification is part of the query:

ControllerContext controllerContext =
    (from context in Mocks.Query<ControllerContext>()
     where context.HttpContext.User.Identity.Name == "kzu" &&
           context.HttpContext.Request.IsAuthenticated == true && 
           context.HttpContext.Request.Url == new Uri("http://moq.me") &&
           context.HttpContext.Response.ContentType == "application/xml"
     select context)
    .First();
...

Read full article

Compile-time safety is always important, as it reduces the chances that a refactoring can break existing code that compiles successfully. This benefit took me previously to the path of using expression trees to achieve strong-typed reflection.

There is, however, an alternative that works on previous versions of .NET and doesn’t involve expression trees. It essentially involves creating a delegate of the target method, and using the delegate properties to get to the corresponding MethodInfo:

Action<string> writeLine = Console.WriteLine;
MethodInfo writeLineMethod = writeLine.Method;

Note that the code above is very explicit about which overload of the WriteLine method to pick: the one with a single string argument and a void return value. You can leverage Action and Func various overloads to represent pretty much any method invocation. Also, if those do not fit, you can still create your own delegate type. The benefit, clearly, is that you now can refactor the defining class or method and the change will be picked automatically....

Read full article