Fix usage of assembly (fix db context class discovery)

The current sync manager uses Assembly.GetEntryAssembly() to find the DbContext-Type used during a transfer of a change. This makes in impossible to define the DbContext in a different assembly than the Entry Assembly.

It should be possible to use a different Assembly. A way to avoid this issue is to all registered DbContext-Types in a storage class.

[morrisjdev]

Yes that is a good idea but after considering carefully I decided to not add the additional property.

The benefit is too small and it would make less sense when you’re rolling out an update because the server applications would not have to be synced on startup anyway.

[hwanders]

Thank you for the clarification, I’m just getting acquainted to the code base.

It’s fine if it’s just an internal API, I thought it was an API directly if indirectly accessible by the actual clients (because I wasn’t looking deep enough).

My thoughts regarding updates in a cluster:

For a smooth upgrade path you might try to leave the old property in the request class for a while and cope with only one of them being set or create a new class for the new request altogether (and handle both separately). The next version can then remove the old property.

Of course that requires the users to perform a clean migration via one intermediate version with the behavior described above.