Tag Archives: development

KeePass PLGX build automation

One of KeePass Password Safe’s strengths is the ability to install plugins. This keeps the main application simple and hence (potentially) more secure. Developing plugins for KeePass and installing them has always been pretty straight forward but starting with KeePass 2.09 there is a new plugin format which now means that your plugins will not need to be re-compiled every time a new version of KeePass is released. If enough plugin authors migrate their plugins to this new format then this should gradually remove some of the barriers that discourage users from promptly upgrading to the latest version of KeePass.

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 FilesKeePass 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

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)PropertiesAssemblyInfo.cs" "%KPPTempDir%PropertiesAssemblyInfo.cs"
if errorlevel 1 goto BuildEventFailed
mkdir "%KPPTempDir%generated"
copy "$(ProjectDir)generatedKeeICE.cs" "%KPPTempDir%generatedKeeICE.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 addonKeeFoxdepsKeeICE.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).

Visual Studio 2008 installer project tips

No doubt there are entire teams of people dedicated to understanding the Microsoft Windows installer system (.msi files) but for me it is just a means to an end. I didn’t find it a particularly accessible technology so from the point of view of someone interested in deploying the output from a Visual Studio 2008 project onto end user systems, here are a couple of the gotchas I came across.

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.

KeeFox task list


Please see http://sourceforge.net/apps/trac/keefox/report/3 for an up to date task list.

All dates are just an early estimation and I won’t be making any effort to treat them as deadlines but I hope they are vaguely realistic. Task assignments to particular versions are just a prediction of where I currently think a feature could fit into the project development timeline but again, it’s all subject to change as the project develops.

ongoing tasks

  • Review of code to reduce memory leaks and improve performance
  • Development of thorough self-test routines
  • Locale development (translation of user interface to other languages)
  • Peer-review of code to highlight security issues
  • icon. fox + padlock? copyright issues if too similar to firefox or KP?

0.1 [August W4]

  • FF LoginManagerStorage implementation (maybe missing some parts like entry deletion or http realm logins) [2008-10-05: done then cancelled]
  • prompt for DB open as required [2008-10-05: done]

0.2 [September W3]

  • handle keepass start and close events in FF (how to tell difference between KP not running and not-installed? ICE runtimes?) [2008-10-05: partially done]
  • complete LoginManagerStorage impl. if required (what happens with “clear passwords” integration?!, etc.) [2008-10-05: cancelled]

0.3 [October W3]

  • Improved LoginManager (ILM) [2008-10-05: moved from 0.4]
  • ILM: replicate built in login manager (extend existing JS code) [2008-10-05: moved from 0.4]
  • ILM: handle disabling/enabling built in login manager – options + (un)install [2008-10-05: moved from 0.4]

0.4 [November W4]

  • Allow choice between standard and ILM? [2008-10-05: cancelled]
  • Make sure passwords don’t get corrupt when swapping between LMs [2008-10-05: cancelled]
  • Clean LM swaps (data migrations if necessary) [2008-10-05: cancelled]
  • match multiple domains for one KP entry (e.g. hotmail, live.com)
  • Cleanly manage “new user” experience in terms of downloading keepass and setting up new database [2008-10-05: partialy done; moved from 0.3]
  • Deal with non-installed pre-requisites (e.g. KeePass v2) [2008-10-05: partially done; moved from 0.3]
  • Package/release system (XPI?) [2008-10-05: planned and mostly done; moved from 0.3]
  • test binary / installation process on seperate machine

0.5 [December W4]

  • XUL locale support [2008-10-05: moved from 0.3]
  • FF based options control system
  • configurable default database and group
  • Folders/groups – probably through integration with KP Groups and Firefox places (FFP)
  • FFP: tie places URL to KP URL
  • FFP: custom places view? used to render a “quick login” drop down menu system
  • publish first binary version

0.6-0.7 [January/February]

  • integration with some other plugins. e.g. Nexus’s Firefox to KeePass
  • FFP: integrate with location bar drop down list, history and bookmarks folder (option to log in straight from there)
  • FFP: options to show/hide links without logins in main drop down system
  • configurable custom-data location
  • ILM: support for deleting passwords, etc.
  • ILM: auto-submit
  • ILM: modal box option [2008-10-05: may not be done before version 1.0]
  • ILM: in-page pop-over login option
  • ILM: default auto-submit selection, with hot-key over-ride
  • (beta 1?)

0.8 – 1.0 [March – July 2009]

  • ILM: allow option to not require master password for everything [2008-10-05: moved from 0.4; may not be done before version 1.0]
  • ILM: Support for custom fields (e.g. radio buttons, checkboxes, PIN numbers, etc.)
  • Save after first registration functionality (ILM only?)
  • track how many times logins used (FFP: show popular sites, order by frequency, hide infrequently used etc.)
  • User-identified “essential improvements”
  • thorough bug testing
  • user documentation
  • user help,tooltips,wizzards,etc.
  • notices, etc. in appropriate places in main firefox UI so user knows KeePass is storing passwords
  • (beta 2, RCs?)


  • Identities (inc. openID?)
  • KeePass v1 support

Maybe TODO

  • Force KeeICE to only communicate with KeeFox
  • SSL encrypt ICE communication channel (store private key in KP DB?)
  • OpenID: Haven’t given this enough thought but maybe some integration of openID features could be good.