A couple of things to note; this feature requires your application to run as an Out Of Browser (OOB) with elevated permissions. Also, there is no IntelliSense for your COM objects. So make sure you have the documentation to the API you are trying to use. So lets get started.

Creating an OOB Application

First thing you need to do is crack open VS 2010 Beta 2 and create a new Silverlight project. Make sure you are targeting the .NET Framework 4 it is a Silverlight 4 application.

For this test project we don’t need to host this in a website.

The next thing you need to do is right-click on the project and choose “Properties”.  Check the “Enable Running Application out of browser”

Now click the Out of Browser Settings button and set “Require Elevated Trust when running outside the browser.”

Next add a button to the application to install our OOB application.

<Button x:Name="btnInstall" Content="Install Me" Click="btnInstall_Click" />

if (Application.Current.InstallState == InstallState.NotInstalled)

               Application.Current.Install();

Now run the application and install it by clicking the install button you just created.  When you start the installation, you will be prompted to install the app, and whether or not you want to create some shortcuts. Just say yes, we trust ourselves, sort of.

The next thing we want to do is enable debugging our OOB application.  So right click your project and chose properties –> Debug –> Installed out of browser application –> YourApplication

The final step is to add a reference to Microsoft.CSharp.dll so we can use the dynamic keyword.  Look for it in C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\.  Now on to fun stuff.

Send an Email with Outlook

First create a form that will take your user input for the “To” and “Message” data, and a button to send the message.

<StackPanel>

    <StackPanel Margin="5">

        <TextBlock Text="To:" />

        <TextBox x:Name="txtTo" />

    </StackPanel>

    <StackPanel Margin="5">

        <TextBlock Text="Message" />

        <TextBox x:Name="txtMessage" Height="200" />

    </StackPanel>            

    <Button x:Name="btnSend" Content="Send Message" Click="btnSend_Click" />

</StackPanel>

Then handle the button click event as follows.

private void btnSend_Click(object sender, RoutedEventArgs e)

{

    using (dynamic outlook = ComAutomationFactory.CreateObject("Outlook.Application"))

    {

        dynamic mail = outlook.CreateItem(0);            

        mail.To = txtTo.Text;

        mail.Subject = "Hello, from Silverlight";

        mail.HTMLBody = txtMessage.Text;

        mail.Display();

    }

}

And you done.  Of course this will only display the message, but just call mail.Send() to actually send it; one thing to mention is to make sure you have Outlook open when you hit send or bad things will happen.

Send Data to Excel, edit it, and update Silverlight

Now this little trick is cool. We will have a data source, send it to excel for display and editing, then send the updated data back to our Silverlight application and update the UI.  Now this is a poor mans implementation for demo reasons.

First lets create our UI and populate it with data.  This is what mine looks like.

Lets code up the Launch Excel button.

bool firstTime = true;

private void LaunchExcel(object sender, RoutedEventArgs e)

{

   // create an instance of excel

   dynamic excel = ComAutomationFactory.CreateObject("Excel.Application");

   excel.Visible = true;  // make it visible to the user.

   // add a workbook to the instance 

   dynamic workbook = excel.workbooks;

   workbook.Add();

   dynamic sheet = excel.ActiveSheet; // get the active sheet

   dynamic cell = null;

   int i = 1;

   // iterate through our data source and populate the excel spreadsheet

   foreach (Entity item in CustomerList.ItemsSource)

   {

       cell = sheet.Cells[i, 1]; // row, column

       cell.Value = item.CustomerName;

       cell.ColumnWidth = 25;

       cell = sheet.Cells[i, 2];

       cell.Value = item.UnitSales;

       i++;

   }

   // add a chart

   dynamic sheetShapes = sheet.Shapes;

   sheetShapes.AddChart(-4100, 200, 2, 400, 300);

   // wire up an event handler to the Excel SheetChanged event

   if (firstTime)

   {

       excel.SheetChange += new SheetChangedDelegate(SheetChangedEventHandler);

       string sheetName = sheet.Name;

       firstTime = false;

   }

   ExcelButton.IsEnabled = true;

}

As you can see we are hooking into the Sheet changed event so we can respond to when the data is update in excel. So here is the code for that.

delegate void SheetChangedDelegate(dynamic excelSheet, dynamic rangeArgs);

// event handler for the sheet changed event

// looks at the data and creates a new items source to rebind to the datagrid

private void SheetChangedEventHandler(dynamic excelSheet, dynamic rangeArgs)

