NetOffice: Office automation and add-ins without VSTO
🌌 Extend and automate Microsoft Office applications using NetOffice framework.
At a glance
- What is it?
- NetOffice gives .NET developers the Microsoft Office object model through libraries that are syntactically and semantically identical to the Interop Assemblies, without needing VSTO, without registration and without interop assemblies of their own. It suits teams automating Excel, Word, Outlook, PowerPoint and Access, or building add-ins that install without deployment friction.
- Who is it for?
- Use NetOffice when your .NET application has to drive or extend Microsoft Office and you want the familiar Interop Assemblies API without the deployment overhead of VSTO, especially for add-ins that must install cleanly on a user machine. Do not choose it if you need to run Office on a server without Office installed, since the design is built on COM and on the Office object model itself, and treat the version range with care.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The Interop Assemblies API, kept
NetOffice is a set of libraries for building Microsoft Office add-ins and for automating Microsoft Office applications, covering Excel, Word, Outlook, PowerPoint and Access. The language is C#, the licence is MIT, and the packages are published on NuGet.
The design decision that defines the project is compatibility. The README states that NetOffice is syntactically and semantically identical to the Microsoft Interop Assemblies, and that there is no training if you already know the MS Office object model because you can use your existing PIA code. The first two features on the list follow from that: Microsoft Office integration without version limitations, and all features of the Office versions 2000, 2002, 2003, 2007, 2010, 2013 and 2016 are included.
That last point is unusual. The Interop Assemblies are versioned, and a PIA built for one Office release can fail to load against another. NetOffice's claim is that the whole object model from those Office versions is present in one set of assemblies, so a single build works across the range.
For a developer this means the adoption cost is close to zero if you have written Office automation before. There is no new API to learn, and existing snippets, Stack Overflow answers and internal helpers written against the PIAs keep working. The libraries exist to change what you deploy, not what you write.
COM proxies managed for you
The feature list credits reduced and more readable code with automatic management of COM proxies, and this is the second substantive difference from working against the Interop Assemblies directly.
Office automation in .NET means dealing with COM. A COM proxy is a runtime object that needs releasing, and the classic failure modes are a reference count that never reaches zero, which keeps a document or an Excel process alive, and the need to interleave marshal and unmarshal calls by hand. Code that does this correctly is verbose, and code that does it incorrectly leaks processes on the user's machine.
NetOffice takes that bookkeeping out of the caller's hands, which is what makes the reduced and more readable code claim possible. The object model calls stay the same shape as the PIA calls, and the lifetime handling happens underneath.
That matters most for automation rather than for add-ins. A long-running service that opens and closes workbooks is exactly where un-released proxies turn into a slow leak, and a script that exits anyway is where the difference is invisible. Anyone migrating from PIAs to NetOffice should expect to be able to delete release plumbing, and should also expect to find code where it was safe to keep a proxy alive across calls and now is not, which is a behaviour change worth testing rather than assuming.
Add-ins that install without registration and without VSTO
The deployment story is where the biggest practical difference lies. The README claims easy add-ins development, no deployment hurdles, no registration, and no dependencies, no interop assemblies and no need for VSTO.
VSTO is the Microsoft-supported way to build Office add-ins, and it is linked from the README for reference. The complaint in the feature list is not that VSTO is a bad idea, it is that it imposes requirements: a specific project system, deployment of extra assemblies, and per-machine configuration on the target machine.
NetOffice's answer is to keep the add-in as a plain .NET assembly that Office loads through the same COM add-in mechanism, with the add-in registration handled by the framework rather than by an installer step. That is why the repository has a RegAddin directory, and why the examples include an AddinProjectHelper and an AddinRemovalTool, which exist to register and unregister the add-in on the target machine.
The trade is that you are still doing COM add-in deployment, not a modern packaging format. An Office add-in that runs in-process on a user's desktop still has to be deployed to that desktop, and NetOffice removes the VSTO-specific hurdles rather than the entire problem. For a line-of-business tool distributed to a controlled set of machines, that is the difference between a deployment that works and one that needs a support call.
The NetOfficeFw package prefix and the 1.7.4 migration
The README puts a notice near the top of the page, and it is the first thing an upgrading user has to deal with. Use the official packages with the NetOfficeFw prefix on NuGet, and if you are using the old 1.7.4 packages, there is a migration notice linked from the page.
The package set is split per application, which is a sensible shape for a COM based framework. The repository carries separate packages for NetOfficeFw.Core, NetOfficeFw.Outlook, NetOfficeFw.Word, NetOfficeFw.Excel, NetOfficeFw.PowerPoint and NetOfficeFw.Access:
NetOfficeFw.Core
NetOfficeFw.Outlook
NetOfficeFw.Word
NetOfficeFw.Excel
NetOfficeFw.PowerPoint
NetOfficeFw.AccessDepending only on the packages for the applications you automate keeps the deployment footprint smaller, which matters for a tool that has to run on a locked-down desktop.
The migration is a namespace and package rename rather than a rewrite, and the linked notice exists because the old 1.7.4 packages came from a different distribution channel. If you are starting fresh there is nothing to migrate, and if you are moving an existing solution the cost is a change to the references and the using directives.
The runtime requirement is .NET Framework 4.6 or higher, which is the practical floor for where these libraries can run.
Branches, archived history and the build tooling
The branch layout in the README is unusually well documented, which tells you how much history the project carries.
There is a main branch for ongoing work, and release branches for the older 1.7 line, one each for netoffice_v1.7.7, netoffice_v1.7.6, netoffice_v1.7.5 and netoffice_v1.7.4. Then there is a separate group of archived branches that are archives of source code from CodePlex and OSDN, including import/osdn_repository for code imported from the OSDN repository, import/legacy_repository for the original source imported from CodePlex Subversion, and two import branches carrying early 1.7.4 alpha source code provided by Sebastian.
That is a project that has moved hosting twice and kept every version recoverable. For a library embedded in other people's products, being able to rebuild the exact version you shipped three years ago is worth a lot, and the fact that the archives are branches rather than tarballs means you can diff across the whole history.
The repository root also shows the working parts of the project: Source for the libraries, Tests with a workflow badge for the test suite, Examples with a solution containing per-application sample projects, BuildTools, Tutorials, Toolbox for the Visual Studio templates and wizards, Documentation, KeyFiles for signing, and a build.cmd batch script for the Windows build. There is a SECURITY.md, a CHANGELOG.md and an .editorconfig, plus a markdownlint configuration for the documentation.
Getting started, the Toolbox and where the examples live
The getting started instruction is one line: check out the NetOffice-Examples repository to see how to use NetOffice to automate Office applications or to create add-ins to extend them.
That separation is sensible. The main repository is the framework, and the examples are kept apart so that a consumer clones something small. The examples tree mirrors the application list, with directories for Access, Excel, Outlook, PowerPoint and Word, plus shared pieces such as ExampleBase, AddinProjectHelper and AddinRemovalTool, and an Examples.sln at the top. There is an Other directory for the cases that do not fit the per-application split.
The Tools section points at the NetOffice Toolbox, described as a comprehensive toolset to get started with NetOffice solutions, and the feature list adds Visual Studio Project Templates and Wizards available through it. For a framework whose stated goal is to remove the friction of building an Office add-in, shipping templates and a wizard is as much a part of the product as the libraries are.
The project history documentation is in Documentation/History.md, and the homepage netoffice.io carries the migration notice and the Toolbox downloads.
On releases, the recent tags are v1.9.9 on 2026-06-07, and v1.9.8 and v1.9.7 both on 2026-02-21. The repository is not archived and the last push was on 2026-10-17, so work continues on the branch even when the tag cadence is slow.
Editorial conclusion
Use NetOffice when your .NET application has to drive or extend Microsoft Office and you want the familiar Interop Assemblies API without the deployment overhead of VSTO, especially for add-ins that must install cleanly on a user machine. Do not choose it if you need to run Office on a server without Office installed, since the design is built on COM and on the Office object model itself, and treat the version range with care. Before you start, take the packages from the NetOfficeFw prefix rather than the old 1.7.4 packages, check that the target machine can run .NET Framework 4.6 or higher, and note that the latest release is v1.9.9 from 2026-06-07 with the last push on 2026-10-17.
Frequently asked questions
What is NetOffice and which Office applications does it cover?
NetOffice is a set of MIT licensed C# libraries for building Microsoft Office add-ins and automating Office applications, covering Excel, Word, Outlook, PowerPoint and Access, with separate NuGet packages per application plus NetOfficeFw.Core.
Is NetOffice the same API as the Microsoft Interop Assemblies?
Yes. The README states that NetOffice is syntactically and semantically identical to the Interop Assemblies, so existing PIA code can be reused, and it adds automatic management of COM proxies to produce reduced and more readable code.
Do I need VSTO or add-in registration to build an Office add-in with NetOffice?
No. The feature list states easy add-ins development, no deployment hurdles, no registration, and no dependencies, no interop assemblies and no need for VSTO. The repository does include a RegAddin directory and an AddinRemovalTool example for handling add-in registration on the target machine.
What runtime does NetOffice need?
The README states that NetOffice is usable with .NET Framework 4.6 or higher. The packages are published on NuGet under the NetOfficeFw prefix, and the old 1.7.4 packages are superseded, with a migration notice linked from the README.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/netofficefw-netoffice)Was this useful?