Steps to replicate the issue (include links if applicable):
- Set up a machine in a way that only Framework 4.0 needs to be installed
- Load AWB with a settings file that contains an active module
What happens?:
- Error dialog: could not find csc.exe
What should have happened instead?:
- Module compiled without error, and executes.
Software version:
Windows 10 or 11 without Framework 3.5 installed. Note AWB itself requires 4.x.
It turns out that the CSharpCodeProvider uses the provided compiler version to look up the location of csc.exe inside the registry key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\3.5 (in a 64-bit machine anyway; in the case of an x86 machine the unvirtualized version is read), corresponding to the 3.5 compiler version specified by AWB. On new systems, that key does not exist.
The user can hack a new key 3.5 into the registry alongside the existing 4.0 key, and add a string value MSBuildToolsPath:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
The requested AWB fix is to change the three "3.5" references to "4.0" in the source, or specify an empty providerOptions dictionary to the CSharpCodeProvider constructors and let the framework code find the compiler. That works for me but may have other failure modes.