starred/outlookcaldavsynchronizer

Fork 0

mirror of https://github.com/aluxnimm/outlookcaldavsynchronizer.git synced 2026-04-26 03:25:48 +03:00

[GH-ISSUE #279] Linux Support via WINE/Crossover (Outlook 2016 Works) #1174

New issue

Closed

opened 2026-03-14 00:32:33 +03:00 by kerem · 5 comments

kerem commented

2026-03-14 00:32:33 +03:00

Owner

Originally created by @JGKle on GitHub (May 28, 2020).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/279

A few years back, issue #134 asked about compatibility with Linux, & the response said that since there's no Outlook for Linux, this would be impossible.

Currently, Outlook 2016 works quite well via WINE, and can be installed essentially just as easily as in Windows thanks to Crossover. They have a "recipe" that creates a bottle & sets up all required prerequisites.

Outlook 2016 running on Crossover also definitely supports COM add-ins, as the few that are included by default (i.e. "Social Connector") work just fine. However, CalDAV Synchronizer won't start up (checking in Options->Add-Ins shows "Not loaded. A runtime error occurred during the loading of the COM add-in." The required Visual Studio Tools for Office Runtime has been installed.

So, I just wanted to resurrect this request, as I've been happily using Outlook on Linux for some time, & it would be great to be able to use CalDAV on there as well :)

Originally created by @JGKle on GitHub (May 28, 2020). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/279 A few years back, issue #134 asked about compatibility with Linux, & the response said that since there's no Outlook for Linux, this would be impossible. Currently, Outlook 2016 works quite well via WINE, and can be installed essentially just as easily as in Windows thanks to Crossover. They have a "recipe" that creates a bottle & sets up all required prerequisites. Outlook 2016 running on Crossover also definitely supports COM add-ins, as the few that are included by default (i.e. "Social Connector") work just fine. However, CalDAV Synchronizer won't start up (checking in Options->Add-Ins shows "Not loaded. A runtime error occurred during the loading of the COM add-in." The required Visual Studio Tools for Office Runtime has been installed. So, I just wanted to resurrect this request, as I've been happily using Outlook on Linux for some time, & it would be great to be able to use CalDAV on there as well :)

kerem closed this issue

2026-03-14 00:32:38 +03:00

kerem commented

2026-03-14 00:32:45 +03:00

Author

Owner

@JGKle commented on GitHub (Jun 6, 2020):

Solved it.

To debug why a VSTO addon is failing to start, you can set environment variable VSTO_SUPPRESSDISPLAYALERTS=0 (per https://stackoverflow.com/questions/4668777/how-to-troubleshoot-a-vsto-addin-that-does-not-load).

That reveals the specific error that was occurring when it was failing to start the addon. The error was "System.IO.FileLoadException: The specified user does not have a valid profile."

Googling that string turned up several other WINE apps exhibiting the same issue. Adding a "magic" registry key fixes it: HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-0-0-0-1000 (per https://bozaro.ru/2016/04/19/wix-wine-wixsharp-en/).

After adding that key, the addon starts perfectly. I haven't tested extensively, but a cursory test shows the UI fully working, & successfully synced contacts with a CardDAV server :)

@JGKle commented on GitHub (Jun 6, 2020): Solved it. To debug why a VSTO addon is failing to start, you can set environment variable VSTO_SUPPRESSDISPLAYALERTS=0 (per https://stackoverflow.com/questions/4668777/how-to-troubleshoot-a-vsto-addin-that-does-not-load). That reveals the specific error that was occurring when it was failing to start the addon. The error was "System.IO.FileLoadException: The specified user does not have a valid profile." Googling that string turned up several other WINE apps exhibiting the same issue. Adding a "magic" registry key fixes it: HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList\\S-1-5-21-0-0-0-1000 (per https://bozaro.ru/2016/04/19/wix-wine-wixsharp-en/). After adding that key, the addon starts perfectly. I haven't tested extensively, but a cursory test shows the UI fully working, & successfully synced contacts with a CardDAV server :)

kerem commented

2026-03-14 00:32:50 +03:00

Author

Owner

@aluxnimm commented on GitHub (Jun 6, 2020):

Amazing. Thanks for solving this!

@aluxnimm commented on GitHub (Jun 6, 2020): Amazing. Thanks for solving this!

kerem commented

2026-03-14 00:32:55 +03:00

Author

Owner

@JGKle commented on GitHub (Jun 6, 2020):

...Actually, although it's running for the most part, syncing seems to be erratic:

I set it up to sync a folder of 601 contacts (i.e. a new Outlook instance on Linux, from an existing folder on my Radicale server). No other clients were running, so the only thing talking to the server was this single Outlook instance.

The first sync showed a server delta of "Added: 510," and it brought in those items successfully (note: it saw 510, not 601 as was actually on the server).
The next sync immediately after showed a server delta of 96 items deleted, and it deleted them from the local Outlook instance, leaving 413 items.
The next few syncs showed no changes, until a few minutes later when a sync raised an error: System.Runtime.InteropServices.COMException (0x8001010E): Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD). The full exception is listed below.
Subsequent syncs always show the RPC_E_WRONG_THREAD, but always for the same 2 specific items
Trying to add a new item now shows the same error

At this point I fired up Outlook on another PC, and it saw 188 items deleted, bringing that PC's contacts down to 413. In other words, Linux seems to be doing erroneous partial-syncs, and deleting items from the server. If you could provide any pointers on how I might debug this, I'd greatly appreciate it - after quite a few hours to get to this point, seems like I might be close to getting it working :)

System.Runtime.InteropServices.COMException (0x8001010E): Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD)
   at Microsoft.Office.Interop.Outlook._ContactItem.get_LastModificationTime()
   at CalDavSynchronizer.Implementation.Contacts.ContactEntityMapper.Map1To2(IContactItemWrapper source, vCard target, IEntitySynchronizationLogger logger, ICardDavRepositoryLogger context)
   at GenSync.Synchronization.States.UpdateAToB`7.<UpdateEntity>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at GenSync.Synchronization.States.UpdateAToB`7.JobWrapper.<UpdateEntity>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.Implementation.Contacts.CardDavEntityRepository`3.<TryUpdate>d__12.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CalDavSynchronizer.Implementation.Contacts.LoggingCardDavRepositoryDecorator.<TryUpdate>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.<PerformOperations>d__3.MoveNext()

@JGKle commented on GitHub (Jun 6, 2020): ...Actually, although it's running for the most part, syncing seems to be erratic: I set it up to sync a folder of 601 contacts (i.e. a new Outlook instance on Linux, from an existing folder on my Radicale server). No other clients were running, so the only thing talking to the server was this single Outlook instance. * The first sync showed a server delta of "Added: 510," and it brought in those items successfully (note: it saw 510, not 601 as was actually on the server). * The next sync immediately after showed a server delta of 96 items *deleted*, and it deleted them from the local Outlook instance, leaving 413 items. * The next few syncs showed no changes, until a few minutes later when a sync raised an error: System.Runtime.InteropServices.COMException (0x8001010E): Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD). _The full exception is listed below._ * Subsequent syncs always show the RPC_E_WRONG_THREAD, but always for the same 2 specific items * Trying to add a new item now shows the same error At this point I fired up Outlook on another PC, and it saw 188 items deleted, bringing that PC's contacts down to 413. In other words, Linux seems to be doing erroneous partial-syncs, and deleting items from the server. If you could provide any pointers on how I might debug this, I'd greatly appreciate it - after quite a few hours to get to this point, seems like I might be *close* to getting it working :) ``` System.Runtime.InteropServices.COMException (0x8001010E): Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD) at Microsoft.Office.Interop.Outlook._ContactItem.get_LastModificationTime() at CalDavSynchronizer.Implementation.Contacts.ContactEntityMapper.Map1To2(IContactItemWrapper source, vCard target, IEntitySynchronizationLogger logger, ICardDavRepositoryLogger context) at GenSync.Synchronization.States.UpdateAToB`7.<UpdateEntity>d__6.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at GenSync.Synchronization.States.UpdateAToB`7.JobWrapper.<UpdateEntity>d__13.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.Implementation.Contacts.CardDavEntityRepository`3.<TryUpdate>d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at CalDavSynchronizer.Implementation.Contacts.LoggingCardDavRepositoryDecorator.<TryUpdate>d__3.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at GenSync.EntityRepositories.BatchEntityRepositoryAdapter`4.<PerformOperations>d__3.MoveNext()

