Another exotic formula. Looks like something mixing or flowing.
Continuing my VS2022 porting story. My first attempt to upgrade failed, a few months later I tried again, this time with more realistic expectations of the time commitment.
I had some success porting some smaller, and some not so small programs to the new framework. I did the first few slowly and carefully. Making sure I understood all of the differences. I compiled a detailed checklist, and the other programs ported smoothly. Eventually I started on the Art program, and had some initial success. The bulk of the program was up and running. Then I hit a wall. Two problems, both related to the dynamic, in-program compile and run add-on code feature.
The Roslyn compile needs a list of dlls used by the program code being compiled. The list contains both the dlls with that I wrote and dlls that contain the .Net 6 library features that I use. In the past it was easy to find the library dlls. If I guessed wrong, then the compiler error message would tell me which type (object) I missed, and the documentation told me the dll that has the missing type. The documentation is not reliable with .net 6. Adding the dll listed in the documentation does not find the missing type. Also, VS2022 introduces two types of dlls (with identical names), one for compilation and one for execution. Grabbing the wrong one causes failure, but only some of the time.
Eventually I made a list of all dlls included with .net 6 and fed that list to the compiler. It works. Since over 90% of them are not used, I know it slows down the compile step. That slowdown is in computer time, I do not notice it. In a whole lifetime, that less than a second delay each time I compile an add-on will not add up to the time already spent trying to debug the problem. This is a good example where trying to be efficient, pick out exactly the dlls I use, turns out to be very inefficient.