I know it will fail on runtime, that’s my point - this is not a help/bug report after all, but feedback on workflow analyzer rules gap.
Just for context - this topic was sparked by a different topic in Help (link), where the user was switching from static invokes to dynamic dispatch based on variables (which will make the future maintainers suffer).
Static analysis should “protect” the developer from statically detectable defects in the produced code. The level of that defect can differ, and it can be argued what level should which issue be, but that’s a separate discussion.
Invoking a compile-time-evaluatable path that points to nowhere (case #1) falls straight into a “how did this pass the checks?” territory (it’s an equivalent of referencing a method/class that doesn’t exist, just with xaml’s). It’s as close to a compile-time error as you can get with xaml’s aside of straight up “does not parse” errors. There’s no edge cases, or nuance - this will fail at runtime, 100% of the time.
Invoking a workflow with the path passed as a variable (#2) is closest to a potential null dereference - it’s perfect for a warning. It’s not a per se error, but can easily lead to one in the future.
Invoking a workflow from an arbitrary absolute path (#3) is closest to loading assemblies from untrusted locations. There’s a reason why there’s layers on layers of security and checks in what can get loaded from where into the appdomain in traditional software. Performing a load like that with xaml’s (which are effectively just code) is an invitation for a code injection attack (and very brittle).
I do of course agree that static analysis is not end-all-be-all, and runtime tests are needed, that’s not even a question. But, at the same time, if something can be a compile-time error because it’s 100% guaranteed to fail when run (case #1), it should not be a runtime error. The other ones are just good warnings to have.
And I’m not even advocating for the #1 case to be a compile-time error (although IMHO it could be), just an analyzer error.
Let’s put it in perspective:
The analyzer gives warnings for things like 2 activities having the same name (because it could potentially make debugging more difficult) even if those activities physically cannot fail (static value log messages, for example).
It gives an error if a workflow has too many arguments. There’s nothing inherently unsafe about it, it’s just not really too good maintenance.
The examples could be numerous - a lot of what the analyzer does falls under design style, security and maintainability (the other ones being enforcing organizational rules). Proposed rules, in my opinion, fit well into that style.
(although the more I think about it, that #1 case should be a compile-time error, because it will never ever work)