Regarding versioning, have you had to integrate this with IFeatureManagement, i.e. feature flagging? What would be a recommended approach? (something in the consumer definition?)
Using feature flags/toggles/switches with messaging is similar to using them with databases. You have to ensure 100% backwards compatibility for the on/off states. I'll see if I can discuss this in either a subsequent video or a separate bus stop on feature toggles on their implications.
How do you deal with enum values that change (or additions) within contracts?
Good question, I'll cover that in the next video on versioning message contracts!
Regarding versioning, have you had to integrate this with IFeatureManagement, i.e. feature flagging? What would be a recommended approach? (something in the consumer definition?)
Using feature flags/toggles/switches with messaging is similar to using them with databases. You have to ensure 100% backwards compatibility for the on/off states. I'll see if I can discuss this in either a subsequent video or a separate bus stop on feature toggles on their implications.
We are currently using a git submodule instead. Works just as well for us.
tip: make sure you dont use struct as well as primary constructors
Correct, messages _must_ be reference types (records, classes, or even interfaces).
@@PhatBoyGisn't the preference an interface?
@@logantcooper6 not since records were introduced, at this point, records are my favorite for message contracts.