All About Interop : Not Really Interop

Enable .NET 3.5 goodies in IIS vdir

DotNetInterop — Fri, 05 Dec 2008 20:29:00 GMT

Some of you may be oddballs like me: you like .NET, you program in .NET, but you don't always use Visual Studio. You hand-code everything for some applications. You often open up a text editor and just start writing a source module, with no wizards, no project templates, etc. You hand-code your MSbuild files. You hand-code your web.config files.

Oddballs like us cannot rely on the code-generation that comes with Visual Studio. So when we write a new ASP.NET application, and we want to use the .NET 3.5 goodies in that app - things like var types, and LINQ - we need to explicitly specify that we want .NET 3.5 compilation. Same is true if you are writing a WCF service and want to use REST or any of the var types or LINQ.

I've done this twice now and had to search for the way to do it both times. I'm putting here as a "note to self" and also as a reference for anyone else. These are the custom magic incantations for web.config, if you want to enable .NET 3.5 in your ASP.NET app, or in your WCF Service - eg, the cool REST stuff from .NET 3.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>

  <system.web>
    <compilation debug="false">  
      <assemblies>  
        <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>  
        <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
        <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>  
      </assemblies>  
    </compilation>  
  </system.web>


  <system.codedom>  
    <compilers>  
      <compiler language="c#;cs;csharp" extension=".cs"   
                type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"   
                type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"   
                warningLevel="4">  
        <providerOption name="CompilerVersion" value="v3.5"/>  
        <providerOption name="OptionInfer" value="true"/>  
        <providerOption name="WarnAsError" value="false"/>  
      </compiler>  
    </compilers>  
  </system.codedom> 

</configuration>

Profiles in Microsoftee-hood

DotNetInterop — Tue, 16 Sep 2008 17:19:00 GMT

I hadn't seen Microspotting before - consider me educated. It's a blg site run by a Microsoft employee that profiles... Microsoft employees.

Enough about you. Let's talk about me!

Yeah, it's self-centered, but despite that I found the blog to be well written and I expect it will be really interesting, for MS employees as well as outsiders. I especially liked the looks inside the different offices, like the tour of the new west-side South Lake Union office in Seattle. I even found some profiles of colleagues of mine in there, which is pretty neat. The profile on Shawn Burke and the Reference Source project was nice to see.

On the about page it says the blog site runs on some non-specified open source content management system. I wonder what it is, and I wonder if there is any interop story there?

Anyway, Check out Microspotting.

What is Scalability? Do I have Extreme Requirements?

DotNetInterop — Thu, 17 Jul 2008 22:22:00 GMT

Can I turn my Volvo into an F1 Racer?

I am a fan of auto racing. I started following racing way, way back. At the low end of the spectrum, anyone with a car can get started racing in autocrosses and track days, for not very much money. At the other end of the spectrum, the pinnacle of the sport, the very top, is Formula One. It's a racing series in which teams field two cars, and they can spend hundreds of millions of dollars for a single season. The cars are very lightweight and produce over 850bhp of power from what engineers would call a "traditional" internal combustion engine, of 2.4 liters displacement. That by the way, is the same displacement engine used in my 1994 Volvo wagon, which delivers about 150bhp, but weighs about 2.5x as much as an F1 racer.

If I am into acceleration, that comparison should make me very sad. Remembering Newton's Second Law of motion, gold old F=ma, I know that acceleration, in automobiles, is proportional to the power-to-weight ratio of the car. More power means more acceleration. Less weight means more acceleration. The F1 car has a 15x advantage in power-to-weight ratio over my car. Yow. That's horrible.

If I wanted to add a little more spice to my morning commute, maybe I should think about learning from the F1 McLaren team, and using some of that technology in my Volvo? Would that work? Let's see.

The F1 engine has a peak internal speed of 19,200 RPM, whereas my Volvo redlines at 7000 RPM. Because the F1 engine has such extreme speeds, the friction generated by it is extreme, and the temperatures, too. The exhaust temperature on an F1 car can reach 1000F. Imagine pulling up to the quickie mart with a glowing-red hot exhaust pipe sticking out. It would be a huge safety issue. Speaking of exhaust, the pipes are custom made, and cost maybe USD$12,000 a pop. The entire engine goes for maybe USD$200,000. The noise generated by an F1 engine can reach 120 db at 20 feet away. That might be a problem for my neighbors. The fuel economy of an F1 car is around 3 mpg. Before you start an F1 engine, you need a team of people to pre-heat it; the tolerances are so close that starting a cold engine would damage it. And on and on.

Hmm, okay. So this all might get kinda impractical. Maybe pinnacle-of-the-industry technology is not right for me.

Where does Scalability Come From?

On a completely unrelated note, Dare is continuing to blog on protocols. This time he takes on the idea that Google's Protocol Buffers bring Scalability and Speed from Scott Loganbill.

Dare writes:

The fact that Google uses MapReduce and BigTable to solve problems in a particular problem space does not mean those technologies work well in others. MapReduce isn't terribly useful if you are building an instant messaging service. Similarly, if you are building an email service you want an infrastructure based on message queuing not BigTable. A binary wire format like Protocol Buffers is a smart idea if your applications bottleneck is network bandwidth or CPU used when serializing/deserializing XML. As part of building their search engine Google has to cache a significant chunk of the World Wide Web and then perform data intensive operations on that data. In Google's scenarios, the network bandwidth utilized when transferring the massive amounts of data they process can actually be the bottleneck. Hence inventing a technology like Protocol Buffers became a necessity. However, that isn't Twitter's problem so a technology like Protocol Buffers isn't going to "help them scale". Twitter's problems have been clearly spelled out by the development team and nowhere is network bandwidth called out as a culprit.

I completely agree. We can all get a little sloppy. "If it works for THEM, it's probably the perfect thing for ME." Nope. That is a dangerous habit to get into. Are we F1 racers, or commuters, or something in between? Can we tolerate the costs, the 1000F exhaust temperatures and the extreme noise of an F1-class infrastructure? Probably not We need to be more thoughtful about our requirements. Technology does not always transfer downward effectively from the pinnacle of any industry.

Dare also asserts,

If someone tells you "technology X doesn't scale" without qualifying that statement, it often means the person either doesn't know what he is talking about or is trying to sell you something. Technologies don't scale, services do.

I think what he means by "services" in this context is "implementations". Even so, I cannot completely agree here. Some technologies just don't scale well. On the other hand, to say that "XML doesn't scale", as Mr Loganbill seems to do, asks us all to ignore the success XML has enjoyed since the late 90's. It scales, up as well as down. From my mobile phone to the datacenter. Does XML solve all problems? No. Google had some particular data-shipping scenarios for which XML was not an optimal solution. We can conclude "XML did not meet the requirements of Google in some particular cases." That does not mean "XML does not scale." To draw that general conclusion is to deny the reality of the internet today.

There's an exponential decay curve that describes the scalability requirements for all apps in the world, where the Y-axis can be any aspect of scalability: number of users, petabytes of data handled, number of transactions, and so on.

Your app, dear reader, is probably not in the first 25% of that curve. Google's is. But yours probably isn't. Google's network is at the pinnacle of the industry. The most extreme requirements. Are you at that point? Probably not. And even if you are, you ought to examine your own requirements closely, rather than just "doing with the other guy did." This all goes to show that just because Google believes that Protocol Buffers (or whatever - you pick the particular technology choice) is the most effective solution for their particular problem space, does not mean that the given technology choice is the right one for YOU too.

Getting back to F1: it's true that some technologies have migrated from F1 to passenger cars. For example, now it is possible to get cars with carbon-ceramic disc brakes, just like an F1 car. Some cars have flippy-paddle shifters, just like an F1 car. But... not everything translates so readily. And even with those technologies, there is a cost/benefit analysis that is worth doing. Do I need ceramic brakes or can I just buy commodity cast-iron discs for much less cost? (If you know me, you know the choice I made here).

Technology that is just perfect for an F1 racer, is probably not exactly right for the commuter.

.NET Terrarium - it's BAAAAAACK!

DotNetInterop — Thu, 17 Jul 2008 01:39:00 GMT

Remember Terrarium? It was a .NET 1.0 learning tool disguised as a game. Microsoft released a developer's kit, and and people built herbivores, carnivores, or plants and introduced them into a peer-to-peer, networked ecosystem where they interacted and sometimes competed for survival. There was a visual display element of course. It was kinda like SimCity crossed with a .NET Tutorial, all run on a peer-to-peer network. People had a ton of fun with it; there were competitions and Terrarium events, it really captured the attention of the community.

Well,......... it's back!

A fella by the name of Bill Simser has resurrected Terrarium, put it on CodePlex, and is inviting participation! Terrarium 2.0 demonstrates some of the features of the .NET Framework, including Windows Forms integration with DirectX®; XML Web services; support for peer-to-peer networking; support for multiple programming languages; the capability to update smart client (Windows-based) applications via a remote Web server; and the evidence-based and code access security infrastructure.

Read about it here http://weblogs.asp.net/bsimser/archive/2008/07/16/reintroducing-terrarium-now-with-2-0-goodness.aspx.

If you want to try your hand at producing a critter, Bill's got a Terrarium server up and running already.

This could be a fun, engaging, and collaborative way to introduce .NET programming skills into your company or organization.

On the other hand, if you ever wanted to participate in the construction of a peer-to-peer mesh, contributing to the Terrarium project on Codeplex could be your chance!

[Edit: Just one thing - Terrarium in its current form depends on DirectX 7 (yes, it's THAT old) which Vista does not have. So if you are wanting to install this on Vista, you will need to take special action. ]

Interesting - CacheMan for .NET

DotNetInterop — Fri, 25 Apr 2008 22:58:00 GMT

A distributed object cache (distributed hashtable) for .NET

http://www.sriramkrishnan.com/blog/2008/02/cacheman-fast-distributed-hashtable-for.html

Powershell script to batch-update AssemblyInfo.cs with new Version

DotNetInterop — Mon, 21 Apr 2008 18:15:00 GMT

I wrote this script to update all the AssemblyInfo.cs files in a Visual Studio solution, to have the same version number. This is the kind of thing I would have used Perl to do, in the past. But Powershell's got this covered nicely.

[ 23 April 2008 - 1150am PST - I updated the script to deal with the AssemblyInfo.vb files in a VB project, and also to deal with version numbers that have less than 4 digits. Thanks for the suggestion, Jason! ]

Maybe someone can learn from this.

# SetVersion.ps1
#
# Set the version in all the AssemblyInfo.cs or AssemblyInfo.vb files in any subdirectory.
#
# usage:  
#  from cmd.exe: 
#     powershell.exe SetVersion.ps1  2.8.3.0
# 
#  from powershell.exe prompt: 
#     .\SetVersion.ps1  2.8.3.0
#
# last saved Time-stamp: <Wednesday, April 23, 2008  11:46:40  (by dinoch)>
#


function Usage
{
  echo "Usage: ";
  echo "  from cmd.exe: ";
  echo "     powershell.exe SetVersion.ps1  2.8.3.0";
  echo " ";
  echo "  from powershell.exe prompt: ";
  echo "     .\SetVersion.ps1  2.8.3.0";
  echo " ";
}


function Update-SourceVersion
{
  Param ([string]$Version)
  $NewVersion = 'AssemblyVersion("' + $Version + '")';
  $NewFileVersion = 'AssemblyFileVersion("' + $Version + '")';

  foreach ($o in $input) 
  {
    Write-output $o.FullName
    $TmpFile = $o.FullName + ".tmp"

     get-content $o.FullName | 
        %{$_ -replace 'AssemblyVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewVersion } |
        %{$_ -replace 'AssemblyFileVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewFileVersion }  > $TmpFile

     move-item $TmpFile $o.FullName -force
  }
}


function Update-AllAssemblyInfoFiles ( $version )
{
  foreach ($file in "AssemblyInfo.cs", "AssemblyInfo.vb" ) 
  {
    get-childitem -recurse |? {$_.Name -eq $file} | Update-SourceVersion $version ;
  }
}


# validate arguments 
$r= [System.Text.RegularExpressions.Regex]::Match($args[0], "^[0-9]+(\.[0-9]+){1,3}$");

if ($r.Success)
{
  Update-AllAssemblyInfoFiles $args[0];
}
else
{
  echo " ";
  echo "Bad Input!"
  echo " ";
  Usage ;
}

MSBuild script for compiling each .cs file into an EXE

DotNetInterop — Wed, 16 Apr 2008 20:53:00 GMT

I previously wrote about using MSBuild to build all .cs files in a directory into a single exe. Here's a companion script that builds every .cs file into a separate exe.

This might be helpful for directories where you keep sets of small projects, where each source file stands alone, that sort of thing.

(I'm posting these things just as simple illustrations to help people along with their own MSBuild things)

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
         DefaultTargets="CompileEach"
         ToolsVersion="3.5"
         >

  <!-- This build file compiles each .cs file into its own exe -->

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <!-- Import Project="c:\.net3.5\Microsoft.Csharp.targets" /    -->

  <PropertyGroup Condition="'$(Configuration)'==''">
    <Configuration>Debug</Configuration>   <!-- Default -->
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)'=='Debug'">
    <Optimize>false</Optimize>
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>.\bin</OutputPath>
  </PropertyGroup>

  <!-- Specify the inputs by type and file name -->
  <ItemGroup>
    <CSFile Include="*.cs" />
  </ItemGroup>

  <!-- specify reference assemblies for all builds in this project -->
  <ItemGroup>
    <Reference Include="mscorlib" />
    <Reference Include="System" />
    <Reference Include="WindowsBase" />
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="System.Printing" />
    <Reference Include="ReachFramework" />
  </ItemGroup>

  <Target Name="CompileEach"
          DependsOnTargets="ResolveAssemblyReferences"
          >

    <!-- ResolveAssemblyReferences resolves the short names of the assemblies -->
    <!-- named in the @(Reference) vector, into fully-qualified DLL names.    -->
    <!-- The task is defined in the Microsoft.Csharp.targets file.            -->
    <!-- The output of it is the @(ReferencePath) vector.                     -->

    <Message Text="Reference = @(Reference)" />
    <Message Text="ReferencePath = @(ReferencePath)" />

    <!-- Message Text="MS Build Tools path:  $(MSBuildToolsPath)" / -->

    <!-- Run the Visual C# compilation on EACH .cs file. -->
    <!-- see http://msdn2.microsoft.com/en-us/library/s5c8athz.aspx  for more info    -->
    <!-- By using the %(CSFile.identity) scalar, we run this task once for each       -->
    <!-- file.  The converse would be @(CSFile.identity).  That would run the compile -->
    <!-- once, for all files, compiling them all together into a single assembly.     -->
    <!-- Not what we want here.                                                       -->

    <CSC 
       Sources="%(CSFile.Identity)"
       References="@(ReferencePath)"
       OutputAssembly="$(OutputPath)\%(CSFile.filename).exe"
       EmitDebugInformation="$(DebugSymbols)"
       Toolpath="$(MSBuildToolsPath)"
       Nologo="true"
       >
    </CSC>
  </Target>

</Project>

To use it, run this:
c:\windows\Microsoft.NET\Framework\v3.5\msbuild.exe build.xml

WPF invokes Powershell.exe as an inferior shell

DotNetInterop — Fri, 11 Apr 2008 18:49:00 GMT

I wrote this up as an example of how to run powershell.exe as an inferior shell from within a WPF app.

It is not a "Powershell host" in the normal sense of the word, with a RunSpace and a RunSpaceFactory and so on. Instead, this example uses System.Diagnostics.Process to start powershell.exe as a process, and redirect stdin, stdout, and stderr. The result of those things is displayed in a WPF TextBlock.

The key bit is the Shell class, which I show here. It includes async i/o for the output.

    1 using System;
    2 using System.Collections.Generic;
    3 using System.Linq;
    4 using System.Text;
    5 
    6 namespace WPF_Host_for_PowerShell
    7 {
    8     class Shell
    9     {
   10         public delegate void OutputReceived(String output);
   11 
   12         private System.Diagnostics.Process _p;
   13         private System.AsyncCallback _rc = null;
   14         private System.IO.StreamWriter _sw;
   15 
   16         public System.IO.StreamWriter Input { get { return _sw; } }
   17         public OutputReceived StdoutOutputReceived { get; set; }
   18         public OutputReceived StderrOutputReceived { get; set; }
   19 
   20         public Shell(String exe, string args, OutputReceived callback1, OutputReceived callback2)
   21         {
   22             _rc = new System.AsyncCallback(ReadCompleted);
   23             StdoutOutputReceived = callback1;
   24             StderrOutputReceived = callback2;
   25             Launch(exe, args);
   26         }
   27 
   28 
   29         public class StreamState
   30         {
   31             public System.IO.Stream Stream;
   32             public byte[] Buffer;
   33             public OutputReceived Callback;
   34 
   35             public const int DefaultBufferSize = 2048;
   36 
   37             public StreamState(System.IO.Stream stream, OutputReceived callback)
   38             {
   39                 Buffer = new byte[DefaultBufferSize];
   40                 Stream = stream;
   41                 Callback = callback;
   42             }
   43         }
   44 
   45 
   46         private void ReadCompleted(System.IAsyncResult asyncResult)
   47         {
   48             StreamState state = (StreamState)asyncResult.AsyncState;
   49             int BytesRead = state.Stream.EndRead(asyncResult);
   50             if (BytesRead > 0)
   51             {
   52                 if (state.Callback != null)
   53                     state.Callback(System.Text.Encoding.ASCII.GetString(state.Buffer, 0, BytesRead));
   54 
   55                 System.Threading.Thread.Sleep(20);
   56                 // repeat: 
   57                 state.Stream.BeginRead(state.Buffer,
   58                     0,
   59                     state.Buffer.Length,
   60                     _rc,
   61                     state);
   62             }
   63 
   64         }
   65 
   66 
   67 
   68         private void KickoffAsyncReading(System.IO.Stream stream, OutputReceived callback)
   69         {
   70             // initialize the state for this async read loop: 
   71             StreamState state = new StreamState(stream, callback);
   72             System.Threading.Thread.Sleep(20);
   73             stream.BeginRead(state.Buffer,  // where to put the results
   74                 0,                          // offset
   75                 state.Buffer.Length,        // how many bytes (BUFFER_SIZE)
   76                 _rc,                        // ReadCompleted call back delegate
   77                 state);                    // local state object
   78         }
   79 
   80 
   81         private void Launch(string shellexe, string args)
   82         {
   83             _p = new System.Diagnostics.Process();
   84             _p.StartInfo.FileName = shellexe;
   85             _p.StartInfo.Arguments = args;
   86             _p.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
   87             _p.StartInfo.CreateNoWindow = true;
   88 
   89             _p.StartInfo.RedirectStandardOutput = true;
   90             _p.StartInfo.RedirectStandardError = true;
   91             _p.StartInfo.RedirectStandardInput = true;
   92             _p.StartInfo.UseShellExecute = false;  // required for redirect
   93 
   94             _p.Start();
   95 
   96             _sw = _p.StandardInput;
   97             KickoffAsyncReading(_p.StandardOutput.BaseStream, StdoutOutputReceived);
   98             KickoffAsyncReading(_p.StandardError.BaseStream, StderrOutputReceived);
   99         }
  100 
  101 
  102         public void Stop()
  103         {
  104             try
  105             {
  106                 _p.Kill();
  107             }
  108             catch { }
  109         }
  110     }
  111 }

To use it, it looks something like this:

    1 using System;
    2 using System.Collections.Generic;
    3 using System.Linq;
    4 using System.Text;
    5 using System.Windows;
    6 using System.Windows.Controls;
    7 using System.Windows.Data;
    8 using System.Windows.Documents;
    9 using System.Windows.Input;
   10 using System.Windows.Media;
   11 using System.Windows.Media.Imaging;
   12 using System.Windows.Navigation;
   13 using System.Windows.Shapes;
   14 
   15 namespace WPF_Host_for_PowerShell
   16 {
   17     /// <summary>
   18     /// Interaction logic for Window1.xaml
   19     /// </summary>
   20     public partial class Window1 : Window
   21     {
   22         delegate void MyAppendCallback(string s, System.Windows.Media.Brush color);
   23 
   24         Shell shell;
   25         TextBlock currentTextBlock= null;
   26         MyAppendCallback AppendDelegate = null;
   27 
   28         public Window1()
   29         {
   30             InitializeComponent();
   31 
   32             AppendDelegate= new MyAppendCallback(MyAppend);
   33         }
   34 
   35         private void MyAppend(string s, System.Windows.Media.Brush color)
   36         {
   37             if (this.Scroller1.Dispatcher.Thread != System.Threading.Thread.CurrentThread)
   38             {
   39                 this.Dispatcher.BeginInvoke
   40                     (System.Windows.Threading.DispatcherPriority.Normal, AppendDelegate, s, new object[] { color });
   41                 return;
   42             }
   43 
   44             lock (this.Scroller1)
   45             {
   46                 if (s != "")
   47                     this.currentTextBlock.Inlines.Add(new Run() { Text = s, Foreground = color });
   48 
   49                 this.Scroller1.ScrollToBottom();
   50             }
   51         }
   52 
   53         void StdoutReceived(string t)
   54         {
   55             MyAppend(t, System.Windows.Media.Brushes.BlueViolet);
   56         }
   57 
   58         void StderrReceived(string t)
   59         {
   60             MyAppend(t, System.Windows.Media.Brushes.Red);
   61         }
   62 
   63 
   64         private void Window_Loaded(object sender, RoutedEventArgs e)
   65         {
   66             // creating the shell starts it up
   67             shell = new Powershell(
   68                 new Shell.OutputReceived(StdoutReceived),
   69                 new Shell.OutputReceived(StderrReceived));
   70 
   71             InitCommand();
   72 
   73             shell.Input.WriteLine("prompt");
   74             shell.Input.Flush();
   75         }
   76 
   77         private void InitCommand()
   78         {
   79             // add a new textblock for each command
   80             currentTextBlock = new TextBlock();
   81             currentTextBlock.FontFamily = new FontFamily("Consolas");
   82             currentTextBlock.Margin = new Thickness(0d);
   83             //currentTextBlock.Foreground = color;
   84             this.OutputPanel.Children.Add(currentTextBlock);
   85         }
   86 
   87         private void Button_Click(object sender, RoutedEventArgs e)
   88         {
   89             InitCommand();
   90 
   91             MyAppend(this.textBox1.Text, System.Windows.Media.Brushes.SteelBlue);
   92             shell.Input.WriteLine(this.textBox1.Text);
   93 
   94             shell.Input.WriteLine("prompt");
   95             shell.Input.Flush();
   96         }
   97 
   98         private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)
   99         {
  100             shell.Stop();
  101         }
  102     }
  103 }

The full source is attached. Maybe interesting and re-usable for someone who wants to embed Powershell capability into an application.

MSBuild script for compiling all .cs files into a single assembly (DLL or EXE)

DotNetInterop — Tue, 08 Apr 2008 18:46:00 GMT

I love Visual Studio, but sometimes I build code using no graphical IDE - just the .NET Framework SDK. I wrote an article not long ago describing how to build a WCF Service using .NET 3.5, and just the SDK.

I've always been a makefile weenie, but msbuild is the new build tool - it really makes sense to me. One of the things that took a little effort for me was figuring out the msbuild script I wanted. Basically I wanted to just compile all the C# code contained in a directory, into a single assembly (EXE or DLL). As I build out an idea, I often will iterate rapidly on an app - introducing and removing C# files as it makes sense to me, and I want the build script to remain the same - just compile whatever files it finds.

Enclosed here is what I came up with, for my .NET Framework 3.5 SDK environment. Maybe it will work for you, too.

    1 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
    2         DefaultTargets="CompileAll"
    3         ToolsVersion="3.5"
    4   >
    5 
    6   <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
    7   <!-- Import Project="c:\.net3.5\Microsoft.Csharp.targets" /    -->
    8 
    9   <PropertyGroup>
   10     <!-- This AppName thing is the base name of your DLL or EXE -->
   11     <AppName>YourAppNameHere</AppName>
   12   </PropertyGroup>
   13 
   14   <!-- This build file compiles each .cs file into its own exe -->
   15   <PropertyGroup Condition="'$(Configuration)'==''">
   16     <Configuration>Debug</Configuration>
   17     <!-- Default -->
   18   </PropertyGroup>
   19 
   20   <PropertyGroup Condition="'$(Configuration)'=='Debug'">
   21     <Optimize>false</Optimize>
   22     <DebugSymbols>true</DebugSymbols>
   23     <!-- <OutputPath>.\bin</OutputPath>  -->
   24     <OutputPath>.\</OutputPath>
   25     <OutDir>.\</OutDir>
   26     <IntermediateOutputPath>.\</IntermediateOutputPath>
   27   </PropertyGroup>
   28 
   29 
   30   <!-- Specify the inputs by type and file name -->
   31   <ItemGroup>
   32     <CSFile Include="*.cs"/>
   33   </ItemGroup>
   34 
   35 
   36   <!-- specify reference assemblies for all builds in this project -->
   37   <ItemGroup>
   38     <Reference Include="mscorlib" />
   39     <Reference Include="System" />
   40     <Reference Include="System.Core" />
   41     <Reference Include="System.Data" />
   42     <Reference Include="System.Data.Linq" />
   43     <Reference Include="System.ServiceModel" />
   44     <Reference Include="System.ServiceModel.Web" />
   45     <Reference Include="System.Runtime.Serialization" />
   46     <!-- <Reference Include=".\ObjectDumper.dll" /> -->
   47   </ItemGroup>
   48 
   49 
   50   <Target Name="CompileAll"
   51           DependsOnTargets="ResolveAssemblyReferences"
   52     >
   53 
   54     <Message Text="Reference = @(Reference)" />
   55     <Message Text="ReferencePath = @(ReferencePath)" />
   56 
   57 
   58     <!-- Message Text="MS Build Tools path:  $(MSBuildToolsPath)" / -->
   59 
   60     <!-- Run the Visual C# compilation on all the .cs files. -->
   61 
   62     <CSC
   63       Sources="@(CSFile)"
   64       References="@(ReferencePath)"
   65       OutputAssembly="$(OutputPath)\$(AppName).exe"
   66       EmitDebugInformation="$(DebugSymbols)"
   67       TargetType="exe"
   68       Toolpath="$(MSBuildToolsPath)"
   69       Nologo="true"
   70         />
   71   </Target>
   72 
   73   <!-- redefine the Clean target, from the Microsoft.csharp.targets file.  (Last definition wins) -->
   74   <Target Name="Clean">
   75     <Delete Files="$(OutputPath)\$(AppName).exe"/>
   76     <Delete Files="$(OutputPath)\$(AppName).pdb"/>
   77     <Delete Files="%(CSFile.identity)~"/>
   78     <Delete Files="build.xml~"/>
   79   </Target>
   80 
   81 </Project>

To use it, run this:
c:\windows\Microsoft.NET\Framework\v3.5\msbuild.exe build.xml

Don't Believe Everything you Read on Wikipedia, especially about C# Anonymous Functions

DotNetInterop — Mon, 31 Mar 2008 17:41:00 GMT

I was reading Wikipedia the other day, and saw this:

C# has partial anonymous function support through the use of delegates. ... Since anonymous methods are not nameless and can only be declared inside methods of classes then C# does not support full anonymous functionality.

Hmph, who's in charge here? I don't really feel any ownership for Wikipedia, but that is just bad info. So I rewrote it.

The updated entry, including the comments on C#, is here: http://en.wikipedia.org/wiki/Anonymous_function

If you want to read all about the anonymous function support added in C# v3.0, then go the the source - MSDN.

Leads me to a couple other notes here.

First, yes, I agree it is a pain that the language compiler version has a different version than the framework. So we have C# 3.0, but it shipped with the .NET Framework v3.5. Confused? You should be. All I can say is, we apologize. there are good reasons we are confusing you. We're not doing it on purpose, it just works out that way.

Second, at first I approached the new C# language stuff with a little trepidation. I mean, lambdas? Extension methods? All of this stuff sounds a little esoteric. But after exploring a little bit, I have found good uses for these new language constructs, even outside the coolness that is LINQ. It's the little things. For example, I can convert a version string like 1.2.3.4 into a List<int> with a single line of code, using the ConvertAll() method and a lambda expression.

That kind of thing is just pretty cool. Also I use the object initializers all the time now.

Last, I wonder how much of the wikipedia thing works this way - people just feel like they don't want bad info out there, and are sort of transparently taxed into writing the articles themselves. This is sort of like trash collection in Seattle. When I lived in Pennsylvania, trash collection was just included in the taxes, and you could throw anything away. I could put a used car on the curb with a note on the windshield saying "Trash", and the trash man would come and haul it away. But in the Seattle area, you can't throw just anything away. There's a limit. If you want to discard an appliance, for example, you have to take it to the dump yourself.

There's something to be said for the Pennsylvania model - basically it means that there's no reason to be a "bad actor" and throw trash out in an empty lot. Whatever you want to throw out, they'll haul away. It's taken care of for you. (Like Encyclopedia Britannica). On the other hand the Seattle approach means people who discard a lot of stuff, have to pay more, and make more of an effort. (like Wikipedia).

Well I'm obviously rambling now. . .

Simple Auto Update, auto patch, for WPF Apps, without the Updater Block

DotNetInterop — Fri, 28 Mar 2008 18:59:00 GMT

I am writing some smaller WPF apps, and I want them to automatically update themselves, or automatically patch themselves, something like Lutz Roeder's Reflector or Paint.NET does. Scott Hanselman has commented on this previously, and he's right. Every app ought to be able to do this.

I looked into the Application Update Block, which was last updated I think in 2005, and is at version 2.0. This is a thorough application block (a body of reusable code) that seems to do "everything". But it's a little too much for me. It requires the .NET Enterprise Library, which is free, but a lot of extra code. It all feels like too much work. Too much configuration, too many options, too much flexibility. It's too much for what I want.

My apps are small, single EXEs, no installation, no config files, and so on. This is a very very simple scenario. The Updater Block is overkill.

I looked into using AppDomains and getting fancy that way, but I didn't like that approach either. Too complicated, too unnecessary. The AppDomain is a nice structure if I want the process to continue living through the update lifecycle. But I don't need the process to live forever. I don't care about re-cycling the process. So AppDomains seem like the wrong approach too.

I also looked around for some biolerplate code produced by someone else, something I could re-use. But I couldn't find anything accessible. I think there are commercial third-party components that do this, but this was just for some really basic apps, I didn't want a commercial solution. So, I built it myself.

A Simple Approach to Self Patching Apps

There are really two steps to the auto-update, or auto-patch trick. First is to find out the latest version of the app, Second is to get the latest version and replace the old version with your new version. The first problem is simple, just an HTTP GET (in the REST tradition) on a text file containing the version number. The second problem is more challenging.

The EXE starts up, and it can do the HTTP GET to find out it needs to be updated. But then what? Of course, the app could go get the updated version of the app image, with the same kind of HTTP GET. For a reasonably sized app (let's say up to 1mb EXE image size), this will be reasonably fast, well within the realm of acceptable performance. Even for a 20mb download, it's still acceptable. BUT, while the EXE is running, the EXE Image on disk is locked. It cannot be overwritten. This second problem is trickier.

What I settled on was this: have the executing application replicate itself. The App starts up. Let's say it runs in process 1. checks for available updates. If it finds an update, it replicates - copies its EXE image to another location, a temporary location. The original process then does a Process.Start() on that copy of the EXE, we now have process #2. Then the original process (#1) exits!. This unlocks the original EXE image on disk, so that it can be overwritten. The process running from the temporary copy location, now downloads the latest, updated EXE image, and copies it to the original location. The Updater clone process then does a Process.Start() on the original EXE location. This creates process #3. Then Process #2 exits. When process #3 starts up, it checks for updates and finds none, since it is the running from the latest EXE image. Process #3 then tries to clean up any EXE "updater clone" images - this last step is just good manners and not strictly necessary for correctness.

This should work with any WPF application. The approach will also work for WinForms applications, but the code I have here, will not.

Here's what the code looks like in your app; you embed this in the code-behind of your WPF Window class:

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();
        if (UpdaterCheck())
            this.Hide();
    }
    private Ionic.AppUpdater.Wpf.Updater _updater; 
    private string _manifestUrl =
        "http://example.org/AppUpdates/MyApplication/Manifest.xml";
    private string _infoUrl = 
        "http://example.org/MyApplication.html";
    private string _description =
        "MyApplication is a delightful application; it does x, y, and z. " +
        "It uses the Ionic AppUpdater module for WPF for auto-update " +
        "capability.";
    // Obtain the publicKey XML from the ManifestTool that ships with Ionic AppUpdater.
    // The following string is Ionic's public key.  You will need a different one.
    // Consult the Readme for more information. 
    private string _publicKeyXml = "<RSAKeyValue><Modulus>sZqhvF0KX6m4blah..blah...=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>";
    private bool UpdaterCheck()
    {
        _updater = new Ionic.AppUpdater.Wpf.Updater("This is MyApplication.",
                                                    _infoUrl,
                                                    _description,
                                                    _manifestUrl,
                                                    _publicKeyXml);
        return _updater.Status.IsUpdating; 
    }
    ...

When this runs, the Updater() will check for updates and will inform the user if a more recent version is available.

When it starts up, the sample app looks like this :

Not very fancy. But this is just an example. It can be any WPF application. If there is an update, then automatically, this UI is presented:

This UI is not something you have to code; It is generated by the AppUpdater module, based on strings your app passes in to the AppUpdater constructor. If the user clicks the "Get Update" button, then the app automatically begins downloading. There's no code required for that, either. It looks like this:

You don't have to code any of this.

When the download completes, that window disappears, and then the app starts up again. It all happens pretty fast for a small app. For my sample app of around 28k, it happens in less than a second.

Now, in general, people will want different user interaction models. The code above will nag the user, every time the app starts. You might want to be more in the background - and only tell the user if there is an update when they ask. Maybe you notify about updates based on a click on a menu item, maybe it's a button click. This is easy to do, too. Just put the call to the Updater() constructor in the code-behind for the button or menu item. The UI will look the same.

I hope this is useful.

The source is attached here. It is all C#. This requires the .NET Framework v3.5, and WPF.

Hmmm, what about Security?

My first crack at this just used a text file holding the Version tuple (1.2.3.4), and if the version was different, the app would download itself and there ya go. But the security of that approach was pretty loose. I saw an older comment from some guy named Mike, who described an approach to signing an XML manifest file, and including an MD5 hash in that manifest. So I adopted that approach (except I use a SHA256 hash). I used this codeproject article as a hint for how to sign the XML and verify the signatures.

The tool emits a signed XML manifest that looks like this:

<UpdateInfo xmlns="urn:Ionic.Apps.Updates">
  <LatestAvailableVersion>1.2.5.4</LatestAvailableVersion>
  <ImageName>MyApplication.exe</ImageName>
  <AssemblyFullName>MyApplication, Version=1.2.5.4, Culture=neutral, PublicKeyToken=null</AssemblyFullName>
  <TimeStamp>2009-08-11T02:31:43.2320026-04:00</TimeStamp>
  <Hash>8BA50BC233CB70478E04D6A740358E3DD0F30C78988BFC22D4AC58A8D777A8FE</Hash>
  <HashType>System.Security.Cryptography.SHA256CryptoServiceProvider</HashType>
  <DownloadLocation>http://example.org/AppUpdates/MyApplication/MyApplication.exe</DownloadLocation>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <Reference URI="">
        <Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /></Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>cUxRXJ0lcVcAB7cdWkRdyggAVEM=</DigestValue>
      </Reference>
      </SignedInfo>
      <SignatureValue>CheE/WCcHvbsZr9Y3ACpX4Wqp9e/0cpUpEE6JYtjl2dZdr606xIcGsouUnjOBNfEPs02neRIuVMrGMCo/4ImkbSlprroQY6/Yd9ne7LXytBd1/5+RfJzHoKMM7/Nnoc2A3eP7wBpEtGgMJZ3VFrDHxLRJSpaEKpWdOPO6EIEmGk=
      </SignatureValue>
  </Signature>
</UpdateInfo>

The source for the Updater module, as well as a sample app demonstrating its use, and the manifest tool, is all attached here.

This really has nothing to do with Interop, but it's a handy thing to have. Now, go and be cool, and build self-patching, auto-updating applications.

My Vista Experience just got sooooo much better

DotNetInterop — Sat, 22 Mar 2008 22:09:00 GMT

Quietly I've been suffering through an experience with Windows Vista on my laptop. I got my laptop, a HP/Compaq nc8430, in October 2006 and had been running Vista on it since then. In the early days, I used a pre-release version of vista, but I switched to the generally-released (RTM) version as soon as it was available.

The laptop is a nice piece of hardware - it's got a huge, bright 1680x1050 screen, a solid keyboard, a touchpad and a mouse stick (nipple?). It's got good sound, a 100gb hard drive, a fast processor. I got the spare battery. IT also has a fingerprint scanner, built-in reader for smartcards and SD storage, 3 USB ports, built-in Bluetooth and 802.11g wireless networking. Also it's solid, built like a tank. As a "work machine" it's not what you would call "exciting". It doesn't have flashy looks or wafer-thin profile (and the slim battery life to go with it). It's not as light as a feather, but I'm a big guy and I can handle the heft, whatever it is. It never bothered me. Overall, I am very pleased with the hardware.

Who's Driving This Thing?

The problems I had with Vista on this machine started early. I did not have an OEM-blessed install of the OS on the machine, and some device drivers were lacking. The fingerprint reader, I think was one of them. Also the function keys - like the one to turn on and off the wireless network, or the one to flip the machine into presentation mode - also lacked Vista-compatible drivers. There's a mobile data protection thing in the hard drive - an accelerometer that protects the hard drive from sudden drops - that one also did not work. Lots of people may doubt the value in the mobile data protection thing, but I experienced a data loss first hand from sudden laptop droppage. It happened with my old IBM Thinkpad - I dropped it on a bed, a BED mind you! in a hotel room while I was travelling. The laptop immediately experienced drive errors and it was never the same since then. So I totally understand the value. Anyway, the driver for the accelerometer on the hard drive was lacking for Vista.

As a result I was using a slightly crippled install - some drivers were totally lacking, and for other devices, I installed WinXP-compatible drivers and winced as I ok'd through the "are you sure you want to do this?" dialogs. And the user experience resulting from the mishmash of drivers was accordingly poor. I'd get bluescreens with the accelerometer stuff. I'd have trouble waking up and hibernating. Some ordering of hibernate, sleep, wakeup, and re-sleep would cause my PC to just shut down completely. There's never a good time for your laptop to just turn off. But it happened a couple times a week to me.

I signed up for HP's driver alert email, so I would know about the latest releases of drivers for the thing. But the emails I got several times per week seemed to have a lot of noise - alerts about new marketing programs and stuff I just did not need to know about. As a result I stopped reading the emails and was in the dark as to when the drivers were being updated.

When I had the time and energy, I would manually visit the HP site to check for new drivers, and wouldn't you know it, every time I visited there would be new and updated drivers. Monthly, sometimes more often, I would update the machine, crossing my fingers, hoping, hoping! that somehow, please please please, finally the PC would be working the way it ought to, the way my WinXP SP2 machines were running - solid! But while the various problems changed or morphed, they never seemed to go away.

AC power = A Useless Machine

One of the nastiest problems was with disconnecting and re-connecting from AC power. It seemed that every time I connected to AC power, the hard drive would thrash for 10 minutes and the machine would essentially become useless. Apparently this disk thrash was not an unusual user experience. If I was low on battery and walked into a meeting, I'd be forced to plug into AC, and then endure the 10 minutes (no kidding, 10 full minutes) of PC uselessness. I searched and searched and never could diagnose this problem. I turned off Vista search indexing, thinking it was that. (this was a huge setback in user experience). I imagined it was some combination of poor device drivers coupled with heavy disk use. I turned off Sidebar. I turned off everything I could find, trying to minimize stress on the machine. I disabled superfetch. Nothing solved it. Finally I resorted to planning my business day around hooking up to AC power. I could do it before lunch. I could do it in evening just before I left for home. Living like this was utterly stupid.

I was hoping that Vista SP1 would solve the problem for me.

The Tide Turns

In early December 2007 I went through a huge batch of HP driver updates. Slowly the problems lessened, it seemed. Then in January I did it again, found a whole new batch of updates. Once more in early March I did it again. For the first time there was a BIOS update for the machine! Whoo-hoo! With all the updates, things were looking good: The bluescreens on hibernate/sleep/unsleep/sleep went away. The accelerometer started working. The function keys started working. Then one night earlier this week I dedicated some time to diagnosing the final remaining annoyance: the hard-drive-spin-up-when-on-AC-power thing. Turns out, all along, it was a Defrag task.

In the Task scheduler for Vista, there's a bunch of settings - one that says "don't do this task while on battery power" and another that says "do this task as soon as you are able". (it is worded as "Run task as soon as possible after a scheduled start is missed"). My weekly full defrag was set to run at 3am on Thursday morning. Sometimes the machine would be OFF at that time, so as soon as I turned it on, and plugged it into AC power, the defrag would start. And it would hammer the disk.

I looked into it, and found an article that guided me through some of the possibilities in adjusting the task schedules. Just turning off the "Run task as soon as possible after a scheduled start is missed" checkbox avoided a world of hurt for me. This should never be the default option on a laptop, in my opinion.

I'm in Love. Again!

I am proud to say, I now love my laptop again. I love my laptop more than I ever thought I could. Things are better than ever between us!

Listen, for those of you who doubt, for those of you who go through hell in your relationship... let me tell you, it does get better. You go through dark days, thinking, I need to get out of this relationship! I can't take it anymore! But then the other half of you is saying, "what about all I've invested in it? If we somehow got over this rough spot, we could still have a beautiful future together!" It all seems an impossible dream. Well, I'm here to tell you, that things can get better. Even when things look darkest, it is still possible to recover and get to a happy place. It is possible to Find Love Again!

Ok, off to install Vista SP1 !

ps: I still have superfetch turned off.

Gates Center at Carnegie Mellon

DotNetInterop — Sat, 22 Dec 2007 15:52:00 GMT

I visited my alma mater, Carnegie Mellon last weekend. Met up with some fellow alums who came in from out of town, including Brendan, Scott, and Brian, pictured here. We're checking out the construction site for the Gates Center at Carnegie Mellon. This was enabled by a grant from the Bill & Melinda Gates Foundation to the university. It's the first time I had seen the project.

Here's a view of the construction site itself. Pictured in the background are Wean Hall and Doherty Hall.

You can read about the details of the project on the Wikipedia article.

VS2005 support for SQL 2008 CTP5

DotNetInterop — Wed, 21 Nov 2007 02:52:00 GMT

Visual Studio 2005 Support for SQL Server 2008 CTP is now publicly available.

Download Center links:

SQL Server 2008 CTP, November 2007 - this is the "Community Tech Preview" (CTP5) of SQL 2008.
Visual Studio 2005 Support for SQL Server 2008, CTP - this is the patch you can apply to Visual Studio 2005, to allow it to connect to the SQL 2008 CTP5.

The Microsoft team is now working on a similar patch for VS 2008. Stay tuned!

Keeping it real on SOA

DotNetInterop — Tue, 02 Oct 2007 17:59:00 GMT

Bobby Wolfe of IBM told no lies when he said that

Clients often want to build only an ESB, because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It doesn't create business value.

David Linthicum, an analyst who writes for infoWorld, agrees:

The truth seems to finally be coming out…you can't buy a SOA. Indeed, SOA is something you do, and an ESB is not an architecture, it's a mere instance of technology.

Somehow this idea - that you cannot "buy" an SOA - is remarkable. Somehow when people say, "you should only build and deploy what the business needs, you should take a practical approach that aligns IT and business value", that is news. Odd because this is what Microsoft has been saying for some time now. When common sense becomes notable, you know things are goofy.

Apparently, Bobby Wolfe's article caused quite a stir at IBM because now it carries a disclaimer!

Since its publication, Bobby’s article has drawn a lot of interest, and we appreciate the discussion surrounding this article. Unfortunately, it gave some readers the impression that IBM® no longer values the ESB. Rest assured that nothing is further from the truth. ...

heh heh, amusing