I have made several updates to the Codoxide.Common Library and moved the project over to SourceForge.net.

The project's new home is codoxidelib.sourceforge.net and the new SVN repository is https://codoxidelib.svn.sourceforge.net/svnroot/codoxidelib/trunk

Today I'm so excited to announce the first release of the Codoxide.Common Library. I haven't been over ambitious about the version numbering as I want you to treat this library to still be in concept stage.  

Unfortunately, this release had taken longer than expected cos of my newly cramped up schedule. Worst part of that is I'm posting this code without proper documentation (yep, excuses!). Nevertheless, there's plenty of code in here to prove useful to many. So here goes!

Features/Components

Patterns

• SharedInstance<T>
• Singleton<T>
• Factory e.g. Factory.Build<T>()

Configuration

• ConfigurationManager<T>
• ConfigurationSectionBase

Data

• Database<CONNECTION_TYPE, COMMAND_TYPE, ADAPTER_TYPE>
• Map<T>

SharedInstance<T>

SharedInstance is actually the most basic type of generic Singleton implementation that's been around in the C# community. This implementation was both simple and efficient. But, it violated the definition of a Singleton by depending on the presence of a public constructor and thereby allowing additional instances to be created. Therefore, I have refrained from calling this a Singleton resorted to the term SharedInstance.

E.g:

Singleton<T>

More advanced implementation of the generic Singleton implementation. Uses reflection, custom attributes and "lazy initialization" to provide a powerful way to create and initialize your singletons.

E.g:

Factory.Build<T>

This one's another powerful and unique implementation. Coolest feature of this class is that you can do something like the following:

This allows developers of class libraries to write their code using interfaces or abstract classes, leaving the library users to specify the concrete classes via configuration files.

Grab the Code

There's of course, plenty more to be documented regarding the library. And you can expect the project space to be updated in coming (err..) weeks .

Until then, you can:

Check out the code (using SVN): https://codoxidelib.svn.sourceforge.net/svnroot/codoxidelib/trunk

Browse the project space: http://codoxidelib.sourceforge.net/

Detecting and Deploying Prerequisites

This is the 2nd of a multi-part series on deploying VSTO Applications using NSIS. Part 1 of the series can be found here.

Step 4: Ensuring MSI 3.1 is available

Before proceeding you need to make sure the client computer has MSI 3.1 installed. Click here to find out how.

Step 5: Checking whether Excel is Installed

Being an Excel Worksheet-Level Customization, it makes no sense for this app to be deployed on a computer that doesn't have MSO Excel 2003 Professional installed. Lets see how we can achieve this. If you do a bit of research you can find out that with VS Deployment Projects, this is achieved by doing a Windows Installer search for the component ID {A2B280D4-20FB-4720-99F7-40C09FBCE10A}.

Since performing a Windows Installer Search is a common and desirable feature, I came up with the following macro:

When invoked, this macro will generate a function, with the give name that will search for the specified Component ID. So the code to detect Excel 2003 becomes:

So, why did I make this a macro that generates a function, and not just a function that accepts the component ID as a parameter? Well, parameter passing is not that straight forward with NSIS, and I believe this leads to much cleaner code at the end.

Step 6: Ensuring .NET 2.0 Runtime is Present

You can find plenty of ways to do this on NSIS web site. Here's one of them.

Step 7: Ensuring VSTO is Present

We now have the scripts in place to deploy the application components as well as the to determine all prerequisites are available. All that is left is to add the boiler place Update Manifest and Set Security code. Easiest way to do this is to bring the code over a new .NET EXE project and pass the installation-dependent (e.g. Installation Path etc.) parameters as command line arguments. You can then execute the EXE as the last step of the installation.

For a little over a year, we’ve been working on a very sophisticated Microsoft Excel 2003 Document Level Customization project. We have nothing but pride towards the ingenuity of this application. But, there was one aspect that consistently overshadowed its success: Deployment.

Visual Studio Deployment Projects help you generate a setup app quickly and easily. It has the ability to look up source projects and determine all the components that need to be deployed. This makes things remarkably easy when you want a rudimentary installation. But, for anything out of the ordinary,  you will find that this offers you very limited help. To workaround these limitations you have to pick up a tool called Orca. Now, here’s where things get really dirty.

To use Orca, you have to have some semblance of the MSI database format. That isn’t actually so bad. A simple search on the Internet will fetch you loads of information regarding the subject. But, figuring out the format is just the beginning. You then have to weed your way using some ugly hacks. That's not all; you have to reapply those hacks with each build. If you are willing to live with the inconveniences, there's still a lot you can achieve using Orca. Musical Nerdery has a neat example on the subject.

Anyway, the point is we got sick and tired of working within these constraints and started looking for alternatives. After some serious considerations we opt to go with NSIS (Nullsoft Scriptable Installer Suite). We were mostly excited about its low footprint and its powerful scripting language.

This post is the first of a series in which I'm going to guide you through the steps involved in migrating your existing VSTO deployment package to NSIS. Before we begin, I should point out a few of the downsides to using NSIS.

1. NSIS doesn't understand VS Projects. It cannot scan through your projects and determine which components are relevant. You have to figure out all the files/dependencies you must deploy on to the client PC. Easiest way to do this is by creating a VS Deployment Project and let it tell you which files you need.
2. It cannot perform automatic rollbacks. If you want the user to be able to cancel the installation midway (after some files have already been deployed), you have to roll back the installation yourself using scripts. I'd argue that this is only a minor concern.

Since basic tutorials on NSIS scripting are widely available, I'm going to skip over the basics. You can learn about them here if you need to.

Step 1: Add a Visual Studio Deployment Project to your VSTO Solution

For the purpose of this tutorial I'll be using a really simple Excel 2003 Document Level Customization project called NsisDemo. All it does is display a message box saying "NSIS Rocks!!!" You can download it here or use your own VSTO project and include a VS Deployment Project as I have done.

Step 2: Begin your NSIS Script

Now, fire up your favorite text editor. I tend to prefer Notepad++ which offers syntax highlighting for NSIS scripts. Create the basic skeleton of a NSIS script in a sub folder of your main solution folder. If you need help getting started check out HM Nis Edit to generate a script for you, or use this one: Sample NSIS Start Script (2.4KB).

Step 3: Include Files that will be Copied to Client Machine

Open your VS Deployment Project. Go to the File System Editor and take a look at the file list under Application Folder.

Lets go ahead and add these files to our script. You'd need to modify the main installer section as well as the uninstaller section.

Note that all the non-user files (files other than NsisDemo.xls and NsisDemo.dll) are part of the Office 2003 PIAs. You might chose to deploy these files properly using the PIA installer. But, for now lets keep things simple and stick to copying them to the install directory.

At this point you may compile the script to generate an executable installer file. However, the VSTO application deployed through it will fail at run time as there are lot more missing pieces we need to stitch in to it.

Up next: Part 2

After weeks of inactivity, I finally managed to get a demo project in place for the BreadCrumbs controls. You can download it here. The code includes few updates I have made since the last version. For the sake of flexibility, I have kept the basic control as simple as possible. In the demo, I have added few additional helper classes to provide the full functionality desired.

Extending the control is pretty simple too. For instance, to display the menus for each of the sub items in a list item, you handle the SubItemClicked event. The SubItemClickedEventArgs passed to you along with this event provides you with the row index, column index and the bottom-left corner pixel coordinates of the sub item. In the demo app, this event handled as;

Here, the _entityMenu is a pre-constructed menu while as the "Template Menu" is reconstructed every time based on the selection.