{

    dynamic sheet = excelSheet;

    string sheetName = sheet.Name;

    dynamic range = rangeArgs;

    dynamic rowValue = range.Row;

    Entity[] entities = CustomerList.ItemsSource as Entity[];

    Entity[] newEntities = new Entity[10];

    dynamic col2range = sheet.Range("B1:B10");

    for (int i = 0; i < 10; i++)

    {

        Entity newEntity = new Entity();

        newEntity.CustomerName = entities[i].CustomerName;

        newEntity.PhoneNumber = entities[i].PhoneNumber;

        dynamic item = col2range.Item(i + 1);

        newEntity.UnitSales = Convert.ToInt32(item.Value);

        newEntities[i] = newEntity;

    }

    CustomerList.ItemsSource = newEntities;

    CustomerList.SelectedIndex = Convert.ToInt32(rowValue) - 1;

    UpdateNotification.Text = "Data updated from Excel spreadsheet";

}

Now, I will click the Launch Excel button, and edit my data.

Now if I look back in my Silverlight application, I will now see that all of my data in the grid has been updated.

Lets Open a Program

Using the WScript.Shell API we can execute any command and open any program.  In this example lets open Notepad and write some text to it.  So first I am going to create a simple UI to allow a user to enter some text, then click a button to send it to Notepad.

<StackPanel>

   <TextBlock Text="Enter text to send to NotePad." />

   <TextBox x:Name="txtTextToSend" />

   <Button x:Name="txtOpenProgram" Content="Open NotePad" Click="txtOpenProgram_Click"  />

</StackPanel>

private void txtOpenProgram_Click(object sender, RoutedEventArgs e)

{

    using (dynamic shell = ComAutomationFactory.CreateObject("WScript.Shell"))

    {

        shell.Run(@"C:\windows\notepad.exe"); //you can open anything

        shell.SendKeys(txtTextToSend.Text);

    }

}

Now lets enter some text and click that button.

Now that’s pretty cool. I am sure your mind is thinking of all the cool stuff you can do with this.

Well, this stuff is cool and all, but where is the really cool stuff? Wait no more!

Text to Speech

That’s right, I said it.  I am going to use the SAPI.SpVoice API to tap into the power of text to speech. So lets build a UI that will allow a user to enter some text. Heck lets let them control the rate and pitch of the speech.

<StackPanel>

    <TextBlock Text="Enter text to say: " />

    <TextBox x:Name="txtTextToSay" Margin="0,0,0,20" />

    <TextBlock Text="Pitch" />

    <Slider x:Name="sldrPitch" Minimum="-10" Maximum="10" Value="0" />

    <TextBlock Text="Rate" />

    <Slider x:Name="sldrRate" Minimum="-10" Maximum="10" Value="0" />

    <Button x:Name="btnSpeak" Content="Speak" Click="btnSpeak_Click" Margin="20" />

</StackPanel>

This should look something like this.

Lets hook up our button’s click event and make some noise.

private void btnSpeak_Click(object sender, RoutedEventArgs e)

{

   using (dynamic ISpeechVoice = ComAutomationFactory.CreateObject("SAPI.SpVoice"))

   {

       ISpeechVoice.Volume = 100;

       ISpeechVoice.Speak(string.Format("<rate speed=\"{0}\"><pitch middle=\"{1}\">{2}", Math.Round(sldrRate.Value), Math.Round(sldrPitch.Value), txtTextToSay.Text));

   }

}

If you wanted to you could create a volume control for it as well.

What? This still isn’t cool enough for you? Well I think I can satisfy your need for coolness. Enter:

Acquire an Image from your Scanner/Camera

That’s right I said it.  You can access your scanner, scan an image, and then save it to your hard drive.  Here we are using the WIA (Windows Image Acquisition). “WIA is a full-featured image manipulation component that provides end-to-end image processing capabilities.  The WIA Automation Layer makes it easy to acquire images on digital cameras, scanners, or Web cameras, and to rotate, scale, and annotate your image files.” So, enough with the talking, lets get coding.

First all I need to do it create a button that will initiate the process.

<Button x:Name="btnAquireImage" Content="Aquire Image from Scanner/Camera" Click="btnAquireImage_Click" />

Now we need to handle the button’s click event and do all the complicated code.

private void btnAquireImage_Click(object sender, RoutedEventArgs e)

{

   using (dynamic CommonDialog = ComAutomationFactory.CreateObject("WIA.CommonDialog"))

   {

       dynamic imageFile = CommonDialog.ShowAcquireImage();

       if (imageFile != null)

       {

           string filePath = string.Format("D:\\{0}.jpg", Guid.NewGuid());

           imageFile.SaveFile(filePath);

           MessageBox.Show(string.Format("Saved {0}", filePath));

       }

   }

}

So what does this actually do?  Well lets push the button and find out:

Well the first thing it does is asks me which device I want to get my images from.  Lets pick my scanner.

Well, holly crap, that’s my scanner. And I can preview and crop my image before I even get the image. Yes, that is my baby picture, it was the only thing I could find OKAY!  All my current pictures are digital.  Anyways, so once I like my settings I click scan, the scanner will do its thing and my image will be saved.

