Говорю свежим взглядом:
Скрипт, как оказалось, абсолютно ни при чем. Последовательно отключал весь ввод-вывод в скрипте - пофиг. После вообще скрипт убрал. Опять пофиг. Ошибка осталась. Вот такие пироги. Делаю ставку на то, что что-то с .NET. Не находить один из самых "most used" неймспейсов - это нонсенс.
Вернул изначальный скрипт, т.к. он оказался не виноватым.
Есть вариант что игра подгружает скомпилированный вариант старого скрипта. Кэш чистили?Сообщение от Small_Bee
Говорю свежим взглядом:
Скрипт, как оказалось, абсолютно ни при чем. Последовательно отключал весь ввод-вывод в скрипте - пофиг. После вообще скрипт убрал. Опять пофиг. Ошибка осталась. Вот такие пироги. Делаю ставку на то, что что-то с .NET. Не находить один из самых "most used" неймспейсов - это нонсенс.
Вернул изначальный скрипт, т.к. он оказался не виноватым.
И, вроде как, нужно делать using System.Windows.Forms. Впрочем, сервер ил-2 вполне может и не референсить System.Windows.Forms.dll - ему она особо и не нужна.
Скрипта не было вообще, Ошибка оставалась. Плюс насколько знаю, все эксепшены в пределах миссии сливаются в консоль без всяких окошек.
Предполагалось использовать вот это - System.Windows.MessageBox.Show("Hello world"). Да и пофиг скрипту что референсит сервер - он сам себе dll и может референсить у себя что угодно, насколько понимаю. Лишь бы приложение нашло нужную длл.
Когда я запускал сервер у себя, он при первом запуске компилировал скрипт и клал дллку в C:\Users\red75\Documents\1C SoftClub\il-2 sturmovik cliffs of dover\cache\0.dll. После этого на изменения в .cs файле не реагировал никак. Приходилось удалять эту "0.dll".
[...]
Перепроверил конкретно для миссии StbVolcanicIslands2. К ней сказанное не относится - она компилируется в "5099688294344549696.dll" (цифры - видимо хеш текста скрипта) и ил-2 реагирует на изменения в исходном тексте StbVolcanicIslands2.cs.
В общем-то, инструкция using ничего не референсит - она позволяет использовать имена классов без указанного namespace prefix. А какие dll доступны скрипту определяет компилятор, который в этом случае вызывается изнутри ила. Так что сделать using System.Windows - недостаточно, нужно ещё чтобы во время компиляции System.Windows.Forms.dll была включена в список референсов.
Крайний раз редактировалось red75prime; 29.07.2011 в 23:20.
Хм.. Я специально включил в скрипт строку, которая просто создавала файл со случайным именем, так что уникальность каждого запуска я вполне мог проверить. По поводу референсов - а как тогда быть со сборками, которые линкуются динамически? Например, хост понятия никакого может не иметь, что эта dll юзает, а юзать она может еще целую пачку левых сборок. Никаких референсов у хоста на них нет, и он ничего о них не знает. А System.Windows.Forms.dll стандартная библиотека и .NET всегда в курсе, где она лежит. Почему например, я вполне могу использовать LINQ и т.д. и т.п. Они тоже включены в референсы приложения?
Проверил еще раз.
Почистил кеш. Удалил скрипт. Запуск - ошибка появляется. В консоли нет ни одного сообщения о каких либо появившихся группах или загрузке подмиссий.
Вернул скрипт на место. Запуск - ошибка появляется. В консоли сообщения о загрузке подмиссий и новых группах самолетов.
--- Добавлено ---
Мы могли бы говорить о правах или путях, если бы файлы не создавались в принципе. А так один файл у нас вполне создается и все в него пишется. Возможно, проблема могла быть в многопоточности - в одной нити файл открылся с монопольными правами, из другой нити код тоже пытается его открыть. Но ошибка появляется даже если скрипта нет в принципе.
Если по правам и отбивается на какой то файл - явно не из-за скрипта.
--- Добавлено ---
Ну, если это действительно хеш текста скрипта, то при каждом изменении будет компилироваться dll с новым именем, соответственно, будет актуальной.
Мда. Остаётся только использовать 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 и далее далеко по списку. Не быть включенным он просто не может... Ай блин, это ж сервер... похоже я неправ.
--- Добавлено ---
Да, стопудово, ошибаюсь, сорри.
Ваши права
Ответить с цитированием