Compiler-generated type as a service

[yallie]

Hi Maksim,

I've updated my app to the last version of DryIoc and found that it's not starting up.
The application couldn't resolve its settings class generated from App.settings file.

I found the exact commit where the breaking change was introduced: 2aaedc4
Then I tried to extract the failing setup into a minimal reproducible unit test and it turned out to be tricky.

I was thinking it was the unusual setup (exported static property) that was problematic.
But finally I discovered that the issue was the CompilerGeneratedAttribute.
I'll create the pull request demonstrating the issue.

Can we disable the rule that ignores the compiler-generated classes as a services?
Does it really help speeding up service resolution?

[dadhi]

I will look.

[yallie]

Thank you! 🙏

[yallie]

Looks like SettingsSingleFileGenerator tool incorrectly uses CompilerGeneratedAttribute instead of
the GeneratedCodeAttribute which should be used. The same issue with StronglyTypedResourceBuilder.

Related MSDN blog post: Correct usage of the CompilerGeneratedAttribute and the GeneratedCodeAttribute.
Even Microsoft's own tools don't use the right attributes.

Unfortunately, there seems to be no way to instruct the tools to avoid emitting the attribute...

[dadhi]

Thanks for the link. It is always good to have a broader look at the problem.

[yallie]

I'm disappointed that CompilerGenerated attribute doesn't actually mean that the code is compiler-generated.
Sometimes C# compiler doesn't apply it to the generated code, and sometimes the attribute is misused by code generation tools.

[dadhi]

Off-topic rant:

Code generation story is lost in the details and history now.
I am in disarray in general where to go here in this direction.
The Source Generators even with the last incremental addition are very specific way to solve the problem with no much flexibility.

I would prefer to go to the T4 way of things, but with better tooling and compiler support.
Or have the pay-for-play story starting from the macros and building all the way to the full code-gen with some things in between.
I would like the Expression Trees to be the basis for such thing - partially because I know them well.
I have also like the way of LeMP/Extended C# which I have explored here. Given that the work was done by one guy it makes Microsoft look like not paying enough attention and effort.

[yallie]

Hmm, interesting...
Is there any benefit from static compile-time service registrations, apart from the faster start-up?
As far as I've seen, DryIoc service discovery and registration is blazing fast, compared to other containers.
For typical applications service registration would take less than a second, and other startup tasks
like looking up something in the database would require much more time anyway. Am I missing something?

[dadhi]

It is mainly about not doing at runtime what can be done at compile-time.

Benefits are having compilation errors upfront instead of runtime blow-up.
You may introspect the generated code and educate yourself that there is no magic induced by IoC. You may search the generated code, go to references, etc. etc.
Performance too, especially at start-up.

But, the sole usage of compile-time generation in real solutions is a myth. I believe you need both compile and run-time tooling and them being good at playing together to get the max of it.

[yallie]

Oh, I see, thanks for the insight.
Compile-time errors vs runtime errors look like the most important point to me :)
I've seen too much cryptic runtime errors in MEF times...

[dadhi]

@yallie What is the name of the class generated from App.settings?
Does it start with '<>'?

[yallie]

No, class name is derived from the settings file name: MyAppConfig.settings → MyAppConfig.Designer.cs.
Similar to resx resource file generator's behavior.