kerem commented

2026-03-14 00:33:00 +03:00

Author

Owner

@JGKle commented on GitHub (Jun 12, 2020):

If you could just give a little guidance, I'm very willing to put in the work to try & debug this. As the author who's intimately familiar with the code & its behavior, I'd assume you'd have a better idea of a starting point given the above.

Much appreciated.

More info:

I tried changing the following connection-related settings to see if they made any difference (they didn't):
*Use fast queries
*Close connection after each request
*Perform synchronization in chunks
*Synchronize items immediately after change
*Use preemptive authentication

Also, an observation: it looks like incoming syncs work. It's only outgoing that raises the exception. i.e. if I set up the profile as Server->Outlook replication mode, it always works fine - but as soon as I change it to any of the others, and edit a local item, the exception starts happening (and continues always for the single item I edited locally, that it's trying to push to the server).

@JGKle commented on GitHub (Jun 12, 2020): If you could just give a little guidance, I'm very willing to put in the work to try & debug this. As the author who's intimately familiar with the code & its behavior, I'd assume you'd have a better idea of a starting point given the above. Much appreciated. More info: I tried changing the following connection-related settings to see if they made any difference (they didn't): *Use fast queries *Close connection after each request *Perform synchronization in chunks *Synchronize items immediately after change *Use preemptive authentication Also, an observation: it looks like *incoming* syncs work. It's only *outgoing* that raises the exception. i.e. if I set up the profile as Server->Outlook replication mode, it always works fine - but as soon as I change it to any of the others, and edit a local item, the exception starts happening (and continues always for the single item I edited locally, that it's trying to push to the server).

kerem commented

2026-03-14 00:33:06 +03:00

Author

Owner

@JGKle commented on GitHub (Jun 14, 2020):

I realized I sort of hijacked my own thread, & this has gone a bit beyond the general "how to install in Linux," which is now solved. Also, it seems like devs are far less active here than on Sourceforge. Thus I posted a more clear & specific issue on Sourceforge, & will go ahead & close this one.

https://sourceforge.net/p/outlookcaldavsynchronizer/tickets/1403/

@JGKle commented on GitHub (Jun 14, 2020): I realized I sort of hijacked my own thread, & this has gone a bit beyond the general "how to install in Linux," which is now solved. Also, it seems like devs are far less active here than on Sourceforge. Thus I posted a more clear & specific issue on Sourceforge, & will go ahead & close this one. https://sourceforge.net/p/outlookcaldavsynchronizer/tickets/1403/