.Net

Visual Studio 2010 beta2 + Framework 4.0

Bill Tudor — Sun, 25 Oct 2009 22:48:55 GMT

Visual Studio 2010 beta2 + Framework 4.0

. . . with a few comments on Windows Virtual PC.

Installation

I don’t “work” on my laptop – mostly used for travel, library, watching Hulu and channel 9, etc. Since I will be out of town for a while, however, I decided to install VS20101b2 in a winVPC for the trip on the laptop. The only complaint about the new VPC offering from Microsoft is that when it is running, it takes forever for my notebook to initiate sleep mode. I don’t recall the old product having this issue.

Installation of 2010 was a breeze, especially Team Foundation Server (holy crap is that a different experience!). The new icon needs work – looks very bad in the new Windows 7 taskbar with the default theme.

First Impressions

The first thing I did was fire up the VM and connect to TFS server – all running on the laptop – in a 1GB VM, I might add. I create a new team project (‘TestProject’). This all worked. I seem to remember several days before I was able to accomplish this on tfs2005, and at least a few hours on tfs2008. Today’s elapsed time is a couple of minutes (for the TFS part).

Overall, I found a snappy IDE that has a finished feel to it. Nice. March release should be no problem.

Branching and Merging

I setup the TestProject with a typical branching and merging strategy (dev/main/prod), added a few work items and a bug, and got to work.

[ Note: I like the little ‘Save’ icon – saves a picture of the visualization] There seem to be lots of tools accessible from this UI, such as branch compare tools. Overall, this visualizer is a nice feature (the simple picture shown does not do justice). I’m still looking for the merge visualizations (update: found them!). I’d like to see merge arrows that are labeled per the changeset description and clickable to show history/changeset details for merges. It looks like I’ve got some exploring to do.

Team Web Access

I was not expecting this. Even in the Basic product running on a local client OS. Nice touch. It’s a beautiful source, work item, project browser web application. Who needs SharePoint?

New in Framework

I’ve already blogged a few times about changes in the Framework 4.0 beta. A few more in this release:

DLR library
Several more threading primitives
System.Collections.Concurrent namespace
MEF improvements
In-process side-x-side CLR

Static Reflection in .Net

Bill Tudor — Mon, 12 Oct 2009 17:08:21 GMT

Static Reflection in .Net

Where have I been?

I recently took a few minutes to look through the latest MSDN magazine and ran across a nice article by Jeremy Miller on “Functional Programming for Everyday .NET Development”. The section titled “Lambdas as Data” was my first introduction to static reflection in .Net. Where the heck have I been? I don’t write database persistence code, so I am not familiar with NHibernate (or fluent NHibernate) (which is where Jeremy’s sample comes from), but I am still surprised at how little I understand about everything Linq brought to the .Net party. A quick search around the internet reveals this topic is well-covered, and several years old.

Example Code

Suppose you have a need to dynamically discover properties on an object. Easy, right? After all, that’s what the System.Reflection namespaces is for! However..

Let’s look at a class named “SomeObject” with a property “SomeProperty”:

class SomeObject

    public string SomeProperty { get; set; }

You can use so-called “static reflection” like this:

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         SomeObject o = new SomeObject()

   6:         {

   7:             SomeProperty = "Test"

   8:         };

   9:         staticReflection(o, e => e.SomeProperty);

  10:         Console.ReadKey();

  11:     }

  12:     static void staticReflection<T>(T o, Expression<Func<T,object>> expression)

  13:     {

  14:         MemberExpression me = expression.Body as MemberExpression;

  15:         if (me != null && me.Member.MemberType == System.Reflection.MemberTypes.Property)

  16:         {

  17:             Console.WriteLine("Property: '{0}' of type '{1}' has value '{2}'.",

  18:                 me.Member.Name,

  19:                 expression.Body.Type,

  20:                 expression.Compile().Invoke(o)

  21:                 );

  22:         }

  23:     }

  24: }

The output is:

Property: 'SomeProperty' of type 'System.String' has value 'Test'.

Very cool. Now I need to understand why the second argument has to be something like Expression<Func<T, object>> rather than simply Expression<T>. If the latter is used, the compiler rewards me with:

Error 1 Cannot convert lambda to an expression tree whose type argument 'StaticReflection.SomeObject' is not a delegate type

