Сервер Repka

[Small_Bee]

Проверил еще раз.
Почистил кеш. Удалил скрипт. Запуск - ошибка появляется. В консоли нет ни одного сообщения о каких либо появившихся группах или загрузке подмиссий.
Вернул скрипт на место. Запуск - ошибка появляется. В консоли сообщения о загрузке подмиссий и новых группах самолетов.

--- Добавлено ---

В том-то и дело, что у меня был случай, когда сервер на изменения в скрипте никак не реагировал, а использовал закешированную версию. Впрочем, так получается похоже только если скрипт компилируется в файл 0.dll.

У меня миссия работает без вылезающих окошек. Но у меня изначально пользователю, под которым запускается сервер, были даны права на запись в каталог C:\Program Files (x86)\Steam\steamapps\common\il2back\il-2 sturmovik cliffs of dover\missions и подкаталоги.

Сейчас попробую эти права отобрать...

Мы могли бы говорить о правах или путях, если бы файлы не создавались в принципе. А так один файл у нас вполне создается и все в него пишется. Возможно, проблема могла быть в многопоточности - в одной нити файл открылся с монопольными правами, из другой нити код тоже пытается его открыть. Но ошибка появляется даже если скрипта нет в принципе.

Если по правам и отбивается на какой то файл - явно не из-за скрипта.

--- Добавлено ---

Перепроверил конкретно для миссии StbVolcanicIslands2. К ней сказанное не относится - она компилируется в "5099688294344549696.dll" (цифры - видимо хеш текста скрипта) и ил-2 реагирует на изменения в исходном тексте StbVolcanicIslands2.cs.

Ну, если это действительно хеш текста скрипта, то при каждом изменении будет компилироваться dll с новым именем, соответственно, будет актуальной.

[red75prime]

Проверил еще раз.
Почистил кеш. Удалил скрипт. Запуск - ошибка появляется. В консоли нет ни одного сообщения о каких либо появившихся группах или загрузке подмиссий.
Вернул скрипт на место. Запуск - ошибка появляется. В консоли сообщения о загрузке подмиссий и новых группах самолетов.

--- Добавлено ---



[...]
Если по правам и отбивается на какой то файл - явно не из-за скрипта.

Мда. Остаётся только использовать processmonitor, чтобы точно узнать, что он там пытается открыть.

--- Добавлено ---

Хм.. Я специально включил в скрипт строку, которая просто создавала файл со случайным именем, так что уникальность каждого запуска я вполне мог проверить. По поводу референсов - а как тогда быть со сборками, которые линкуются динамически? Например, хост понятия никакого может не иметь, что эта dll юзает, а юзать она может еще целую пачку левых сборок. Никаких референсов у хоста на них нет, и он ничего о них не знает. А System.Windows.Forms.dll стандартная библиотека и .NET всегда в курсе, где она лежит. Почему например, я вполне могу использовать LINQ и т.д. и т.п. Они тоже включены в референсы приложения?

Одно дело, когда динамически подключается скомпилированная dll, в которую уже включены референсы на используемые ею сборки. А если, как в случае с илом, скрипт компилируется на лету, то при компиляции нужно указывать используемые скриптом сборки. Вот цитата из msdn:

If your project references any assemblies, you must specify the assembly names as items in a StringCollection set to the ReferencedAssemblies property of the CompilerParameters used when invoking compilation.

Так что получается, что LINQ в этот список включен, а System.Windows.Forms - нет. Может быть, что разработчики добавили возможность указывать в тексте скрипта какие дополнительные сборки он хочет использовать, но это знают только они.

[Small_Bee]

Мда. Остаётся только использовать processmonitor, чтобы точно узнать, что он там пытается открыть.

--- Добавлено ---



Одно дело, когда динамически подключается скомпилированная dll, в которую уже включены референсы на используемые ею сборки. А если, как в случае с илом, скрипт компилируется на лету, то при компиляции нужно указывать используемые скриптом сборки. Вот цитата из msdn:

If your project references any assemblies, you must specify the assembly names as items in a StringCollection set to the ReferencedAssemblies property of the CompilerParameters used when invoking compilation.

Так что получается, что LINQ в этот список включен, а System.Windows.Forms - нет.

Гм.. Возможно я ошибаюсь, но...
Конкретно, System.Windows cсодержит кроме MessageBox такие базовые для WPF вещи, как Setter, UserControl, PropertyPath и далее далеко по списку. Не быть включенным он просто не может... Ай блин, это ж сервер... похоже я неправ.

--- Добавлено ---

Да, стопудово, ошибаюсь, сорри.