'rnorm' could not be found. Default 'stats' package functions fail to load.

[jmp75]

Trying to release an update for R 4.0.x

Unit tests outputs that the function 'rnorm' could not be found. This is part of the stats package that's always available.
Looking in debug mode, the evaluation results in:

RDotNet.EvaluationException: 'Error in inDL(x, as.logical(local), as.logical(now), ...) : 
  unable to load shared object 'C:/Program Files/R/R-4.0.2/library/stats/libs/x64/stats.dll':
  LoadLibrary failure:  The specified module could not be found.

Usually this is a sign that a DLL dependency of stats.dll cannot be loaded (of course, stupid LoadLibrary message fails to say which module could not be found)

[jmp75]

Using dependencywalker, r.dll, rblas.dll or rlapack.dll are the likely modules not found. Why? what has changed.

[jmp75]

In Rengine.Initialize, the line:

            var status = GetFunction<Rf_initialize_R>()(R_argc, R_argv);

changes the content of the PATH env var. Before that call, PATH starts with C:\Program Files\R\R-4.0.2\bin\x64, however after that call it starts with "C:\rtools40\usr\bin". I cannot see what is going on for this to happen. No wonder loading "stats.dll" fails to locate rblas.dll. This appears to have been going on for a while (also with 3.4.4??). Or the behavior is due to an external change. Surely behaviors have changed at some point, otherwise many unit tests would have failed in the past.

[jmp75]

Tried to compile R from source on Windows to diagnose why R changes the PATH env var. See SO post.

[jmp75]

Figured out that the reason why the PATH and R_HOME env var are reset by the R native engine are because I have an %userprofile%\Documents.Renviron that specifies PATH="${RTOOLS40_HOME}\usr\bin;${PATH}". Cannot remember why I had to do that BTW but pretty sure not by choice. Problem is, in R embedded this appears to take the default PATH and NOT the process current PATH, which is rather aggravating.
I probably should initialise the engine to ignore .Renviron files. Probably will be annoying in some cases, but less than by keeping this behavior. Pretty sure the root cause is in R's void R_SetWin32:

    /* Process R_HOME/etc/Renviron.site, then
       .Renviron or ~/.Renviron, if it exists.
       Only used here in embedded versions */
    if(!Rp->NoRenviron) {
	process_site_Renviron();
	process_user_Renviron();
    }

[jmp75]

Resolved with R.NET 1.9.0, at least on Windows