# iCal.NET: reading and writing iCalendar data in .NET

> iCal.NET is an RFC 5545 iCalendar library for.NET, published on NuGet and reworked in v5 and v6: v5 for correctness and memory use, and a v6 pre-release that replaces the date and time model, the recurrence engine and the alarm evaluator. Version 4 is out of support, and the v6 preview ships with breaking changes.

**ical-org/ical.net** — iCal.NET - iCalendar library for .Net

- Repository: https://github.com/ical-org/ical.net
- Stars: 983 · Forks: 255
- Language: C#
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ical-org-ical-net

## The problem it solves, and for whom

iCal.NET is a library for working with iCalendar data in .NET, and the standard it targets is RFC 5545. The work it saves is the part that is tedious rather than impossible: reading an .ics file into objects, writing objects back out, expanding recurrence rules into occurrences, and getting time zones and alarms right. A team building a scheduling service, a calendar synchronisation tool or a booking system in C# usually ends up writing a parser, and every parser has the same pile of edge cases around time zones, daylight saving transitions and recurrence exceptions. The library gives you an object model for those instead. The features listed are the ones you would otherwise write yourself: event management, recurrence rules, serialisation and deserialisation of .ics files, time zone handling, and attachments on events including invites. The package is on NuGet as Ical.Net and targets .NET 10, .NET 8, .NET Standard and .NET Framework, so it fits both modern services and older enterprise hosts.

## One command to install, one flag for the preview

The package is a normal NuGet dependency, installed with the dotnet CLI:

```sh
dotnet add package iCal.NET
```

The current line is v6, published as a pre-release, and to pull that instead you have to say so explicitly:

```sh
dotnet add package iCal.NET --prerelease
```

That flag is the whole decision, and it is the one decision worth thinking about before you start. The stable packages are v5.2.3 from 2026-06-23 and v5.2.2 from 2026-05-08, while the newest tag is v6.0.0-pre.1 from 2026-10-14, so a plain install gives you the v5 line and a flagged install gives you the rewrite. The project describes v6 as its best version even as a pre-release, built on more than a hundred commits since v5.2.0, and asks people to try it and give feedback. The safest route for production is to take the pre-release in a branch, read the breaking changes, and keep the v5 line as your fallback.

## v6 replaces the date and time model

The v6 changes are structural rather than cosmetic. The headline is a simplified, unambiguous CalDateTime type, which matters because ambiguous local times are the classic source of scheduling bugs. Recurrence and occurrence evaluation moves to a brand new engine built on NodaTime. Time zones become a per-Calendar provider, which means two calendars in the same process can sit in different zones, a thing that a single global setting cannot express. The alarm evaluator is rewritten to be RFC 5545 compliant, and the serializer is faster. The v5 line itself was already a rewrite, incorporating more than a hundred merged pull requests, with reported issues resolved and unit tests added or improved, and it cut memory usage to about half of v4. The v6 work builds on that. Breaking changes are expected, and the release notes file is where they are listed, alongside the API changes document and the migration guide in the wiki for the v4 to v5 step.

## Recurrence is the part that decides whether the library works for you

If a library is going to fail your project, it will be in recurrence handling rather than in the simple create and read paths. A single event with no rule is trivial. A rule that repeats on the last Friday of each month, with exceptions, in a zone whose offset changes twice a year, is where a calendar library earns its place. iCal.NET supports complex recurrence rules, and in v6 the evaluation of those rules is the new NodaTime based engine rather than an incremental change to the old one, which is the main reason the maintainers call v6 the most correct version to date. The wiki carries a page on working with recurring elements and another on a simple event with a recurrence, and there is a page on concurrency scenarios and PLINQ for the case where you expand occurrences in parallel. Two cautions belong with any recurrence library: expansion is unbounded by design, so a rule that matches every minute of a decade is a resource problem rather than a bug, and the v6 engine is new enough that the edge cases are still being reported.

## Time zones, alarms and attachments

