This week I shall be celebrating with cake because KeeFox 1.0 has been released. More information is available at http://keefox.org/2012/05/01/keefox-10/
Please visit the KeeFox help centre for KeeFox support.
Next week I will probably eat cake anyway… just like last week.
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 :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)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).
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.
THIS PAGE IS DEPRECATED
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.