Today at REMiX '08 Sydney (Also see VisitMIX) along with a good show and a grand feed, attendees also got a copy of Expression Studio 2.  After seeing it in action I'm quite looking forward to taking it around the block.  I never quite got into [Macromedia|Adobe]Flash, and am quietly hoping Silverlight can find a spot next to it in the web ecosystem.

First thing I did when I got home was install Expression Studio, I got a little curious to find that there is a Visual Studio 2008 Standard disk in the box.  It got me to wonder what really is the difference between VS Pro which I am using at the moment and VS Standard?

I can't remember the product comparison pages for any version of Visual Studio on MSDN ever being completely illuminating.  The 2008 version is about as good as it gets it seems. 

The one that I am most interested in somehow is down the end of the list:  the inclusion of the Unit Testing features in VSPro 2008, when it was only included in Team System versions of VS 2005.  Here is a slightly abridged summary of the other features included in VS Professional that you do not get in VS Standard:

Debugging Tools:

• Attach to Remote Process
• SQL-CLR Debugging
• XSLT Debugger
• T-SQL Debugging

Data Tools:

• Database Projects
• SQL Server Projects
• Server Explorer

Reporting:

• Crystal Reports Application & Crystal Reports for Visual Studio

Office development:

• VSTO for Office 2003 and Office 2007
• Sharepoint 2007 State Machine workflow template
  

Smart Device Development:

• Device Emulator
• Project Templates
• Debugging Tools

...but surely this can't be it?

It's not.  Well, this is the story if you are comparing VS Pro and VS Standard alone, but there is one other thing to consider:

1. In my timezone, the full boxed retail VS Standard is less than half the price of the equiv. VS Professional... but;
   
2. You can't get an MSDN Subscription including VS Standard.  They are only available with Professional and above, and imho the licensing benefits of MSDN for developers is well worth the look.
   

So there you have it.  If an MSDN Subscription is on your radar, enjoy using VS Pro.  If it is not, and you can live without the above listed features, well maybe there is no need to spend more than you have to.

This is the first in what I hope will become a series on the new language features in C# 3.0 used in .NET 3.5 / Visual Studio 2008.

One thing I am not intending to cover is LINQ.  Just because the blogosphere has been buzzing with LINQ articles since the early days of "Orcas".  And with good reason I hasten to add!

Where I am starting is with the var keyword.

VB6 veterans will remember the Variant type.  A Variant could contain anything, even Object.  While this was sort of useful, my memory of it is as a synonym for:  I can't be bothered, lets just stick it in a Variant and deal with it later.

There was also a performance impact of using the special Variant type, they were large in memory and have an overhead of extra runtime checking that added up; like when assigned inside a loop for example.  They were also a special case in their un-assigned form, taking on the value Empty (test with IsEmpty()) vs Nothing (test with Is Nothing). 

So when I saw var added to C# I raised my eyebrows in the way a Fed might, when the beagle sits quietly next to your suitcase at the airport.

Most of the time you see it in the samples, it is used when returning an Anonymous Type from a LINQ query.  And this is the clue!  var is not itself a type, but instead it is a signal to the compiler to infer the type of an operation, and substitute in the required type.  It does not even have to be an Anonymous Type.  Consider the following simple example:

var result = 10 / 2.0;
Console.WriteLine(result.ToString());

By the time this code is compiled, var is replaced with double.  In fact, the Intellisense on result will be correct for it being a double.

To confirm this, looking at those lines of the assembly in Lutz Roder's Reflector show the following after disassembly:

double result = 5.0;
Console.WriteLine(result.ToString());

OK, so var can be used independant of Anonymous Types, but why would you want to be less explicit in typing your variables?  Consider the following fictitious example:

DatabaseRequestService req = DatabaseRequestService.CreateFrom(value);

And compare it with the equivalent line using var:

var req = DatabaseRequestService.CreateFrom(value);

Here, var leads itself to much more readable syntax with the same typing, Intellisense, and everything else!

Listening To:  Róisín Murphy

Lots of people are familiar with obtaining and installing SSL Certificates for hosting secure web sites, but the area of code signing seems less cohesive. I’ve compiled some notes I have on the process together in this blog post.

Yes, but who are you?

