Question

Should I reference the Outlook Interop Recurrence Pattern object from my core object code or should I duplicate its “interface” (and I use that term loosely) within my core and then communicate with Outlook in another layer?

I’m a small developer in a small company with a small software product. For years, customers have clamored for Outlook interoperability in our C#/SQLServer RDBMS. We’re finally making it happen for them, but an Outlook Add-in is out of scope.

Thanks to stackoverflow and google (and of course the MS documentation), I’ve got our program successfully saving appointments, cancelling meetings, sending invites… Now we need to decide how to handle recurrences.

I was looking at Outlook’s “Appointment Recurrence” window (and comparing it with Google Calendar’s “Repeat” window) when I started to feel myself getting sucked in… As I hinted above, we usually avoid “Yak Shaving,” but we’ll re-invent the wheel if that’s what it takes to keep control of our products.

I understand that other people have already solved this problem, but our management will probably never let us go that route.

Answer 1

It looks like in order to implement Outlook’s functionality, you would need DayOfMonth, DayOfWeekMask, Duration, EndTime, Instance, Interval, MonthOfYear, PatternStartDate, RecurrenceType, StartTime, and some way to specify when it ends.

Although Outlook uses some combination of Occurrences, NoEndDate, and PatternEndDate to specify the end, you could use a nullable PatternEndDate or a nullable Occurrences to satisfy the functionality.

I believe the actual Outlook object has specific validation rules built in that may require properties to be set in a specific order. I would implement my own object that only performs validation at the right time and then sets the Outlook object’s properties in the proper order.