Filesystem usage analyzer

[RRode]

Resolves #3643

Implements analyzer that searches for file system usage and suggests IFileSystem usage. Currently checks for usages of File, FileInfo, Directory and DirectoryInfo. No warning is produced, if these are used within IFileSystem implementation.

Analyzer was added to Sentry project and finds usage of file system outside of IFileSystem implementations, which then breaks the build. Usages found in PortablePdbReader.cs, CFunctions.cs and FileDiagnosticLogger.cs.

@bitsandfoxes Is this roughly what you had in mind?

[bruno-garcia]

This is really awesome and promising. Thank you!

Is there a way to ignore some places where we it would be safe to call from, for example the CFunction one perhaps will be

[RRode]

Is there a reason why you could not use #pragma warning disable / enable? IMO, with additional comment, this would make it explicit and well documented why the warning should be ignored. But, if you want, I could add some exceptions to the rule. Just let me know what you need.
Also is it OK that I placed the new projects under src and test? For me the analyzer project feels a bit odd there, since it's not a deliverable. I thought about putting both projects under modules, but that seemed a bit off too, since those are git submodules that get pulled in.
Other thing is, would it make sense to put the analyzer into Directory.Build.props in src, so it is added in all src files? I assume that you want to enforce the warning in those projects as well.

[bruno-garcia]

Is there a reason why you could not use #pragma warning disable / enable? IMO, with additional comment, this would make it explicit and well documented why the warning should be ignored. But, if you want, I could add some exceptions to the rule. Just let me know what you need.

That makes sense, #pragma sounds like the right solution

Also is it OK that I placed the new projects under src and test? For me the analyzer project feels a bit odd there, since it's not a deliverable. I thought about putting both projects under modules, but that seemed a bit off too, since those are git submodules that get pulled in.

I also think it's kind of odd, but it's not a big deal. Alternatively it could be a new top level directory: analyzers or build-src I dunno. I think as you did it's fine. But worth adding a README.md on the project directory to clarify this analyizer is only for consumption from Sentry itself, for development of the SDK.

Other thing is, would it make sense to put the analyzer into Directory.Build.props in src, so it is added in all src files? I assume that you want to enforce the warning in those projects as well.

We only really need this on Sentry since this is a requirement coming from Sentry.Unity. So, technically we'd want that analyizer there too.

We'd include that here too: https://github.com/getsentry/sentry-unity/tree/main/src/Sentry.Unity
Using relative paths to the sentry-dotnet submodule

[bruno-garcia]

If it's optional, can we got without them? If not, I suggest taking more details from the ticket that introduced this requirement (tldr: Switch file system requirements)

Suggested change

	<value>Route file system access through IFileSystem wrapper.</value><comment>An optional longer localizable description of the diagnostic.</comment>
	<value>Route file system access through IFileSystem wrapper.</value>

[RRode]

I completely dropped the resx and hardcoded the warning, since I assume that no warning translations will be needed.

[bruno-garcia]

Does this need PrivateAssets>all ?

[RRode]

If I understand the docs correctly, it could have even been fine, but I added it anyway. I also added private assets in analyzer references.

[RRode]

That makes sense, #pragma sounds like the right solution

Can you provide some comments or should I just disable the warning in currently offending files?

I also think it's kind of odd, but it's not a big deal. Alternatively it could be a new top level directory: analyzers or build-src I dunno. I think as you did it's fine. But worth adding a README.md on the project directory to clarify this analyizer is only for consumption from Sentry itself, for development of the SDK.

Then I will keep it simple for now and leave it as it is. I added the README, but was not able to remove the one added via Directory.Build.props to the project, so I hope that is OK.

We only really need this on Sentry since this is a requirement coming from Sentry.Unity. So, technically we'd want that analyizer there too.

We'd include that here too: https://github.com/getsentry/sentry-unity/tree/main/src/Sentry.Unity
Using relative paths to the sentry-dotnet submodule

I guess it makes sense to first merge it here and then add it in the other repo, right?