Add analyzers that help prevent developer gotchas

[WhitWaldo]

Describe the feature

This is intended more as a parent issue to track progress for individual analyzers, but the goal is that we reduce some of the opportunities for developers to inadvertently misconfigure things that we might catch at build time and reduce runtime exceptions. Here's a short and evolving list of opportunities here:

Package	Name	Description	Pull Request	Fixes
Dapr.Actors	Actor cross-serialization errors	Ensure that when developers retain DataContract serialization or opt into JSON-based serialization, they're not inadvertently cross-serializing in a way that breaks the serializers and deserializers for either approach.	#1441
Dapr.Actors	Actor DI registration	Identify actors that are referenced but not registered in DI.	#1441
Dapr.Actors	Don't use UseHttpsRedirection with actors	Warn when using UseHttpsRedirection middleware as this breaks Dapr actor discovery
Dapr.Actors	Ensure MapActorsHandlers is in app startup	When AddActors is found, validate that MapActorsHandlers is in place	#1441
Dapr.Actors	Validate named callback method for a timer exists on the actor type.	When registering a timer in an actor, one specifies the name of the callback method to invoke. This analyzer confirms that this method name exists on the actor type.	#1513
Dapr.Jobs	Validate registered job callback URLs	Validate registered jobs have a corresponding registered invocation URL	#1477
Dapr.Workflows	Workflow/activity DI registration	Identify workflows and workflow activities that are referenced, but not registered in DI	#1440
Dapr.Workflows	Prevent DI injection errors	Ensure that during startup, those resources that require a app.UseX() have it specified in Program.cs
Dapr.Workflows	Validate inputs/outputs in workflows and activities	Validate that the input and output types to and from a workflow and workflow activity match on either side of the operation.		#1399
Dapr.Workflows	Check for common non-deterministic calls from workflows	Ensure developers are not using Guid.NewGuid or DateTime.UtcNow or variations within workflows themselves as these are not deterministic. For Guid.NewGuid, a fix could use context.NewGuid() instead and for DateTime.UtcNow it can favor context.CurrentUtcDateTime. For others, it could create an activity that performs the same and replaces the text to invoke that activity. Thanks to @marcduiker for the idea
Dapr.Client (current) / Dapr.PubSub (future)	Ensure MapSubscribeHandler is in app startup when programmatic subscriptions are used	When programmatic subscriptions are used (e.g. WithTopic or a Topic attribute), validate that MapSubscribeHandler is in place** - thanks to @ngruson for the idea	#1448
Dapr.Workflows	Do not use Parallel.ForEachAsync within a Workflow as it's non-deterministic and thus not supported	Validated while evaluating https://github.com/dapr/dotnet-sdk/issues/1577

There are a great many analyzers and code fix providers in the Azure Functions Durable Extension repository that could be adapted for use in Dapr Workflows as well.

Release Note

RELEASE NOTE: ADD Analyzers to help prevent runtime errors

[jev-e]

I'd be interested in looking at this; although partially motivated by self improvement as my knowledge of Roslyn analysers isn't super strong, but an area I'd like to improve.

[siri-varma]

Planning to add an analyzer to make sure MapDaprScheduledJobHandler is in place to receive invocations for the jobs api. Let me know what you folks think ?

[WhitWaldo]

Planning to add an analyzer to make sure MapDaprScheduledJobHandler is in place to receive invocations for the jobs api. Let me know what you folks think ?

I didn't realize analyzers can look up installed packages. If that's the case, sounds like a great idea.

Could take it a step farther, though a future release might render it obsolete. Because only the app that schedules a job can receive job invocations, you could do a scan for all the job names that are registered in the app and validate there's a corresponding mapped handler for each.

[marcduiker]

Can we add an analyzer that checks the input and output argument types when calling activities from the workflow? And if the activity class name matches? See the DurableTaskAnalyzers.

[WhitWaldo]

Can we add an analyzer that checks the input and output argument types when calling activities from the workflow? And if the activity class name matches? See the DurableTaskAnalyzers.

I added the former to the list. Can you get into more detail on the latter ask and how it differs from "Identify workflows and workflow activities that are referenced, but not registered in DI" which is already in the table?

I'll go through the linked analyzers and get them added as well. Good find!

[marcduiker]

Can we add an analyzer that checks the input and output argument types when calling activities from the workflow? And if the activity class name matches? See the DurableTaskAnalyzers.

I added the former to the list. Can you get into more detail on the latter ask and how it differs from "Identify workflows and workflow activities that are referenced, but not registered in DI" which is already in the table?

I'll go through the linked analyzers and get them added as well. Good find!

Yes, the other use case matches what you describe here 👍 .