3D.ru

Зачем было вырезать из .NET методы и целые классы?

Допустим, есть dll библиотека, которая используется в WebPlayer сборке. И юзается там File.ReadAllText. Могли бы просто сделать NotSupportedException, так нет же - вырезали метод целиком! Теперь при вызове метода библиотеки, в котором содержится вызов ReadAllText (который может реально не использоваться), имеем MissingMethodException.

А если этот вызов в статическом конструкторе? Получаем TypeInitializationException. Спасибо за это UT, что так внимательно относитесь к подбору .NET специалистов, которые сделали _такое_ с Mono!

Все делаете для скриптеров, а тру программистам руки связываете. А ведь многие выбирают ваш движок именно за поддержку ! Это нормальный полноценный язык программирования, а не какой-нибудь скриптовый UnrealScript и т.п. При этом других движков с удобным редактором в комплекте и поддержкой .NET просто нет! Задумайтесь, именно поддержка готовых решений и стандартов делает продукт востребованным!

Можно ли выразить надежду на более адекватную переработку Mono 3? Для меня полноценная поддержка шарпа - самое важное в Unity.

P.S. Это вопрос-отзыв.

почему не написать это через багрепортер свежей версии? оформить как feature request, описать ситуацию, в которой подобная функциональность была бы полезной, приложить простой пример, демонстрирующий неудобство существующего положения. тестировщики "баг" воспроизведут, отправят разработчикам, а там как повезет, но маловероятно. тут же писать вообще никакого смысла нет. думаете Орлову больше делать нечего, как продвигать ваши хотелки? не поймите меня неправильно, это реальная оценка ситуации.

Отправил багрепорт.

1) What happened
When creating dll plugin for unity I use .NET methods which are accessable in the standalone version but not in the webplayer.

So I expect this to work:
try { File.ReadAllText(...); }
catch(NotSupportedException){ // exception in webplayer }

But when I do things like this I receive TypeInitializationException (my code is located in static class constructor).

I think this problem can be solved if you'd replace such methods body with throwing NotSupportedException instead of fully removing them from framework.


2) How can we reproduce it using the example you attached
Build standalone player and launch. You will see "OK" in log files.
Build webplayer version and launch. You will see TypeInitializationException in player log (see attached).

Visual Studio project with dll source code is also attached.

Мне ответили

We have been able to reproduce this bug and have sent it for resolution with our developers. We cannot say when the resolution will be publicly available.

А потом

Thank you for yous submission, this issue was decided to be by design by our developers and also it reduces the download size of the webplayer.

Вот какой смысл экономить на размере WebPlayer? Он устанавливается 1 раз, при том устанавливается на standalone устройства. Зато могли бы не включать библиотеки .NET в сборки, что значительно ускорило бы их загрузку.

А чего тут капризничать то? Всем известно, что работать с файловой системой клиента, из WEB плеера нельзя. Просто не используйте эти методы, или поставьте их в дефайны.
http://docs.unity3d.com/Documentation/M ... ation.html

Речь идет о внешних библиотеках. Они ничего могут и не знать про юнити. Или даже если знать - придется делать отдельные dll для standalone и web.

Проблема в том, что ВЕСЬ текущий метод не будет выполнен, если хотя бы один из методов, на которые есть ссылки, не существует.

Да, согласен. С внешними библами проблема останется нерешённой. Особенно, если они чужие и закрытые.

это тоже все обходиться, обращаться к внешним библам, если это не вебплеер. типо не дериктива, а condition

pod4444 писал(а):это тоже все обходиться, обращаться к внешним библам, если это не вебплеер. типо не дериктива, а condition

Condition - runtime проверка в самом методе. Весь метод не будет выполнен, если внутри него ссылка на другой, отсутствующий, метод.

А если к сторонним библиотекам нужно обращаться и в webplayer-е?

VBProgr писал(а):А если к сторонним библиотекам нужно обращаться и в webplayer-е?

Да даже к своим это крайне не удобно, в standalone одно в web другое.

А так по теме, обертка для своего нативного кода на .net ограничивает нас еще как, а моно 3 там еще долго не видать.
А как бесит не возможность использовать unity api в своих потоках или асинхроных калбеках.

VBProgr писал(а):Condition - runtime проверка в самом методе. Весь метод не будет выполнен, если внутри него ссылка на другой, отсутствующий, метод.

А если к сторонним библиотекам нужно обращаться и в webplayer-е?

Вы меня не поняли, кондишин перед методом, который может отсутствовать, и в случае, если это не веббилд, он просто не выполнится, и сделать условие иначе, организовать другую логику не проблема.
А я вообще бы сделал два вида поведения и при самом старте проверял, веббилд ли это? Если это веббилд, то делать такую логику, если нет, то другую.
Все проблемы только в Вашей голове.

Ты предлагаешь:


Но это не будет работать, в этом и проблема! Весь код в твоем методе забракуется. Потому что JIT не сможет его скомпилировать. Из-за неверного вызова.

Или ты предлагаешь вызывать метод внешний библиотеки с таким условием? Это не вариант, метод может делать что-то полезное, а обращение к отсутствующему функционалу не использоваться с теми аргументами, которые передаются.

Если код находится в проекте для этого есть директивы, если в отдельных библиотеках, то кондишин должен сработать.

Он не будет работать. Из-за этого и вся тема. Кондишен заработает только в том случае, если обернуть вызов File.ReadAllText в свой метод с NoInlining и проверять кондишен снаружи этого метода.

VBProgr писал(а):Он не будет работать. Из-за этого и вся тема. Кондишен заработает только в том случае, если обернуть вызов File.ReadAllText в свой метод с NoInlining и проверять кондишен снаружи этого метода.

Значит выход все-такие есть?))

Это разве нормальный выход? По-моему это извращение...