.Net Core 6 jumps the shark
-
Dave Kreskowiak wrote:
Yep, and it was ugly and included certain restrictions on how the code had to be written.
I would need more details. How the code and not for example process failures would lead to problems. I have worked on two products in C# that did dynamic code compiling. Certainly no restrictions that ever stopped what I wanted to do or in one case many customers that were using the product to write code, for the actual code. I didn't try to keep it in memory but the dlls were loaded dynamically in both cases. So converting to memory for that part would have been easy. Now the entire process is "ugly" but in both cases there was much of what was done that could not have been done, in a product feature way, that would have removed that requirement. In both cases people tended to get excited and then over use it. I have done the same with java (at least 3 times) and that problem happens with that as well. However that is a process problem not a code problem. So in C# does it have to do with actually saving it to memory?
You're thinking in technical terms. My issues with the previous ways of doing it are more "customer" issues than anything technical.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak