• You will need to grab the Silverlight 1.0 RC1 SDK
• .NET Framework, v1.1 (required by the InnerWorkings bits, regardless of the training being in Visual Studio 2005)
  
• Register at CSharpZealot.com if you have not already done so
  
• Follow the link on Brian's blog to InnerWorkings special promotion for CSharpZealots

• Forward, at a pace of 1 second per second, same as daily life, really; and
  
• Backwards at a rate of 20 yrs in, say, about 150 miliseconds.

• Windows Communication Foundation (Including Windows CardSpace)
• Windows Workflow Foundation
• Windows Presentation Foundation
  

• Managed AddIn Framework (System.AddIn & System.AddIn.Contract) ...also the CLR Add-In team blog.
  
• An AD/ADAM wrapper (System.DirectoryServices.AccountManagement)
• A WMI 2.0 Managed wrapper (System.Management.Instrumentation)
• Peer-to-Peer API's (System.Net.PeerToPeer & System.Net.PeerToPeer.Collaboration)
• In ASP.NET there is ASP.NET AJAX, asp:ListView, and the LinqDataSource. (System.Web.Extensions)
• Improvements to WCF and WF (System.ServiceModel.Web & System.WorkflowServices)
• ADO.NET Entity Framework (System.Data.Entity)
• New Crypto algorithms and support for Vista's Next-Gen Crypto, which replaces CryptoAPI. (System.Security)

Update:  Please also check out Daniel Moth's whole bunch Orcas posts, and his run-down of the new bits.

• LINQ to Xml (System.Xml.Linq) and LINQ to SQL (System.Data.Linq) ...also ScottGu's posts here, here and here are some of the best you'll find)
  

...and for everything that I have missed, or is not in the beta bits yet, grab the Orcas overview whitepaper.

What is .NET 3.5 going to do to 3.0?

It seems it has to do with Green Bits and Red Bits(source: Daniel Moth).  In other words, .NET 3.5 will also include SP1 for .NET 3.0 and SP1 for .NET 2.0.

I've just got a couple of lessons from the last week to share around developing Office 2003 (and specifically Visio 2003) Add-Ins

I'm also trying to saturate this post with links because I have come up with a good size folder in my bookmarks for what started out to be a simple task.

• Grab the PIA's.  Anyone who wants to run the Add-In will need them.  Alternatively they can be installed from the Office Add/Remove/Repair under the guise of .NET Programmability Support, but in reality the user may not have the media or security access to do this.  Do NOT however ship the PIA's in your bits.  Ship the PIA's with your bits:  This means 2x MSI's.
• Using NAant to automate the build with csc.exe & vbc.exe is suboptimal.  I'm keeping my project to one small assembly that depends on the PIAs, and also depends on another assembly that does the heavy lifting but has no ref to the PIA's.
• Strong Name everything.  Well, strong name everything anyway, but when trying to pass of managed code as COM it is essential.
• You cannot load a .NET DLL, even one with the ComVisibleAttribute on the Assembly or Classes, via the Office UI.  You just can't.  KB316723 gives an explanation.  This is because Office will try and register it the old regsvr32 way, which of course won't work.  To get a .NET DLL into the Macros -> Add-Ins list, you must write the registry entry under: HKEY_CURRENT_USER\Software\Microsoft\<office program name>\Addins\
• This brings me to my next point.  KB316723 hints at it, but your setup must write a HKCU key not a HKLM key.  The Shared Add-In Wizard in Studio is ambiguous when it shows you this choice:

• I know this may be contentious, but consider using VB.NET over C#.  This depends of course, but some parts of the Office object model make heavy use of Optional Parameters which C# does not support.  It has been noted elsewhere what Type.Missing can do for readability.  Having said that, it does vary greatly depending on where in the Office Object Model you are.
• Spend some time with the Setup project that the Shared Add-In Wizard makes and test it.  Once you like it, reverse engineer it to a WiX script and feed that to your automated build.  For the record, you do that with:

Dark.exe –x path Debug/msi My.wxs
Candle My.wxs
Light My.Wixobj

• To extra points when dealing with WiX-ified MSI's
  1. It's useful to note that the extracted (-x) resources take many forms.  DefBannerBitmap.ibd for example is just a bitmap.  I think it is easier to rename it to .bmp & tweak it in Photoshop than to add a new banner in Visual Studio.
  2. The Add-in reg setting mentioned in point #4 above references an assembly version.  Visual Studio tweeks this for you but your WiX script will be frozen at the time your Dark.exe'd it.  So don't auto-increment your assembly version numbers, or tweak you WiX script.  The choice is yours but your MSI must write the version of the Add-In DLL to the target machine's registry.

Listening To: Leftfield, Leftism

So I feel that my last post on pretty gray info bars in Photoshop could do with a second chapter :)

This is a pretty long series so I'll be breif - what follows is the rough outline of how to achieve the same result as a User Control in your Visual Studio project.  The advantage of this aproach would be to allow you to dymanically add text or other sparkle of your own creation :-)

Here's a sample:

Code follows :-)

