Optimize-DbContext: same problem as many times before: Exceeds maximum filename length

Many times earlier, Microsoft's development tools have had the specific weakness that some limit has been exceeded, also in case of EF Core.

It can be an idea to create a deep hierarchy using CASE which exceeds the maximum height, 10, which SQL Server supports.

Maximum length of filename for automatically generated filenames, which Windows Workflow Fundation did.

Now Optimize-DbContext does exactly the same, creates some enormously long filenames, so the command fails at some time because the generated filename exceeds the limit.

Is there any idea in creating these countless tiny files and not just one as it's not possible to update the created compiled model but only to create a new one from scratch.

I think you should either:
*) Create only one file with all the stuff.
*) Create files having names like f1, f2, f3 etc., then the lenght shoould not be exceeded.

The current approach with countless tiny files is generally a very inefficient way to use the filesystem.

Couldn't you instruct your staff, that as they dynamically create something in some domain having specific limits, then the staff should ensure, that these limits will not be exceeded. It can not be so difficult to adhere to.

Now, due to your decision, this is again something which is only usable in tiny demo-cases. A problem which has characterized EF for all the years as you can read about in countless posts, particularly in scope of EF before CORE.

I am sorry for my rather negative tone, but I consider the persistent approach to denote complete carelessness. Can it really be correct it must be a problem again and again?

So, due to your decision, I cannot use this at all. Probably it's the same concerning many other people.

... and it does not solve the problem to enable support for long filenames in Windows 10, which I am using.