Reputable publishers of code signing certificates require some evidence that you are authorized with respect to the organization you wish to have named on your certificate. In my case, being able to produce the ASIC registration for my company was enough, YMMV.

This is subtle, but important.

1. My company rego papers are credentials a Root CA (e.g Comodo, Verisign, Thawte, USERTrust etc) uses to trusts me.
2. The user (implicitly) trust the Root CA by using an OS with their Certificate installed.
3. Ergo, the user (indirectly) trusts me.

Macro projects in Microsoft Excel/Word/Visio/Access/etc

Once you have obtained your certificate, you are able to sign Macro projects in Office document templates by choosing Tools -> Digital Signature.

Your newly purchased certificate will appear in the list and by saving the project your template is signed. The difference is now the user is asked to trust you (as verified by the CA) and your code, rather than being asked to enable all macros.

Software distributed MSI packages

Signing MSI packages and CAB files is more visible than ever before in Windows Vista. This I think is a good thing, however I do worry that because there are a lot of unsigned installers out there that users may get the message that it’s not that important.

Once you have got your certificate from a CA, the process couldn’t be easier. There are a couple of ways to get signtool.exe, I usually have the Windows SDK on my machines which ships with it.  The command to sign ClassLibrary1.dll for example is: (assuming signing from a pfx, not the local cert store)

C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\signtool.exe sign /f My_Code_Signing_Cert.pfx /p L0ng5ecr3tp@ssw0rd /d name /du http://www.MyCompany.com /t http://timestamp.verisign.com/scripts/timestamp.dll ClassLibrary1.dll

The time stamping is important here, in that certificates expire. An external time stamp ensures that the assembly was signed while the certificate was valid.

.NET Assemblies

Technically, signing an assembly is not unlike signing an MSI. On one hand it is easier because you can do the signing from inside Visual Studio’s project properties

On the hand there is the concept of delay signing, where the actual private key is not available to the developer on a day-to-day basis.  This added security adds a layer of complexity that is frankly beyond the scope of this post. I will come back and dedicate a whole post to it some time

Windows Logo Certification / WinQual

This is the only case I can think of where the vendor of the certificate matters. A certificate from VeriSign is required to prove your identity in the WinQual program, which is required for a Windows Logo certification. VeriSign has special pricing is on offer for members of Windows Quality Online Services site.  The $99 cert from VeriSign is required for WinQual membership, and is all you need if you already have a code signing certificate. The $399 cert is valid for both code signing and WinQual membership.

So looking forward to another year in Visual Studio, and this year in Visual Studio 2008 no less! 

I thought I'd open 2008's blog posts with a note about what is in my toolkit at the moment for developing in VS2008.  So in no particular order...

What is in?

• Visual Studio 2008.  I played with it since Beta1, and blogged about it a bit too.  Living in the RTM now and quite liking it.
• Refactor! Pro and Coderush from Developer Express are still on my list.  There is a new version (3.0.5 at time of writing) out that has some cool new improvements.
  
• Aptana Studio.  I heard about this Eclipse-based IDE on the Hanselminutes podcast and had to check it out.  There are some good features in there for CSS and JS.  Worth having around and they cram a lot of IDE into a tiny space!
• The PowerShell Visual Studio Templates.  Powershell is getting more and more use in my life, and I love the idea of rolling your own cmdlet (pronounced:  "command-let") to manage your own apps.  The page says they are for VS2005 but they are good for VS2008 as well.
• NMock.  I know there are plenty of mocking frameworks out there each with their own style.  I just happen to like NMock.

What is out?

• The notable exclusion from my 2008 dev environment is NUnit.  I have been a fan and user of NUnit for some time, but am going with the MSTest-based unit testing framework that is built in to Visual Studio 2008.
• NAnt is on thin ice in my environment too in favour of MSBuild.  This is largely for pragmatic reasons, there is project information kept in both the VS Solution and in the NAnt file and my preference is to maintain it in one spot only.

And that's it!  I like to keep it light.  For Continuous Integration I am using CruseControl.NET.

I'm still searching for the perfect XPath/XSLT environment.  Visual Studio is OK for the moment, but I have a feeling that the perfect tool may just be Eclipse based :)

The CLR Add-In Team Blog has just posted a list of the 7 new features that they have included in Visual Studio Orcas2008 Beta 2.

