Generate trigger when using transactions

[SeanFeldman]

Add support for cross-entity transactions configuration via a new NServiceBusTriggerFunctionAttribute attribute.

TODO:

• obsolete NServiceBusEndpointNameAttribute with warning.

[timbussmann]

is CrossEntityTransactions a bit too specific in this context? What would be the difference to just calling it EnableTransactions for example? Or maybe something more connected to our transport transactions like SendsAtomicWithReceive?

[SeanFeldman]

Perhaps the name is very specific but given the context of Azure Functions with Service Bus, being explicit is closer to what customers will do. I wouldn't even mind calling it AutoComplete because it is a trigger function. However, I would not want to call it anything like the transport transaction mode as that term is really specific to NServiceBus. Not to mention that EnableTransactions would mislead users to believe they are fully transactional.

[timbussmann]

Not to mention that EnableTransactions would mislead users to believe they are fully transactional.

agreed

However, I would not want to call it anything like the transport transaction mode as that term is really specific to NServiceBus

that might be good though, assuming they are familiar with NSB, it would be fairly clear to them what this means.

I wouldn't even mind calling it AutoComplete

I think I wouldn't do that given AutoComplete isn't directly tied to transactions, just something that is a "side effect" of using transactions.

[timbussmann]

the parameter and the property itself allowed the same config setting to be configured in two ways, e.g. [Attribute("mandatory", "optional ctor param")] or [Attribute("mandatory", SomeProperty = "property value")]. The second is support for attributes ootb. Given the second one is a bit more expressive, I've went with only supporting properties to remove confusion and ambiguity.

[SeanFeldman]

This is why I'm in favour of using a single method all the time and pass messageReceiver no matter what.

1. Less logic here
2. Less cognitive load for customers that choose to override the trigger - no need to distinguish between modes and always a single method/same parameters to pass in.

[timbussmann]

happy to discuss that further, I don't have strong opinions on this.

Less cognitive load for customers that choose to override the trigger

that might be dangerous for customers that write their own trigger as long as we don't have better support to detect whether AutoComplete has been properly configured.

[SeanFeldman]

Using a canonical signature to pass in MessageReceiver, how is that dangerous?

[SeanFeldman]

I'll go ahead and merge but suggest looking into the comment as I feel we're inflicting unnecessary work on the segment of users that want to override the trigger.