Three areas deserve a note because they are where a calendar product is judged. Time zone support is listed as a core feature, and in v6 it becomes a flexible provider configured per Calendar rather than a global setting, so the library can serve a user in one zone and a server in another without converting everything to a single reference. Alarms are handled by a fully overhauled evaluator that aims for RFC 5545 compliance, and compliance here means the alarm triggers when the specification says it should, including the relative offsets and the relationship between an event start and the alarm, which is exactly the kind of detail hand written implementations get wrong. Attachments are supported on calendar events, including invites, so a meeting invitation can carry the file it refers to rather than pointing at a URL that may be dead by the time the recipient opens it. All three are the sort of thing that looks like a checkbox on a feature list and turns into a week of work when you have to build it yourself.

## Strong naming, tests and benchmarks live in the repository

The tree tells you how the project is run. There is a solution file, the library project itself, a test project and a separate benchmarks project, which is the combination you want from a library that makes performance claims. An IcalNetStrongnameKey.snk file sits at the root, so the assemblies are strong named for the .NET Framework era of consumers that need it. There is a codecov configuration and an .editorconfig, and the release notes for each line are kept as separate files, release-notes.md for v6, release-notes-v5.md and release-notes-v4.md, which makes it possible to read the history of a version you are already running without digging through tags. Two other files are quietly useful. lic-history.md records the licence history of the project, and contributors.md is a list of the people who worked on it. The project uses semantic versioning, so a major version bump means a breaking change, which is the signal you want when a dependency upgrade lands in a build.

## v4 is out of support and the work happens in spare time

The version policy is explicit. v4 is still available up to v4.3.1, it is out of support and will not receive further updates, and the recommendation is to use the v6 pre-release or the v5 packages instead. There is no ambiguity there, and anyone still on v4 has a migration to plan. The support model is also stated plainly: contributors are asked to give back, especially if the library is used in a commercial product, questions in the discussions area are open to the community, and keeping the project running is something the maintainers and contributors do in their spare time. The credits name Rian Stockbower, who took the project over in 2016, and JetBrains, which supports the project with free licences for its tools. The licence is MIT, in the license.md file in the repository, and the last push was on 2026-10-19, so the work is current even while the v6 pre-release is still settling.

## Conclusion

iCal.NET is the right choice for a .NET service that has to read, write or schedule iCalendar data, especially if you are starting fresh and can build on v5 or on the v6 pre-release with its NodaTime based engine. It is the wrong choice if you are on v4 and hoping for fixes, since that branch is out of support, or if you cannot absorb breaking API changes in a pre-release. Before you start, read release-notes.md and the v4 to v5 migration guide, decide whether the v6 preview is worth the upgrade work, and check that your target framework is one of the supported ones, since the library spans .NET 10, .NET 8, .NET Standard and .NET Framework.

## FAQ

### How do I install iCal.NET?

Run dotnet add package iCal.NET to get the stable v5 line. To take the v6 pre-release instead, add the --prerelease flag: dotnet add package iCal.NET --prerelease. The package is published on NuGet as Ical.Net.

### What changed in iCal.NET v6?

v6 introduces a simplified, unambiguous CalDateTime type, a new NodaTime based recurrence and occurrence evaluation engine, a flexible per-Calendar time zone provider, a rewritten RFC 5545 compliant alarm evaluator and a faster serializer. It is built on more than a hundred commits since v5.2.0 and includes breaking changes listed in the release notes.

### Is iCal.NET version 4 still supported?

No. v4 is available up to v4.3.1 but is out of support and receives no further updates. The project recommends the v6 pre-release or the v5 packages instead.

### Which .NET versions does iCal.NET target?

It works with .NET 10, .NET 8, .NET Standard and .NET Framework, and the repository also contains a strong naming key for consumers that need signed assemblies.

## Sources

- [ical-org/ical.net on GitHub](https://github.com/ical-org/ical.net)
- [Issues](https://github.com/ical-org/ical.net/issues)
- [README](https://github.com/ical-org/ical.net/blob/main/README.md)
- [Releases](https://github.com/ical-org/ical.net/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ical-org-ical-net