dnGrep, and the search engines it keeps in separate projects

What dnGrep searches, and the four query languages

dnGrep is a Windows search utility that takes the idea of grep and extends it into the file formats a Windows desktop actually contains. The README describes searching across text files, Word, Excel and PowerPoint documents, PDFs and archives, and the distinguishing feature is the set of query languages it accepts: text, regular expression, XPath, and phonetic.

That last list is worth slowing down on, because three of the four are unusual for a desktop search tool. Regular expression and plain text are what you would expect from something called dnGrep. XPath is a query language for navigating structured documents, and it is exactly the right tool for a Word document with tables, headings and numbered clauses, where a regular expression cannot express a constraint and a plain text search cannot tell you where in the structure the match was. Phonetic search is stranger still, and it exists because names in the documents people search are often spelled inconsistently across systems.

The consequence is that dnGrep is not one search with a file filter. It is four query front ends over a set of format-specific back ends, and which combinations work depends on what the engine for that format can parse. An XPath query against a PDF is a different question from an XPath query against a Word document, and the README does not document which combinations are supported. That is the first thing to establish if you are evaluating it for a specific corpus.

The intended audience is narrow and obvious: someone on Windows who knows how to use grep and has hit the moment where the answer is inside a spreadsheet or a PDF and there is no tool on the machine that can see it. The project describes itself as a great Windows search utility, and the graphical interface is the point, since the alternative for most people is installing a command-line tool and learning its switches.

It is also worth noting what the README is not. There is no feature matrix, no screenshot set, no benchmark, and no discussion of limits. The project splits its audience deliberately: users are sent to a separate web site to download and install, and developers are sent to a wiki page covering the continuous build and release process. This repository is a pointer document with a licence and a signing policy attached.

Two Office engines, and why that duplication is probably deliberate

The top-level directory listing contains `dnGREP.WordEngine` and `dnGREP.OpenXmlEngine` as separate projects, and the duplication is the most interesting thing in the tree.

Modern Office documents are Open XML, a zip archive containing XML parts with relationships between them. That format is well suited to structured search: a table is a table in the file, a heading is a heading, and an XPath expression can address content by its position in the document structure rather than by proximity to a string. So a dedicated Open XML engine is the obvious design for Word, Excel and PowerPoint files in their current format.

Then what is the Word engine for? The most likely answer is the legacy binary formats, the pre-2007 Word document format and the older Excel workbook format, which are not Open XML and cannot be read by an Open XML parser at all. A search tool that claims to open Word and Excel files is claiming to open files from twenty years of format history, and the only way to do that is a second engine that understands the older container.

That inference is not stated in the README, and the contents of those two projects are not described anywhere here, so treat it as the most probable reading rather than a documented fact. What is documented is the existence of both projects and the claim that Word, Excel and PowerPoint documents are searchable. The useful conclusion either way is the same: a format that no engine covers is silently missing from your results, and a search across a mixed folder of old and new documents may cover some files and skip others with nothing in the interface to tell you which.

The rest of the engine structure follows the same pattern. There is a `dnGREP.PdfEngine` for PDFs, and a `dnGREP.Engines` project that is presumably the abstraction the other three plug into, since a name without a format attached is usually the interface. That structure is the right one. It means adding a format is a new project implementing a contract, rather than a switch statement in a search routine, and it means the four query languages are implemented once against the abstraction rather than four times per format.

AvalonEdit, SevenZip, DockFloat and NetDiff are all in the tree

Four third-party codebases are vendored directly into the repository, and each one tells you something about a dependency the project could not take as a package.

`ICSharpCode.AvalonEdit` is the text editing control the application uses. It is checked in rather than referenced, alongside a top-level `Dependencies` directory, which suggests a mix of NuGet packages and in-tree source. AvalonEdit is the editor component used by SharpDevelop and related tools, so this is a well-known control, and the reason for vendoring is usually a needed patch or a build that has to work without a package restore.

`SevenZip` is more clearly motivated. Archive support in a search tool means opening zip, 7z and similar containers and searching their contents, and the standard way to do that on Windows is to use 7-Zip. Checking the source in means dnGrep can search inside archives without requiring 7-Zip to be installed, which for a search utility distributed as a single installer is a significant simplification. It also means a security-relevant dependency is compiled in rather than loaded, and that the licence of 7-Zip is a question alongside the project's own.

