What is the $RANDOM_SEED$ file generated by Visual

Question

We noticed that on a certain dev machine a Visual Studio (2015 update 3) debug build of a C# solution was generating a $RANDOM_SEED$ file alongside every built DLL.

The content of the file is just a single number e.g. 1443972318

Deleting the file(s) then rebuilding resulted in the file being regenerated, with a different number.

This behaviour was also observed when rebuilding a single project in the solution (one which has only the standard C# project refs/dependencies + System.Management).

Note that running a command line build e.g. msbuild <sln-file> did not regenerate the file (for build of complete solution or single project).

After a restart of VS, the file is no longer regenerated.

As far as we know this file name is not used in any of our source code, post build steps or internal dependencies. There are quite a few dependencies on .NET framework classes, including Random and RNGCryptoServiceProvider, and also external dependencies. We don't have complete source code for all these so it's not possible to check exhaustively which if any of the dependencies are responsible.

This is a bit of a shot in the dark but the question is has anyone seen anything similar to this?

EDIT I'm not surprised this has been downvoted - I appreciate it is pretty open ended, but as I'm currently not able to reproduce this and as it could have potentially serious consequences (random number generator attack?) I have posted it anyway. If I am able to repro I will of course update here.

Answer 1

I have the same file. After a short investigation I found guilty: this file is created by NUnit 3.x test adapter. (You can check it in AdapterSettings.cs from NUnit adapter source code).

Answer 2

The file is used by NUnit to ensure that we use the same random seed value for generating random test cases in both the discovery and execution processes. This is required because the IDE uses two different processes to execute the adapter. It's not actually required (or created) when running the adapter under vstest.console.exe.