And there it is right where I told it to save.  How fun is that? I did you a favor and already coded all this up and packed it up in a nice little zip file.  So download the code, play with it, and write some kick ass applications!

I almost forgot to mention, when you open the source code, go into Properties –> Debug –> and select “Dynamically create the page”, then run the application, install it, and go back and change the option back to “Installed out of browser application ”.

Folks, this product is getting better. That stands to reason. After all, this is basically version 3 of the product and you know what they say! Version 3 is the one to buy. Most of the kinks are worked out now.

Now, I won’t pretend for a moment that Team Foundation Server hasn’t had its challenges fitting in with agile teams. I think that has come from a history of development by a team that itself was learning and growing just like the rest of us. Now that many of the teams within Microsoft are practicing some form of iterative development with completed cycles of “all the way done”, we are starting to see the influence in the tools they are producing. And the effect is not half bad.

I have been using Visual Studio 2010 for a few months now, and with the recent release of the RC, I can see:

1. Performance is getting better (XAML).
2. Features are getting more solid (fewer exceptions)
3. The polish of the overall user experience is becoming a great example of an application I am happy to look at all day long.
4. The Team Foundation Server features being added are consistent with what we are learning to be effective as an agile community.

So, where’s the meat? What are these shiny features of which you speak, Mr. Starr? Well, here is a short sample because I am sitting in an airport listening to the chaos and I can’t think of it all.

I should also say that this is a very small list of features that I personally am really excited about. The rest of the world probably has other things they care about. These are mine because I believe they have to potential to really change life on a team for the better.

Layer Diagrams

There is a major focus in this release to add UML support to Visual Studio Ultimate. OK, not a huge fan and I know some people will dog on this feature, but I am all about the Layer Diagrams. These are diagrams that we can create just like the UML diagrams that Visual Studio now supports, but the value of a Layer Diagram is that it has teeth and can bite back.

Here’s how it works:

1. Create a Layer Diagram.
2. Draw your favorite design pattern or desired architectural separation model using tools in the Toolbox. In a simple example, this might be to create a model of the MVP pattern. In a large example this model might show the multiple layers in my solution that uses CSLA, Silverlight with MVVM, WCF, and Entity Framework. (Hi, Scott J You knew that was for you.)
3. Add some things to it from your solution. Drop things onto the diagram and into the boxes like classes, namespaces, and Visual Studio projects.
4. Now you can generate dependencies between these things and see the existing relationships. Yawn. Cool, but we get this with dependency diagrams, too.
5. Validate the model.
   
   Wait for it. . . Grok it. . .

   
   You got it! Yeah, that’s right. Validate the LOGICAL model of your application. This is so sweet it comes on a stick. This means that not only can I verify I haven’t violated my design with a bad reference or super egregious abstraction hole, but I can make this validation part of the build process and catch it if I accidently violate my own design later. Where I come from, they call that cool.

Way Better Work Items

This is non-trivial for teams who live every day of their lives in Team Foundation Server to manage their requirements and work queues. Sure, we might all prefer note cards on the wall, but for many this is simply not possible. And for those folks who use Team Foundation Server to manage their notecards, there are some great new things to make that task easier.

1. Hierarchical relationships between Work Items.
2. Agile planning Workbooks.
3. Seamless Team Project Dashboards.
4. MSF Agile 5.

Gated Check In

This is a feature of Team Foundation Build that will actually build and test your software before a check-in is committed to Source Control. The mechanical effect of this is simple: Code that would break the build is never committed to Source Control. The implications are far larger, though. Think it through for a moment. What would change in your daily life if you flat out were unable to commit code that breaks the build? The short answer is, “Quality goes up.” I bit more verbose answer is that I need to be more careful before committing my code.

Yes, I know other vendors have had this feature for a while. So what? So, Team Foundation Server shouldn’t have it too? It rocks and now we get it in Team Foundation Build.

IntelliTrace

I am not even sure how cool this is yet, only that it is. This feature is also known as Historical Debugging and gives the ability to step back and forth through call stacks and watched variables during a debug run. To be clear, that’s Back and Forth through time. So, the first time I hit the breakpoint, here was the status of the code. The second time it was this. And so on. Also, I can inspect all this data on system events (like CLR events) and can therefore tap into my app at a lot of different levels.

Now, I know that you don’t need debuggers anymore because every line of code we write is Test Driven and that means we don’t need debuggers, right? Yeah, sure you never need a debugger. As I said, this is just a wicked tool, but I am not yet sure how wicked. The community will definitely ferret that out over time.

Other Stuff