How to start?
You will need several assemblies.  This is because to reach the level of decoupling that is desired, the pipeline has a certain pattern of dependencies between projects.  I’m not sure if I am subconsciously not objecting to it or actually actively like this now, was not always the way.

A pipeline?
Yes, you need one. 

What is a pipeline?
It’s a series of folders that live somewhere (does not have to be under your application's path) and each of the assemblies have their place in the structure.  The folders will look like this:

It’s probably a good idea to build one now in your project tree and set the build output as you go.

There is a graphic explaining the pipeline on the CLR Add-In team blog (with nice colours), it is also in the Orcas MSDN under the title: "Pipeline Development Requirements".  The MSDN one has the addition of lines to indicate the static dependancies.

I've chosen to show it differently in my graphics (don't say a word!) to indicate the order of it all coming together as well as the references.  In the graphic the arrow lines illustrate the dependancies between the projects.

Also, I make reference to the sample code throughout this post.  Download link is at the bottom.

Step 1: Define Contracts

The first step is to define the contracts in your contracts assembly and DTOs in your DTO’s assembly.

Your contract should be one interface per kind of add-in you will support.  These interfaces need to inherit System.AddIn.Contract.IContract and be decorated with System.AddIn.Pipeline.AddInContractAttribute.

Types in the DTO that you wish to pass over the boundary will need to be serializable.

Jason He’s example of a Paint.NET Add-In (link below) takes a different path, by adding the extra types in the Add-In View, adding more wrappers.  His approach may have advantages that I have not discovered yet, but it reminds me of some of the dancing you have to do when for example you have the same type in a Web Reference and a binary reference in the same project. 

My preference is then to make a behavior-free separate assembly that anyone can take a dependency on safely.  This is the reason for including a DTO project.  I also like having the DTO types there to do as a [DataContract] does in WCF.  This will allow the Add-In contract to remain static if the host side changes it’s implementations of the DTO equiv. types.

Change the project properties of the Contracts project to build to: ..\Pipeline\Contracts\

Also note, for types that take a dependency on the DTO project, set the Copy Local property of the reference to False.  This is to keep the pipleline path clean.  i.e. we don’t actually want a copy of the DTO assembly in the \pipeline\contracts\ path!  This will slow our discovery and generate warnings as the Add-In infrastructure tries to examine it for contracts.

Step 2: Host View and Add-In View

Add two new assemblies:  host view and add-in view
Each has a public abstract class that mirrors the contract interface but does not reference it.

Host view does not even need a reference to System.AddIn.

When building the Add-In View, be sure to:

• Apply System.AddIn.Pipeline.AddInBaseAttribute
• Set the project to build to ..\Pipeline\AddInViews\

Step 3:  Host Adaptor and Add-In Adaptor

Add two more assemblies:  host adaptor and add-in adaptor

Add-in adapter will have one AddinToContractAdapter class for each Add-In type and the Host adapter has one ContractToHostViewAdapter class for each Add-In type.

The AddinToContractAdapter descends from System.AddIn.ContractBase and implements the contract for the Add-In

The ContractToHostViewAdapter descends from the Abstract class in the Host View for the Add-In.

Set the build output path of the Host Side adapter to: ..\Pipeline\HostSideAdapters\
And set the build output path of the Add-In Side adapter to: ..\Pipeline\AddInSideAdapters\

The purpose of these adapters is too marshal calls between the instances of your IContract's and should just look like wrapper code.

Step 4: Build the Add-Ins

Every Add-In needs to take a dependency on the Add-In View project and the DTO project.  Be sure to set their Copy Local = False in the reference properties.

Each Add-In also needs to descend from the abstract class in the Add-In View project, implement overrides, and to be decorated with System.AddIn.AddInAttribute.

The AddIn Attribute is the key to how the Add-In will be seen by the host so pay attention to the parameters on the constructor.

Set the build output path of each Add-In to: ..\Pipeline\AddIns\<addinName>\

I should mention that the Add-In's in the sample code below are just stubs to show the complete loop.  The Book Library Add-In returns empty objects of the prescribed types, the other two throw an Exception.  This is to show error handling.

Step 5:  The Add-In Host

Take a reference to the Host View and Dto projects, this time it is OK to have the reference Copy Local.