It’s the whole “return type” thing on the delegate that throws me as well – where does that come from? In my code sample I have declared the Func return type as type “object” (it is actually a string in my case). Why don’t I have to do something like “e => {return e.SomeProperty;}”, and how come a lambda expression with a statement body like that cannot be converted into an expression tree (compiler’s words, not mine)?

I still have a little more learning to do before really understanding what’s going on here. My suspicion is that Linq brought a heck of a lot more to the party than it might appear at first look.

Three’s a Charm?

Bill Tudor — Fri, 02 Oct 2009 10:10:48 GMT

Three’s a Charm

It looks like the third iteration of Team Foundation Server might be a good one. I just finished reading Brian Harry’s post on TFS 2010 and it contains some interesting references.

SourceSafe Replacement?

I never could understand why TFS was often compared to SourceSafe. All the sessions on migrating from VSS to TFS, TFS for VSS users, etc. Is a team really going to migrate from VSS to TFS? Really? You have got to be kidding me! TFS is change management (to borrow a phrase from Rational), and VSS was barely version control.

… but now I think I get it …

All those VSS (or CVS, etc.) users were left stranded – there was no lightweight version control server for individuals (or very small teams). So they all went to SVN. Quick setup, version control, painful (but possible) branching and merging, command line, nice shell client, poor VS client, and all of that.

VSTS 2010

In steps Visual Studio Team System, Team Foundation Server, 2010.

Can run locally on Windows 7 and Windows Vista client OS’
Simple installation / Configuration
Can optional use SQL Server express edition
Can be installed on a domain controller
Stand-alone version includes Work Item Tracking, Version Control

Note that this stand alone version also appears to include the build server/services!

I assume with the new project collections feature, you could move your SQL Express database over to a real SQL Server when your team gets a bit bigger. And good pricing is also on the Redmond minds.

Looks to me like they did their research. And did it well.

Nice.

Running Command Line Tools from .Net

Bill Tudor — Tue, 22 Sep 2009 09:36:27 GMT

The Process class in .Net makes it easy to run command line tools from within a .Net program. Here is an implementation with a couple of twists:

Environment variable expansion
Optional asynchronous execution
Transformation of output into an enumerable collection of objects

The implementation takes the form of an object named CommandLineTool with the following constructors:

public CommandLineTool(string command)
    : this(command, String.Empty, Environment.CurrentDirectory, _defaultTransform) { }
public CommandLineTool(string command, string arguments)
    : this(command, arguments, Environment.CurrentDirectory, _defaultTransform) { }
public CommandLineTool(string command, string arguments, string workingDirectory)
    : this(command, arguments, workingDirectory, _defaultTransform) { }
public CommandLineTool(string command, string arguments, string workingDirectory, Func<string, object> transform)
{
    this.Command = Environment.ExpandEnvironmentVariables(command);
    this.Arguments = Environment.ExpandEnvironmentVariables(arguments);
    this.WorkingDirectory = Environment.ExpandEnvironmentVariables(workingDirectory);
    this.Transform = transform;
    _isBusy = false;
}

The simplest form provides for an executable filename only, while the last constructor accepts arguments, working directory, and transformation function for the output lines. Note that environment variables, such as "%ComSpec%, may be included in any of the first three arguments.

Output Transformation

Each line of output (strings) can be sent to a transformation function, defined as a Func<string, object>, and returned as an enumerable collection of objects (IEnumerable<Object>) accessed via the OutputObjects property. Output can also be expressed as a single string (Output) or an array of lines of text (OutputLines). These are exposed as properties. The transformation function is free to return null to exclude an item from the OutputObjects collection.

   1: /// <summary>

   2: /// Command output.

   3: /// </summary>

   4: public string Output { get; private set; }

   5: /// <summary>

   6: /// Command output lines.

   7: /// </summary>

   8: public string [] OutputLines

   9: {

  10:     get

  11:     {

  12:         if (Output != null)

  13:         {

  14:             return Output.Split(_seperators, StringSplitOptions.RemoveEmptyEntries);

  15:         }

  16:         return null;

  17:     }

  18: }

  19: /// <summary>

  20: /// Output Objects.

  21: /// </summary>

  22: /// <remarks>

  23: /// Output lines are converted to output objects using the transform

  24: /// function. The default transform functions results in an enumeration

  25: /// of the out lines (strings).

  26: /// </remarks>

  27: public IEnumerable<Object> OutputObjects

  28: {

  29:     get

  30:     {

  31:         if (Transform != null)

  32:         {

  33:             return OutputLines.Select(Transform).Where(o => o != null);

  34:         }

  35:         return null;

  36:     }

  37: }

