14

Мы заметили, что на определенной машине-разработчике Visual Studio (2015 update 3) отладочная сборка решения C# генерирует файл $ RANDOM_SEED $ вместе со всеми встроенными DLL.

Содержимое файла - всего лишь одно число, например. 1443972318

При удалении файлов (ов), а затем восстановление происходит в регенерированном файле с другим номером.

Это поведение наблюдалось при восстановлении одного проекта в решении (которое имеет только стандартные ссылки на C# refs/dependencies + System.Management).

Обратите внимание, что выполняется сборка командной строки, например. msbuild <sln-file> не восстановить файл (для создания полного решения или одного проекта).

После перезагрузки ВС файл больше не восстанавливается.

Насколько известно, имя этого файла не используется ни в одном из наших исходных кодов, шагов пост-сборки или внутренних зависимостей. Существует довольно много зависимостей от классов .NET Framework, включая Random и RNGCryptoServiceProvider, а также внешние зависимости. У нас нет полного исходного кода для всех этих вопросов, поэтому невозможно полностью проверить, какие из них отвечают.

Это немного выстрел в темноте, но вопрос Кто-нибудь видел что-то похожее на это?

EDIT Я не удивлен, это было downvoted - Я ценю это довольно открытым концом, но, как я в настоящее время не в состоянии воспроизвести это, и как это может иметь серьезные последствия (генератор случайных чисел атака?) Я все равно разместил ее. Если я смогу воспроизвести, я, конечно, обножу здесь.

+1

Скорее всего, это файл Microsoft, а не соглашение об именах. Логическое пересечение здания и желание сделать что-то случайное, но повторяемое - это маленькое. Посмотрите на блок-тест, который используется на этих машинах. –

+0

Я видел это сегодня. Не знаю, откуда она взялась. –

+1

Я использовал сторонний инструмент, как указано здесь http://serverfault.com/a/20992 - получается, что vstest.discoveryengine.x86.exe создает файл. Я переработал новое решение с одним проектом библиотеки классов C#. Это даже не нужно строить, просто открытие решения и ожидание обновления окна Test Explorer достаточно. Точный exe: 'C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ CommonExtensions \ Microsoft \ TestWindow \ vstest.discoveryengine.x86.exe' –

ответ

11

У меня такой же файл. После короткого расследования я признал себя виновным: Этот файл создается NUnit 3.x test adapter. (Вы можете проверить его в AdapterSettings.cs из исходного кода адаптера NUnit).

+0

https://github.com/nunit/nunit3 -vs-адаптер/блоб/ведущий/SRC/NUnitTestAdapter/AdapterSettings.cs и да У меня есть установленный тестовый адаптер NUnit 3 v3.5.1 ... –

+0

По-прежнему не уверен в точном использовании случайного значения семени или о том, что это за условие, которое заставляет его записываться в файл. Кроме того, не удалось найти что-либо в тестовом адаптере NUnit [documentation] (https://github.com/nunit/docs/wiki/Visual-Studio-Test-Adapter) об этом ... –

10

Файл используется NUnit для обеспечения того, чтобы мы использовали одно и то же случайное начальное значение для генерации случайных тестовых случаев как в процессах обнаружения, так и при выполнении. Это необходимо, потому что IDE использует два разных процесса для выполнения адаптера. На самом деле это не требуется (или создается) при запуске адаптера под vstest.console.exe.

Смежные вопросы