XCopy install of ReportViewer assemblies

A recent project at work was a Console C# application that used .Net 2.0's LocalReport class to generate letters. To ease deployment, I prefer to distribute an application via copying instead of using an installer. A frequent problem for users of the LocalReport class is that it requires three assemblies that are not part of the .Net 2.0 Framework (but confusingly, are part of VS 2005). Whilst these assemblies can be installed (to the GAC) via Microsoft's ReportViewer re-distributable (SP1), this breaks the principle of an xcopy install. The solution of course is to locate the required assemblies and mark them as CopyLocal in the project that requires them.

This should be no problem of course, as the first two assemblies show up in the .Net reference list:

• Microsoft.ReportViewer.WinForms.dll
• Microsoft.ReportViewer.Common.dll

Inspection of the second using Reflector reveals the third to be:

• Microsoft.ReportViewer.ProcessingObjectModel.dll

which Reflector fails to locate - but why, if has been successfully installed? Even a search of the System partition fails to locate it.

The answer is the platform agnostic GAC (%SystemRoot%\assembly\GAC_MSIL). Its contents are seemingly invisible to searching: the only way to access them is:

1. Via the command-shell, e.g. via a command-prompt, cd/explorer into %SystemRoot%\assembly\GAC_MSIL.
2. Via Microsoft's gacutil.exe.
   

Doing this allows you to locate the third assembly at:

• %SystemRoot%\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel\8.0.0.0__b03f5f7f11d50a3a
  

It can then be copied somewhere visible to the project (e.g. the application's lib directory) and added to the list of CopyLocal dependencies.

How long to change a culture?

A current project I have on the go is writing a C# console app to replace an ageing VB5 application.

For many on the project, this is the first time writing production C# instead of VB. In addition we're aiming at a SOLID design, aided by NUnit, Spring.Net and of course Cruise Control.Net.

A reoccurring challenge we've faced on this project is re-learning how to write software. Its more than just learning a new language, tool or framework, its more like loosing the shackles of apartheid. This analogy may seem a little strong, but it was quite clear to me after discussing with an Afrikaans South African (in his 20's) just how long it would take for his country to be free of apartheid's effects: we concluded at least three more generations.

Whilst I know that the team won't have to be great-great-great-grandparents before we loose the shackles of VB and procedural programming, I need to remember that cultural of change of any sort doesn't just happen overnight!

This was further driven home to me today when ThoughtWorks met with us to discuss an upcoming project. They shared how to aid culture change, they send newbies on a boot-camp that lasts 6-8 weeks!