Asynchronous and Synchronous Operation

Both asynchronous and synchronous modes of operation are provided. An event (ExecuteCompleted) is raised following the completion of an asynchronous execution. Overloads are provided for both the Execute() and ExecuteAsync() methods to allow for an alternate transformation function to be applied in successive calls. Only one asynchronous operation at a time is allowed. The asynchronous version simply calls on the synchronous version using a background thread from the thread pool. Error output is provided in a similar manner to standard output, except that there is no option for transformation of lines of text on the error output to objects.

   1: /// <summary>

   2: /// Execute the command.

   3: /// </summary>

   4: /// <param name="transform">Transform to apply to the output.</param>

   5: /// <returns>Command result.</returns>

   6: public int Execute(Func<string, object> transform)

   7: {

   8:     this.Transform = transform;

   9:     return Execute();

  10: }

  11: /// <summary>

  12: /// Executes the command.

  13: /// </summary>

  14: /// <returns>Command result.</returns>

  15: public int Execute()

  16: {

  17:     ProcessStartInfo info = new ProcessStartInfo();

  18:     info.FileName = this.Command;

  19:     info.Arguments = this.Arguments;

  20:     info.WorkingDirectory = this.WorkingDirectory;

  21:     info.CreateNoWindow = true;

  22:     info.UseShellExecute = false;

  23:     info.RedirectStandardError = true;

  24:     info.RedirectStandardOutput = true;

  25:     Process p = Process.Start(info);

  26:     Output = p.StandardOutput.ReadToEnd();

  27:     ErrorOutput = p.StandardError.ReadToEnd();

  28:     return p.ExitCode;

  29: }

  30: /// <summary>

  31: /// Execute the command asynchronously.

  32: /// </summary>

  33: /// <param name="transform">Transform to apply to the output.</param>

  34: public void ExecuteAsync(Func<string, object> transform)

  35: {

  36:     this.Transform = transform;

  37:     ExecuteAsync();

  38: }

  39: /// <summary>

  40: /// Execute the command asynchronously.

  41: /// </summary>

  42: public void ExecuteAsync()

  43: {

  44:     lock (this)

  45:     {

  46:         if (!_isBusy)

  47:         {

  48:             _isBusy = true;

  49:             ThreadPool.QueueUserWorkItem((WaitCallback)((state) =>

  50:             {

  51:                 int result = Execute();

  52:                 if (ExecuteCompleted != null)

  53:                 {

  54:                     ExecuteCompleted(this, EventArgs.Empty);

  55:                 }

  56:                 lock (this)

  57:                 {

  58:                     _isBusy = false;

  59:                 }

  60:             }));

  61:         }

  62:         else

  63:         {

  64:             throw new InvalidOperationException("Async operation in progress.");

  65:         }

  66:     }

  67: }

Using the Code

Using the code is fairly easy. Just create a new CommandLineTool object and call either the Execute() or ExecuteAsync() methods. Here is a snippet from one of the unit tests:

   1: string command = "cmd.exe";

   2: string arguments = "/c dir";

   3: CommandLineTool target = new CommandLineTool(command, arguments);

   4: int expected = 0;

   5: int actual;

   6: actual = target.Execute();

   7: Assert.AreEqual(expected, actual);

A more involved example (somewhat contrived) includes transformation of the results and asynchronous operations. [Results are transformed into FileObject objects].

   1: // The FileObject class ...

   2: internal class FileObject

   3: {

   4:     public DateTime ModifiedDate { get; set; }

   5:     public string Name { get; set; }

   6: }

7:

   8: // Code ...

9:

  10:     string command = "cmd.exe";

  11:     string arguments = "/c dir /s";

  12:     Func<string, object> transform = new Func<string, object>(s =>

  13:         {

  14:             DateTime modified = DateTime.MaxValue;

  15:             if (s.Length > 39 && DateTime.TryParse(s.Substring(0, 20), out modified))

  16:             {

  17:                 return new FileObject()

  18:                 {

  19:                     ModifiedDate = modified,

  20:                     Name = s.Substring(39)

  21:                 };

  22:             }

  23:             return null;

  24:         });

  25:     CommandLineTool target = new CommandLineTool(command, arguments);

  26:     target.ExecuteAsync(transform);

  27:     while (target.IsBusy) Thread.Sleep(0);