In the attached example the Book Library add-in returns empty objects of the designed type, however the other two (DVD Library and CD Library) throw an Exception for each operation. 

By the end of the process, the project will look like this:

Trouble shooting & Error Handling

Just skiming over this topic, but it is wise to wire up a handler to AppDomain.UnhandledException for the app domain that will run your Add-Ins, and Application.ThreadException (Windows Forms examples) as well as wrapping calls into the Add-In with a Try... Catch block. 

If you are trying to work out why your AddIns are not being discovered, remember that:

• AddInStore.Rebuild()
• AddInStore.RebuildAddIns()
• AddInStore.Update()
• AddInStore.UpdateAddIns()

...all return an array of strings that can be examined to determine how the AddIn discovery went.

Source Code:

The source code for this example is available for download from the following link:

LibraryAddInDemoCode_deepdark.net.zip (152.81 KB)

It requires Visual Studio Codename Orcas Beta 1.

Summary:

There are a couple of steps to implementing the new System.Addin stuff, but none of it is hard!

...and considering that it replaces a lot of very untidy and error-prone Reflection code that we had to do in prior versions of the framework I think this is a great addition to the toolbox.

This post is not meant to be a hardcore reference, just the total of my experience with this technology to date.  If you have any feedback please don't hesitate to contact me by email or leaving a comment on this post.

Sources:

• CLR Add-In Team's blog
• Jason He's CLR AddIn Model in Paint.Net series [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

Listening to: The Chillout Sessions 3

I think this question is really suited to two kinds of people:

1. Criminally insane.  Reckless to a point considered, well, imprudent.   You lick the top of 9V batteries; you chew on tin-foil.  You cut your toe nails with a Leatherman.  You bank the farm on a technology that is still moving because pain is your friend.
2. People who may ship a product before .NET 3.5 ships.  .NET 3.5 has some new technologies that I am going to want to use.  Three that are immediately relevant are: new Active Directory bits, System.AddIn, and the goldern haired child, Linq.

These are bits that (esp. Linq) I want to bake in.  Right now I don’t want to code up bits that I know I am going to have to rip out soon in order to replace with the richer platform.

My ship dates are uncertain… if the product name is anything to go by Orcas is at least 6 mths away.  The real question in this post is how to mitigate the risk of being ready to ship before the platform is, and what to keep an eye on.

Please feel free to leave a comment or email me if you have clues for the above question

IIS 7 & Longhorn Beta 3 already has a Go Live license.  I believe them when they say it is good quality, and I believe them when they say it may still change.  Is a similar license something that we may see for .NET 3.5 as more betas or CTP’s become available?

Update:  Feb 27 2008 is looking like the launch date for SQL Server 2008, Visual Studio 2008 & Windows 2008.

It became clear to me during my last blog post on the .NET landscape that it was going to grow into more than one post. 

Framework Versions

One fact that is important to note about the graphic in that post, and it was the catalyst for me making the drawing, is that the .NET 3.0 and .NET 3.5 frameworks do not supersede .NET 2.0 but augment it.

What I mean by this is if you were to look into your %WINDIR%\Microsoft.NET\Framework\v3.0 folder you do not get a new System.Data.Dll or System.Web.dll.  Instead you see the folders for:

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

If you look in your %WINDIR%\Microsoft.NET\Framework\v3.5.xxx\ (still beta at time of writing) the main thing to note here is a new csc.exe and vbc.exe.

So what do you get with .NET 3.5 & Visual Studio 2008 (codename "Orcas")?

• 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.

...and last but not least, the golden haired child, LINQ...

• 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.

When I started playing with LINQ, I needed to get some clarity on this in my mind, so in the spirit of Linnaeus, Mendeleev and Gell-Mann, I put together a graphic that showed the generations of the various bits, and after talking with friends thought it was worth sharing:

Update:  Daniel Moth has a better graphic for the same data on his blog first.  Shame, not an image map.

Mohammad Adil Akif also has a version in his blog.

...This is the blog version - the original form was a Post-It note.
...And in the spirit of Web 0.9 (which came before Web 2.0 the graphic is an image map

I know there is much more coming, like the Dynamic Language Runtime, Domain-Specific Language tools, Silverlight, and so on.   I've also chosen not to call out the versions of Team System, both in the interest of clarity.