`NetDiff` is a diffing library, and `dnGREP.DockFloat` is a docking and floating panel framework, the kind of component that lets a search results window dock against the main window instead of floating loose. Both being in-tree suggests a project that prefers to control its dependencies rather than track them, which is a defensible position for a desktop application that has to keep working on machines its author cannot test.

The legal consequence of vendoring is worth stating plainly. The project itself is GPL-3.0, which is a strong copyleft licence and requires that a distributed binary's corresponding source be available. Vendored third-party components bring their own licences into the same binary, and those licences are not necessarily GPL. The README's code signing policy actually acknowledges this from the other direction, noting that the install kit contains third-party libraries which may or may not be signed. So a reader of this repository should expect a mix of licences in what they install, and the `license.txt` at the root covers only the project's own code.

Two more small entries in the tree are worth naming. `dnGrep.snk` is a strong-name key file, meaning the project strong-names its assemblies, which is a Windows requirement for certain deployment scenarios and a good sign of engineering discipline. `ResXManager.config.xml` indicates that .NET resource files are managed by a dedicated tool rather than edited by hand, which is what you need once a project has translations.

dnGREP.Everything, the context menu, and two different ways to find files fast

Two directories in the top level show how dnGrep relates to the rest of a Windows desktop, and both involve other programs.

`dnGREP.Everything` is an integration with Everything, the file indexing utility that maintains a near-instantaneous index of file names on a Windows machine. That is a very different capability from what dnGrep does, and pairing them makes sense: Everything answers where is the file, dnGrep answers what is in it. A search tool that indexed file contents the way Everything indexes names would be a much larger project, and this is the shortcut instead, use someone else's index for the first half of the problem.

`dnGREP.ContextMenu` and `dnGREP.ContextMenuPkg` are a shell context menu extension and a package variant of it. In practical terms, that means you can right-click a folder in Explorer and search it without launching the application first. The `Pkg` suffix on the second one is the tell, because that is the naming convention for a Windows packaged application component, which is what an MSIX-packaged app registers instead of a traditional installer.

Both of these are decisions about where the application meets Windows rather than about search. They are also the parts most likely to be affected by platform changes, since a shell extension runs inside the Explorer's process and is subject to whatever restrictions Microsoft applies to in-process code. A context menu handler that crashes takes the folder view with it.

The privacy policy in the README belongs in the same discussion, because it is short and specific. The program does not transfer any information to other networked systems unless specifically requested by the user or by the person installing or operating it. It does periodically check github.com for new versions, transmits no user information with that check, and the check can be disabled by the user in the options.

For a tool that reads every document in a directory, a privacy statement that says it does nothing is worth reading carefully rather than skimming, and this one is specific enough to be checkable. The version check is the only network behaviour described, it goes to github.com, and there is a documented way to turn it off. A search tool that phones home with a query would be disqualifying for a lot of people, and this one does not appear to.

What is signed, and the exact limit of that guarantee

The code signing section is the most carefully worded part of this README, and the precision is the point.

Since version 3.0, the MSI installers and the binary files are signed. The signing is free code signing provided through SignPath.io, using a certificate from the SignPath Foundation, which is a non-commercial signing service for open source projects. The certificate is a foundation certificate rather than a commercial one from a public authority, so what it proves is that the binary came from this project's build and was not modified afterwards. It does not prove the code is safe.

The scope statement is where most projects would stop and this one does not. Signing is applied only to dnGrep project code, in the release branch of the repository, built on AppVeyor. And the install kit contains third-party libraries used by dnGrep which may or may not be signed.

Put those two facts together and you have a precise trust model. The parts of the installer that are the project's own are verifiable end to end, from a signature back to a specific commit in a specific branch built on a specific continuous integration service. The parts that came from AvalonEdit, 7-Zip, the docking framework and the diff library are, in part, not covered. Anyone performing a supply chain review of this software is therefore reviewing two trust domains, not one, and the project tells you so rather than letting you assume the whole kit is signed.

The AppVeyor detail also matters for reproducibility, and not only for the signature. If the signed artefacts are produced only on one continuous integration service from one branch, then the question of whether a given binary was built from a given commit is answerable, which is the property you need when a security researcher wants to check whether a fix is in a released build.

The remaining caveat is the usual one. A signature establishes provenance, not quality. A project whose signing key is compromised, or whose AppVeyor account is taken over, produces correctly signed malware. Signing narrows the set of things you have to trust; it does not make trusting unnecessary.