28:

  29:     List<FileObject> files = target.OutputObjects.Cast<FileObject>().ToList();

30:

  31:     ... etc ...

Hope this comes in handy for someone. Let me know if you see any errors/problems or room for improvement.

Microsoft .Net Framework 4.0

Bill Tudor — Tue, 08 Sep 2009 10:40:02 GMT

Below are a few thoughts on the upcoming framework 4.0. I am not sure if the feature set is finalized, but I’ll comment on what I think are some of the more interesting features being planned for this release, as seen in the beta.

Managed Extensibility Framework

Plug-in architectures are a fairly common pattern for many scenarios, and I have seen quite a few over the years. MEF seems to be a nice combination of plug-in/IoC container/Dependency Injection framework. It’s use in Visual Studio 2010 should prove to give this framework a leg-up. I’m looking forward to using it as a replacement to the typical roll-your-own plug-in architecture. Not sure if it will be used where a complete dynamically composed extensible application is called for, however, that is exactly the scenario that MEF is designed for. I’ll see how it works out for plug-ins, first, before jumping in with both feet.

Language Enhancements

Some of these are obvious improvements: Optional arguments, COM interop/PIA enhancements. Some are welcome, such as named parameters. As for the new dynamic language features in C# ... well, I’m not qualified to comment on that yet. Interoperability with dynamic languages is a good thing. Whether or not I’ll be writing “dynamic c#” in the near future remains to be seen.

Base Class Library

I’ve blogged about one new class, the Memory Mapped File, in the recent past. There are a host of additional improvements, including the inclusion of the Task Parallel Library (TPL) that I believe came out of Microsoft research and has been release in CTP form a few times. Code Contracts look interesting, but I seriously doubt I will be adding pre-conditions, post-conditions and the like to very much code. I suppose there is a use for this – for some types of code; but I don’t see it for typical use. I had some experience with Eiffel in the past and did not care for it.

More Framework, Less P/Invoke

I would like to see more framework and less P/Invoke, particularly for new technologies such as those introduced in Windows Vista. There are managed wrappers provided for many things from Microsoft, but how about adding Windows 7 stuff to framework 4.0? It’s fine that wrapper libraries appear on CodePlex, but I would like to see the kind of treatment you would get from including new APIs in the framework – the way the System.Net.Sockets namespace is not simply a wrapper around the Win32 sockets API. I know, it’s hard – but what else is windows except a platform for development? If I was looking for merely an OS to run standard applications on, I could look elsewhere. Windows is first and foremost an application development platform for me. And for applications, I prefer managed code. Leave the C code (and COM goo) for drivers and low-level applications like virus scanners.

Visual Studio 2010

This looks like a big change. I’ll probably be using this for R&D (and also at home). But will probably wait about a year (or more) before converting all development projects over to vs2010. Although the beta seems pretty solid, my experience is that the first of a major change (vs2002/2003, the initial vs2008) in the Visual Studio line is not the greatest (contrast to vs6, vs2005 and now 2008/SP1). I love two things: multi-targeting and the ability to run different visual studio versions side x side. I expect that experience to be kept in vs2010. This allows developers to install the new tools with “no fear”, committing to them down the road. Goes a long way to increase adoptability. All that being said, the C++ team is saying “10 is the new 6”, and MSBuild can now be used for C++ code, etc., etc. I’ll keep an eye on thing in 2010.

F#?

Don’t know about this one. I’m thinking that the pile of technologies that I am now “expert” in is getting a little too large. However, I believe in the mantra “learn a new programming language every year”. It can be a bit confusing to switch from maintaining classic C code, early C++ code (mostly C with sprinkles of C++, MFC/ATL), later C++ code (STL, etc.), some VB6 and VBscript in classic ASP or office apps; then perform new development in JavaScript, C#, Windows Forms, WPF, Silverlight, and ASP.net. with a sprinkling of objective C for an iPhone app or two (quite a mix of frameworks and languages in that sentence, but you get the idea). I love it all. I’ll have to work F# in somewhere, because a functional language perspective brings new thought patterns, which is always a good thing. I suppose I’m glad it’s in the box, although at first thought I might want IronRuby or IronPython in there instead. I don’t see any production apps developed in F# in the next year or two, but an R&D project is likely.

- - - -

I have to admit that I have not played all that much with the beta; been pretty busy over the past few months. But I’m looking forward to framework 4.0, and expect it will turn out to be a significant release.