namespace GrayBar
{
   public partial classGrayBar : UserControl
   {
      publicenumGrayBarModes
      {
         GreenTick = 0,
         YellowBang = 1,
         RedX = 2
      }

      public GrayBar()
      {
         InitializeComponent();
      }

      protectedoverridevoid OnPaint(PaintEventArgs e)
      {
         Graphics g =this.CreateGraphics();
         g.SmoothingMode =SmoothingMode.HighQuality;

         // Fill the whole canvas
         Rectangle wholeControlSpace =newRectangle(0, 0, this.Width, this.Height);
         Brush controlFiller =newLinearGradientBrush(wholeControlSpace, Color.DarkGray, Color.LightGray, LinearGradientMode.Vertical);
         g.FillRectangle(controlFiller, wholeControlSpace);

         // Make icon in corner
         Rectangle iconSpace =newRectangle(1, 1, this.Height - 2, this.Height - 2);
         Brush iconFiller =newLinearGradientBrush(iconSpace, Color.Gray, Color.DarkGray, LinearGradientMode.Vertical);
         g.FillEllipse(iconFiller, iconSpace);
         base.OnPaint(e);

         Font iconFont =newFont(FontFamily.GenericSansSerif, 12, FontStyle.Regular);
         string iconText ="";
         Brush iconTextBrush =newSolidBrush(Color.NavajoWhite);

         float fontHight =this.Height; 

         // The Font, Text and Colour depends on the setting on our GrayBarMode property
         switch (GrayBarMode)
         {
            caseGrayBarModes.GreenTick:
               iconFont =newFont("Wingdings 2", fontHight, GraphicsUnit.Pixel);
               iconText ="P"; // P == "tick" in "Wingdings 2"
               iconTextBrush =newLinearGradientBrush(iconSpace, Color.DarkGreen, Color.LightGreen, LinearGradientMode.Vertical);
               break;
            caseGrayBarModes.YellowBang:
               iconFont =newFont("Arial", fontHight, FontStyle.Bold, GraphicsUnit.Pixel);
               iconText ="!"; 
               iconTextBrush =newLinearGradientBrush(iconSpace, Color.Orange, Color.Yellow, LinearGradientMode.Vertical);
               break;
            caseGrayBarModes.RedX:
               iconFont =newFont("Arial", fontHight, FontStyle.Bold, GraphicsUnit.Pixel);
               iconText ="X"; 
               iconTextBrush =newLinearGradientBrush(iconSpace, Color.Maroon, Color.Red, LinearGradientMode.Vertical);
               break;
            default:
               thrownew ApplicationException("Unknow Mode");
         }

         float iconTextXPos = (iconSpace.Width / 2) - (iconFont.GetHeight(g) / 4);
         float iconTextYPos = (iconSpace.Height / 2) - (iconFont.GetHeight(g) / 2);
         g.DrawString(iconText, iconFont, iconTextBrush, iconTextXPos, iconTextYPos);

      }

      privateGrayBarModes _GrayBarMode =GrayBarModes.GreenTick;
      publicGrayBarModes GrayBarMode
      {
         get
         {
            return _GrayBarMode;
         }
         set
         {
            _GrayBarMode = value;
         }
      }

      privatestring _MessageText;
      publicstring MessageText
      {
         get
         {
            return _MessageText;
         }
         set
         {
            _MessageText = value;
         }
      }

   }
}

Expect.Once.On(mockFetcher).Method("GetDatabases").Will(Return.Value(mockReturnValue));

Expect.Once.On(mockFetcher).Method("GetDatabases").Will(NMock2.Return.Value(mockReturnValue))

Just a follow-up on my post of yesterday about the intent of exposing a read-write property of an Array/Collection type.

Practical Guidelines and Best Practices has the following guidance (i'm paraphrasing)

13.13 To protect the state of a backing var for properties that return arrays, consider

get { return DirectCast(_arr.Clone(), string()); }

which is good protection, but less efficient.  Or, provide indexed access to the array by an indexed property or function.  Getting close...

13.14 Properties that return a collection should be read-only to prevent clients replacing the whole array with a new one, or with a null reference as that could break assumptions elsewhere in the class. Disco! 

Thanks lads!

This one came up in discussion last week and could be worth mentioning.

Consider the following property:

private List<SchemaAttribute> _attributes = newList<SchemaAttribute>();
publicList<SchemaAttribute> Attributes
{
   get
   {
      return _attributes;
   }
   set
   {
      _attributes = value;
   }
}

NCover/NCoverExplorer reliably inform me that this property has only 50% coverage
in my tests.

By hereto unexplored forces of nature, every consumer of this class calls
.Attributes.Add()

or, itterates over it as so:
foreach (SchemaAttribute element in instance.Attributes)
{
   // ...
}

The keen eye will notice that neither of these ways to access the property actually hit the setter! 

Two possible paths present themselves:

1. Write a test that just exercises the setter.  This seems to me pointless. 
   If we are to consider that our tests can serve to express our intention
   in a repeatable fashion, what is our intent?  To see if a Generic List still works?
2. Consider makeing the property read-only.  Including braces I could own three lines less code.  Yay!
   And also now I have had cause to think about it, it's not my intention that the
   List be set as a list, for this class it just dosen't make sense right now.

Next step?  Consult Francesco & Giuseppe!

Sleep.  The best 10 hours of the week.

Listening to:  Nick Cave and the Bad Seeds - Abattoir Blues