OutlookGoogleCalendarSync: a Windows bridge between two calendars

Two-way copying of events, attendees and reminders between Outlook and Google

Outlook and Google keep separate copies of the same person's week, and neither one talks to the other. OutlookGoogleCalendarSync is the C# desktop application that copies items across that gap, and its topic tags list two-way next to sync, synchronize and synchronise. The README states exactly what crosses: calendar synchronisation between Outlook and Google, including attendees and reminders. Attendees are the part casual users underestimate, since an event copied without its invitee list leaves a trace that colleagues notice when no invitation ever arrives. Reminders travel in the same pass, so an edit made in one client can change what pops up in the other.

The page also claims two deployment properties in a single line: no install necessary, and works behind web proxies. The proxy claim is the load-bearing one on a corporate network, where an authorization exchange with a Google endpoint can be blocked outright. How a proxy is configured never appears in this README.

A free tool running on your own machine is a reasonable default for a personal calendar. A shared team calendar under two administrators is a different question entirely.

Every Outlook client from 2003 to 2024, but New Outlook waits for v3

The support line is the widest claim on the page: all versions of Outlook, from Outlook Online through Classic clients 2003 and on to 2024 64-bit, including Microsoft 365 builds from the General Availability update channel. Read alone, that reads as total coverage. The line under it narrows the promise without much noise. For New Outlook, v3. On the v2 line, a user on the rewritten Outlook client sits outside the range the sentence above claims. Nothing on the page says what such a user gets instead: no error, no fallback, no feature table separating the branches.

That gap grows as Microsoft moves people onto the new client, because the two lines are not interchangeable. The v2 downloads and the v3 downloads sit under separate headings with nothing set beside them to compare. Both blocks carry the same project topics, and windows and portable describe either build equally well.

Anyone reading the support line as a compatibility matrix will be wrong in exactly one place, and that place is the client Microsoft is pushing.

Three ways to get it: installer, portable ZIP, or an in-place package

Every download here is a Windows artefact, and the v3 line offers three shapes of the same application under the v3.0.4-alpha tag:

https://github.com/phw198/OutlookGoogleCalendarSync/releases/download/v3.0.4-alpha/OGCS_Setup.exe
https://github.com/phw198/OutlookGoogleCalendarSync/releases/download/v3.0.4-alpha/Portable_OGCS_v3.0.4.zip

The first is an installer. The second is the portable archive that makes the no install necessary tagline literally true, since it is one ZIP you unpack and run. Four files carry that tag in total:

OGCS_Setup.exe
Portable_OGCS_v3.0.4.zip
OutlookGoogleCalendarSync-3.0.4-alpha-full.nupkg
OutlookGoogleCalendarSync-3.0.4-alpha-delta.nupkg

The last two are not for a first install. An existing copy fetches them when it checks for a newer build, which is why the page shows a full and a delta variant side by side rather than one package. Expect that upgrade path to run inside a Windows application, not from a shell you drive yourself. The page itself gives no steps for either download, and sends installers and configuration questions to the wiki instead.

The v2 line advertises 2.12.0-beta while its own alpha sits at 2.12.2

Under the v2 heading, the badge labelled latest beta points at a general latest page, while the counters printed under it are pinned to v2.12.0-beta. A few lines further down, the v2 alpha block sits at v2.12.2-alpha. So the newest stable v2 download advertised there is two patch numbers behind its own alpha, and nothing marks which one a new user should take. The v3 block repeats the trick by pinning its counters to v3.0.4-alpha, which freezes each set of numbers to the build it names.

Across both lines the newest alpha tag is v3.0.4-alpha from 2026-09-06, preceded by v3.0.3-alpha on 2026-07-12 and v2.12.2-alpha on 2026-06-15. Two of those three belong to v2, so the branches move at different speeds. The last push to master landed on 2026-09-27, and the repository is not archived. That fits the README's claim of active development, without telling you which branch receives the work.

Delta packages come from a batch script and a checked-in nuget.exe

Two files at the top of the repository explain those package names: `nuget-build.bat`, a Windows batch script, and `nuget.exe` itself, committed beside it. A pipeline carrying its own packaging executable reproduces easily on a Windows box and awkwardly anywhere else. The README does not describe the build at all, so the batch file is the only account of how a full package and a delta package get produced.

This is the fork for anyone deciding how to stay current. Take updates through the in-application delta path and an installed copy stays current with less traffic, which suits a machine committed to one line. Download a fresh ZIP instead and you control exactly which build runs, at the cost of manual re-downloads. Nothing on the page describes moving backwards from either route, or previewing what a delta package changes before it is applied.

Every setting lives in the wiki, not in this README

This README has no configuration section at all. It points to a wiki page for install and configuration guides, it steers new users to a user site hosted on GitHub Pages at `https://phw198.github.io/OutlookGoogleCalendarSync/`, and the project also keeps a homepage of its own at `https://www.outlookgooglecalendarsync.com/`. Three separate destinations, and not one of them is this page. No configuration key appears anywhere after the download links.

The silence is what to weigh before installing. Nothing here names a calendar mapping, a sync direction, a reminder offset, a scheduling window or a conflict rule. The topic tags include oauth2, so authorization is involved, though the grant type and the endpoints are not written down anywhere. For software that reads and writes two live calendars, undocumented defaults for the hard cases are a real evaluation cost, and a reader has to go hunting in the wiki before trusting this with a working week.

Agent rule files sit beside the source in the repository root

A listing of the top level shows more than a C# project normally carries. Next to `src/`, `docs/`, `.github/` and the usual readme and ignore files, there are three entries that belong to an automated coding setup: a `.ai/` directory, a `.clinerules` file and `AGENTS.md`.

.ai/
.clinerules
.github/
.gitignore
AGENTS.md
README.md
docs/
license.md
nuget-build.bat
nuget.exe
src/

None of those three appears in the README text. The terms are equally plain, since MPL-2.0 ships as `license.md` at the root and the README adds nothing to them. What the listing shows is a project carrying its own instructions for coding agents next to the build script and the source. Whether those files govern changes to the sync logic is not something the front page lets you determine.

Where a two-calendar bridge is the wrong tool

Windows is the ceiling, and the evidence sits in the file names rather than in a stated requirement. The installer is `OGCS_Setup.exe`, the archive is a portable ZIP, the build script is a batch file, and windows and portable are two of the topic tags. A macOS or Linux user finds no documented build, no package and no documented workaround.

Then there is the standard hazard of any two-way copy, and this page is quiet about all four of its decisions. No rule is given for a conflict when an event changes on both sides between two runs. No dry run or preview is offered. No rollback is documented. Nothing says whether a deletion on one side propagates or brings the item back on the other. An evaluator who needs those answers has to look elsewhere, and a calendar that also feeds a phone through ActiveSync adds a writer this page never mentions.

Editorial conclusion

Adopt it if your week lives in both Outlook and Google on a Windows machine, and accept the v3 line as the only one that follows New Outlook. Leave it alone if you need a documented conflict rule, a dry run or rollback before the first run, because none appears on the project page. A machine pinned to one build line is the easier case, since the updater fetches full and delta packages on its own. Before trusting it, sync a throwaway calendar through the portable ZIP and confirm attendees and reminders survive in both directions.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. phw198/OutlookGoogleCalendarSync on GitHub
3. Project website
4. README
5. Releases