Products, the Universe and Everything

The Riverblade Developer's Blog

Beth demonstrating Visual Lint at the ACCU Conference 2008  Anna taking part in a discussion panel at the European Software Conference 2007 

Welcome to our developer's blog. We hope that this forum provides an insight into us, our products and how we develop them. Please feel free to write to us if you have anything to add to any of the posts here.

Current Entries | Archives |

Visual Studio .NET Add-in installation
Tuesday, March 08, 2005

I said in my previous post I'd talk about add-in installation.

One of the most interesting ones concerns the installation of the add-in. Unlike the skeleton add-ins created by the Visual Studio .NET Add-in Wizard, Visual Lint creates its registry keys on registration as described by Oz Solomon in his article Project Line Counter Add-In v2.10 for VS.NET and VC6. Rather than duplicate that information here, I suggest you go and read the article - it's really quite interesting.

More interestingly, Visual Lint also removes its commands when unregistered (which happens using the uninstallation process). Although managed add-ins can do this easily by including a class derived from System.Configuration.Install.Installer, for unmanaged add-ins it's not so obvious how to implement the same functionality.

As you can see in the code sample below, we chose to remove commands in DllUnregisterServer(). The important bit is that in order to do so, an instance of the corresponding implementation of DTE needs to be created. As it turns out, this is really, really simple:
    // Create an instance of VS.NET 2003
EnvDTE::_DTEPtr ptrDTE = NULL;
Once an instance of DTE is available, it can be passed to methods in the add-in which use it to remove the add-in's commands from the corresponding version of Visual Studio, as the following code from Visual Lint shows:
static HRESULT RemoveCommands(LPCWSTR pszVisualStudioProgID)
EnvDTE::_DTEPtr ptrDTE = NULL;
if (ptrDTE != NULL)
CVsCommandsManager commands;
commands.OnConnection(ptrDTE.GetInterfacePtr(), NULL, NULL, NULL);
hr = S_OK;
catch (_com_error& e)
hr = e.Error();
return hr;
STDAPI DllUnregisterServer(void)
// Remove commands from VS2005, 2003 and 2002 respectively
HRESULT hrVS2005 = RemoveCommands( L"VisualStudio.DTE.8.0");
HRESULT hrVS2003 = RemoveCommands( L"VisualStudio.DTE.7.1");
HRESULT hrVS2002 = RemoveCommands( L"VisualStudio.DTE.7");
HRESULT hr = _Module.DllUnregisterServer();
return hr;

Note that CVsCommandsManager is part of our implementation and not a class generated by the add-in wizard. Whilst its normal job is to manage the CVsCommandHandler objects which implement each of Visual Lint's commands, it is also created in a standalone form during add-in uninstallation as seen above.

Together, these changes seem to have the potential to greatly reduce installation issues, and we fully intend to include this functionality in the next version of ResOrg.

Posted by Anna at 19:28 | Get Link


LintProject 1.2.4 released
Monday, March 07, 2005

We're pleased to announce that a new version (1.2.4) of our LintProject command line tool is now available. The changes in this version are as follows:

  • CSolutionLintAnalyser::Analyse() and CProjectLintAnalyser::Analyse() now use SHCreateDirectoryEx() instead of mkdir() to create folders for analysis results so that recursive folders are automatically created.
  • Corrected UNC path checking as suggested by users on the LintProject CP forum.

  • Improved handling of relative pathnames. Analysis and source files no longer need reside on the same logical drive.
  • Added support for passing parameters directly to lint-nt.exe via a new command line option (/l"").
  • If a warning count of 255 is returned from lint-nt.exe. CFileLintAnalyser::Analyse() will now parse the results file to try to retrieve the true warning count.
  • Reimplemented the FileExists() helper function.
We hope you'll find this version a worthwhile upgrade. Early feedback certainly indicates that to be the case.

FYI, next on the list is likely to be the ability to specify the configuration to Lint (Debug, Release etc.). Although this is straightforward enough (and already supported in Visual Lint), being a Visual Studio add-in it has the advantage of access to Visual Studio's extensibility model...which of course LintProject doesn't have (it has to parse the solution/project files instead).

Another requested feature is to implement a way of linting a complete project without recourse to unit checkouts (PC-Lint's -u switch, which LintProject currently uses to analyse a single file). I have to say that so far we can't see a straightforward way to do this and retain the level of progress reporting LintProject currently has, but we'll certainly keep looking at it.

Of course we're always happy to hear your suggestions for new features, so keep them coming!

Posted by Anna at 22:41 | Get Link