Vagif Abilov's blog on .NET

ASP.NET Bundle from TypeMock

TypeMock is has announced ASP.NET Bundle (consisting of Isolator and Ivonna). Being TypeMock user and customer, I am distributing their announcement. The text below is not mine – it’s written by TypeMock and explains how to get a free ASP.NET Bundle license (if you hurry up, like me :-))

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

How to programmatically define known types in WCF

WCF behavior typically can be specified in three ways: using attributes, using configuration files and programmatically. Although KnownType concept also falls in this category, it is impossible to find any reference or example of how to define a WCF known type programmatically. One of the most comprehensive blog entries on this subject even called “All About Known Type” does not even mention that they can be controlled directly from the application code. Search in Microsoft’s WCF forum brought me a hint to add known types to a collection available at contract endpoint.

After a few trials and failures I came up with the following implementation:

1. On the server side known types must be added to the service host after its creation and before it is open:

ServiceHost host = new ServiceHost(typeof(CustomerManager), new Uri("http://localhost:8000/"));
foreach (var endpoint in host.Description.Endpoints)
{
    foreach (var operation in endpoint.Contract.Operations)
    {
        operation.KnownTypes.Add(typeof(MyDynamicallyAddedKnownType));
    }
}
host.Open();

2. On the client side known types are added after the creation of proxy:

foreach (var operation in proxy.Endpoint.Contract.Operations)
{
    operation.KnownTypes.Add(typeof(MyDynamicallyAddedKnownType));
}

This should do!

Disclaimer: I am not advocating use of known types! In fact, I dislike (or even hate) WCF known types. So this is just an excercise. In something we probably should not be making a part of our core design.

The Downfall of Agile Hitler

Write and execute unit tests, my friends. Automate it and don't fall in love with "Ignore" attribute. Or your will screw the whole empire! :-)

IntelliSense and ‘dynamic’

Kirill Osenkov has posted a simple example showing the code using forthcoming "dynamic" keyword that will come with C# 4.0. His example uses COM. Kirill summarizes the change:

1. Referencing EnvDTE.dll is not required anymore – you also don’t need using EnvDTE – don’t need to reference anything!
2. You declare the ‘dte’ variable to be weakly typed with the new dynamic contextual keyword
3. You don’t have to cast the instance returned by Activator.CreateInstance
4. You don’t get IntelliSense as you type in the last line
5. The calls to dte are resolved and dispatched at runtime

And concludes: "It’s a trade-off, but I still view dynamic as yet another useful tool in the rich C# programmer’s toolbox to choose from."

One of the comments points out: “I may know what the methods of DTE are, but the second solution will require *all* developers in my team to know it as well. While with IntelliSense they learn it as they need.”

I tend to agree. It’s not that I am conservative and don’t welcome language changes. I am for any innovation that fits language spirit and helps writing more compact and understandable code. But while “dynamic” concept will help in the cases where type cast is not available at compile time, I am not sure everyone will accept its trade-offs where use of strong types will be replaced with runtime type evaluation. Look at the Kirill’s C# 3.0 example. The VisualStudio DTE assembly is referenced and imported not because of DTE object instantiation – the call GetTypeFromProgID does not need any references, it goes directly to the registry. The whole purpose of referencing the assembly and importing EnvDTE namespace is to retrieve DTE type information at compile time. Will everyone easily sacrifice this? I am not sure about myself. Moreover, I can imagine coding guidelines in some companies where developers are instructed not to use dynamic types in the scenarios where type information can be obtained at compile time.

On the other hand, I like the idea of removing a reference to dynamically loaded assemblies. So what I would like to see is some kind of hint to an IntelliSense provider that could help with type information, something like this:

using System;
using dynamic("progid://VisualStudio.DTE.10.0")=DTE;

class Program
{
    static void Main(string[] args)
    {
        Type visualStudioType = Type.GetTypeFromProgID("VisualStudio.DTE.10.0");
        dynamic dte = Activator.CreateInstance(visualStudioType) as DTE;
        dte.MainWindow.Visible = true;
    }
}

I am no sure about the syntax, but you got the idea. You give a hint to IntelliSense about what kind of dynamic object you expect to create. If Visual Studio DTE assembly is installed and available on the development machine, IntelliSense will retrieve DTE methods and properties and list them for you as you type. If there is no such assembly, no IntelliSense help is provided, but the compilation will not fail. At runtime the code will work exactly as in Kirill's example: generated code will not be affected. Again, I am not sure about the syntax, especially about new interpretation of "using" directive. On the other hand, I feel that "using" section is a right place to put IntelliSense instructions, because this section does not affect runtime code execution.