This article outlines how I moved my KeeICE plugin to the new format and shows how the PLGX build can be integrated with Visual Studio. (KeeICE is the KeePass plugin that the KeeFox firefox add-on communicates with – a beta release is (still) not far away).

First, check out the documentation and maybe the forum post where the feature was first announced.

I found that they explained the benefits (and small limitations) of the new format and it wasn’t long before I had a PLGX version of my plugin built and loaded into KeePass.

After a variety of changes to my installation routines (so they know to deal with one PLGX file rather than the previous two DLL files) the only remaining challenge was to find a way to package the PLGX quickly. To do this I modified my post-build event so that once Visual Studio has built the plugin DLL, the PLGX creation process happens automatically. This fits in nicely with my existing build process and ensures that I can quickly build a fully packaged Firefox add-on, ready to be shiped onto test virtual machines and the few other PCs I usually have bleeding-edge versions of KeeFox running on.

Of course, I also want to debug my KeePass plugin from time to time so my post-build script needs to put the actual plugin DLL (and dependancy) into the KeePass plugins directory whenever I am running Visual Studio in the Debug configuration (my debug command is set to load KeePass and Firefox so the plugin and add-on need to be in place by the end of the build process).

I have put the post-build script below in case anyone else finds it useful. You will need to read through it and modify it in a few places to suit your particular plugin and its dependencies (or lack thereof) but it should be almost ready for a quick copy and paste into your Visual Studio configuration. NB: The script assumes that the KeePass plugins directory already exists.

echo POSTBUILDSTEP for $(ProjectName)

set KPDir=C:\Program Files\KeePass Password Safe 2\
set KPPDir=%KPDir%plugins\
set KPPTempDir=%KPPDir%$(ProjectName)

IF NOT "$(ConfigurationName)"=="Debug" Goto :NotDebug
REM In debug mode we want to move the generated DLLs and PDBs to the plugins
REM directory so we can easily set breakpoints, etc.
REM In this case, we don't care if the Firefox add-on has missing or outdated
REM files (they are only used at install time so it won't affect debugging)

REM delete the PLGX from any previous Release build
del /Q "%KPPDir%$(ProjectName).plgx"
if errorlevel 1 goto BuildEventFailed
echo Release plgx deleted

REM copy output DLLs to KeePass plugins directory
copy "$(ProjectName).dll" "%KPPDir%\$(ProjectName).dll"
if errorlevel 1 goto BuildEventFailed
copy "Ice.dll" "%KPPDir%\Ice.dll"
if errorlevel 1 goto BuildEventFailed
echo Debug DLLs copied to plugins directory

goto BuildEventOK

:NotDebug
IF NOT "$(ConfigurationName)"=="Release" Goto :NotRelease
REM In release mode we want to make sure that we are working with the PLGX version.
REM For the KeeFox project we will be in this mode quite a lot (whenever working
REM primarily on the Firefox add-on part of the project rather than KeeICE)

REM delete the DLLs from any previous Debug build
del /Q "%KPPDir%$(ProjectName).dll"
if errorlevel 1 goto BuildEventFailed
del /Q "%KPPDir%Ice.dll"
if errorlevel 1 goto BuildEventFailed
echo Debug DLLs deleted

REM create temporary directory
rmdir /S /Q "%KPPTempDir%"
mkdir "%KPPTempDir%"
if errorlevel 1 goto BuildEventFailed
echo Temporary directory created

REM copy relevant project files to temporary directory
REM (for simple KeePass plugins you may need to
REM copy only *.cs files and .csproj file)
copy "Ice.dll" "%KPPTempDir%\Ice.dll"
if errorlevel 1 goto BuildEventFailed
copy "$(ProjectDir)*.cs" "%KPPTempDir%"
if errorlevel 1 goto BuildEventFailed
copy "$(ProjectDir)$(ProjectName).csproj" "%KPPTempDir%\$(ProjectName).csproj"
if errorlevel 1 goto BuildEventFailed
mkdir "%KPPTempDir%\Properties"
copy "$(ProjectDir)Properties\AssemblyInfo.cs" "%KPPTempDir%\Properties\AssemblyInfo.cs"
if errorlevel 1 goto BuildEventFailed
mkdir "%KPPTempDir%\generated"
copy "$(ProjectDir)generated\KeeICE.cs" "%KPPTempDir%\generated\KeeICE.cs"
if errorlevel 1 goto BuildEventFailed
echo Files copied to temporary directory

REM create the PLGX
"%KPDir%KeePass.exe" --plgx-create "%KPPTempDir%"
if errorlevel 1 goto BuildEventFailed
echo PLGX created

REM copy PLGX to Firefox addon folder (for packaging in a .xpi later)
REM copy "%KPPDir%KeeICE.plgx" "$(SolutionDir)Firefox addon\KeeFox\deps\KeeICE.plgx"
REM if errorlevel 1 goto BuildEventFailed
REM echo PLGX copied to Firefox add-on

REM delete the temporary directory and its contents
rmdir /S /Q "%KPPTempDir%"
if errorlevel 1 goto BuildEventFailed
echo Temporary directory deleted

goto BuildEventOK

This is all tested on Visual Studio 2008 on Windows XP SP3 but I have had this page bookmarked for a while in case I come across similar problems on newer versions of Windows. It might be useful if you’re running Vista or 7 and run into any problems copying the files into the KeePass directory (basically, take a sledgehammer to the permissions on the plugins directory).

First, there is a registry key on the end user system which should record the location into which the installer deployed the output of your project (maybe the end user choose this through an install wizard). I mistakenly assumed that Microsoft’s Visual Studio installer project would automatically handle the basics like this, but no. The answer was in this recent blog post: Using a Post-Build Script to set the InstallLocation property in VS Setup Projects – the author includes a handy script which you can just drop into your project to fix this problem.

The second problem was an error message I received when installing my project:

Error 1001. Unable to get installer types in the [...] assembly. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Although missing DLL dependencies and pre-requisites are already published known causes for this problem, that didn’t quite reveal the true cause in my case. The reason I experienced this error is because:

1) I had set up a custom install action in my main project assembly (to add the install folder to the system path)
2) I had redirected the primary project output to an alternative folder (rather than the default “Application folder”)

So the quick fix was to add a second project output to the installer so it now puts the DLL into my alternative folder as well as the main output folder (along with all its other DLL dependencies). Hopefully there is a neater way to do this which doesn’t clutter the end user’s system with two copies of the same file but I’m in no rush to find it because I just want to get on with some real development work rather than trying to understand VS2008 installer project limitations.