This only scratches the surface of what’s in Visual Studio and Team Foundation Server 2010. There are a lot more things, many of them bigger and higher profile than the things I mentioned. I just happen to be in love with these particular features at the moment. As I get deeper into things, I will let you know what I see.

One last thing, I know these tools get a lot of flak in some communities, but I feel comfortable with them. I also understand that many developers out there in the world don’t get to choose their tools. Often tools are assigned. What I see is that the 2010 versions of Visual Studio and Team Foundation Server really have raised the bar. I don’t feel like teams are still having to compromise on tooling to get everything they need in an integrated environment.

Will I still run R#? Well, yeah.

Summary of big long story to at least give a little context as to why (yet another post on optional parameters):

I threw an idea out to the Moq discussion group of how we could use the named/optional parameters in a future version of Moq. (you can read the thread here) In my original feature request I displayed my lack of concrete knowledge in the named/optional parameters support that is eventually coming with .net 4.0.

Once I learned that you could place default values on interfaces it left me with questions… So, what better way to figure them out? Go test it…

Disclaimer: (Shouldn’t every blog have some context enlightening disclaimer?)
I haven’t looked up best practices or lessons learned from people that have had this language feature (VB), so I’m just doing this as an experiment for myself. Hope some of my findings help the other C#’ers wanting to learn a little about the feature.

What are optional parameters?

DimeCasts.Net, Derik Whittaker has a nice intro video # 153 – Exploring .Net 4 Features – Named and Optional Parameters

OR check out – http://tinyurl.com/yz3pc9o

Can an interface define a default value?

Yes!

Can I specify a default in the concrete implementation, if the interface has a default also?

Yes!

What happens when the concrete implementation has a different default value than the interface’s default?

If the interface has a default value specified, that is different from the concrete implementation, then it depends on what reference you’re using when executing the method.

In the case below we are executing the method directly off of the Foo instance and will therefore get the concrete implementation’s default value when executing.

(new Foo()).Bar() – would use the value of ‘1000’.

And in the case below we cast the Foo instance to an IFoo and it will then use the interfaces default value when executing.

((IFoo) new Foo()).Bar() – would use the value of ‘1’.

Below are some examples of the different use cases.

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void Should_get_the_concrete_class_default_value()
    {
        Foo f1 = new Foo();
        f1.Bar();
        f1.ParamValue.ShouldBeEqualTo(1000);
    }

    [TestMethod]
    public void Should_get_the_interface_default_value()
    {
        IFoo f = new Foo();
        f.Bar();
        f.ParamValue.ShouldBeEqualTo(1);
    }

    [TestMethod]
    public void Should_get_the_interface_default_value_because_of_explicit_cast()
    {
        Foo f = new Foo();
        ((IFoo)f).Bar();
        f.ParamValue.ShouldBeEqualTo(1);
    }

    [TestMethod]
    public void Should_get_the_concrete_class_default_value_because_of_explicit_cast()
    {
        IFoo f = new Foo();
        ((Foo)f).Bar();
        f.ParamValue.ShouldBeEqualTo(1000);
    }
}

interface IFoo
{
    int ParamValue { get; }

    void Bar(int paramValue = 1);
}

class Foo : IFoo
{
    public int ParamValue { get; private set; }
    public void Bar(int paramValue = 1000)
    {
        ParamValue = paramValue;
    }
} 

The next experiment – Extract Interface.

Next I tried removing the IFoo interface that I’d created manually, because I wanted to exercise the “Extract Interface…” functionality, just to see how it dealt with the these defaults.

Luckily, there were no surprises. The interface it created was exactly (less spacing) the same as I originally had.

Although it didn’t display the default constant value in the dialog during creation, there was a hint that the method signature had a default by placing [] around the int resulting in “Bar([int])”.

Side Tool Issue: Can’t say I like how it forced me to put the interface in a different file, I guess it’s enforcing “best practice” here, but I prefer to do this later in the dev cycle than immediately (kind of like how R# allows you to place in the file next to the original class). #ToolGettingInWay

Optional Parameter Issue: One issues I see with this solution was the dirty/icky copy/paste feeling I got when extracting the interface – the default was copied from the class to the interface.

Possible solutions to the “dirty/icky copy/paste feeling” the extract interface gives.

(in no particular order of preference)

• Place all defaults into a constant and reference the constant in both the interface and the concrete implementation(s).
• Don’t place the defaults in the concrete implementation (only in the interface). As you should probably not be depending on the concrete implementation to begin with, you wouldn’t need it there (and wouldn’t even call it). This would also help in the case that there are multiple concrete implementation and having to sift through the code looking for all instances to updated defaults for could be very error prone.

On the surface named parameters seem like a very simple feature to the C# language. But after delving into the feature a little, I can see there are many complicated scenarios you can get your self caught up into.

As with anything…Use with care!