MSI, MSIX, three architectures, and a build counter for a version

The packaging story in the repository tells you the project is being maintained for a Windows version range rather than for one machine generation.

The release artefacts named in the README are MSI installers, and the repository contains `make-msix.ps1`, a script for producing MSIX packages. Both formats in parallel is a deliberate choice: MSI is what enterprise deployment tooling and Group Policy understand, and MSIX is what modern Windows packaging and the Store expect. A project that produces both is a project whose users include both a home machine and a managed corporate desktop.

Architecture support is visible in three files at the top level, one each for x86, x64 and ARM64, named as exclusion lists. The existence of a per-architecture list at all means the packaging differs between architectures rather than being one build copied three times, and the presence of ARM64 means Windows on Arm is a supported target. That is worth noting on its own, since ARM64 Windows is still a minority platform and a small utility that supports it is ahead of the average.

The rest of the build infrastructure is conventional and competently arranged. `appveyor.yml` is the continuous integration definition, matching the README's statement that signing happens on AppVeyor. `global.json` pins the .NET SDK version, which is the mechanism that stops a build from silently using a different toolchain on a different machine. `dotnet-install.ps1` installs that SDK. `Directory.Build.props` holds properties shared across projects, `vs.testsettings` configures the test run, and `patch-rc-version.ps1` patches a release-candidate version into the resources, which is the mechanism behind the letter suffix you see on some release names.

One small entry deserves a mention because it is a modern choice made in a mature codebase. The solution file is `dnGREP.WPF.slnx`, in the new XML-based solution format rather than the traditional one. Adopting that format is a signal that the project is tracking current tooling rather than maintaining a build that stopped years ago, and the project directory names, all in the WPF style, tell you the user interface is built on the Windows Presentation Foundation even though the README never mentions it.

There is also `build.txt` at the root, a plain file of build notes, and `README.md` alongside `license.txt` with a lowercase name, which is a small inconsistency in a project that is otherwise careful about naming.

dnGrep against grep, against Everything, and against a content index

Three comparisons, and they are genuinely different tools rather than three versions of one.

Against grep itself, the difference is scope. GNU grep, or its Windows equivalents, read text. Given a folder of Word documents, PDFs and zip files, grep returns nothing useful, because those formats are containers rather than text. dnGrep is the answer to a question grep cannot be asked, and for a folder of plain text files the two do the same job, with dnGrep adding a window.

Against Everything, the two are complements rather than competitors, and the repository says so by containing an integration project. Everything indexes file names and metadata, which means it can find a file in milliseconds across a whole disk. It cannot search inside a document. dnGrep reads contents and can answer what is in the file, at the cost of opening every candidate file. The combination, which is what the integration project enables, is index for the where and content search for the what.

Against a content-indexing search tool, the difference is a build-versus-browse trade. A tool that indexes file contents once and then queries the index is dramatically faster for repeated searches over the same corpus, and it pays for that with an indexing pass, disk space for the index, and the possibility that the index is stale relative to the files. dnGrep reads on demand, so it is always current, it needs no maintenance, and its cost is proportional to how much you search.

Which one is right depends entirely on the shape of the work. A single search across a folder of a few hundred documents, occasionally, is exactly the case dnGrep fits. Searching the same corpus every morning for the last week's reports is a case where an index pays for itself immediately, and dnGrep will feel slow.

There is also a limit worth stating that has nothing to do with the comparison. dnGrep is Windows-only by design, and it is a desktop application rather than a library, so there is nothing to embed. If your documents live on a file share and your users are on macOS or Linux, the equivalent work needs a different tool entirely, and no amount of configuration changes that.

Editorial conclusion

Adopt dnGrep when you need to search the contents of Office documents, PDFs and archives on Windows and cannot install anything else, since that is the capability nothing in the standard toolchain gives you. Do not expect it to be fast on a cold directory, because it reads file contents rather than indexing them, and check what is signed before installing in a managed environment, since the README says third-party libraries in the install kit may not be. Verify first by pointing it at a folder of Office files and trying an XPath query, confirming the version check can be disabled in the options if your environment blocks outbound requests, and comparing a result against a plain recursive text search to see which formats it actually covered.

Frequently asked questions

Official sources

1. dnGrep/dnGrep on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases