Здравствуйте!

Возникла проблема. Не могу понять, как ее решить. Пытаюсь с помощью .NET 8 AOT опубликовать свое приложение через Avalonia WebAssembly:

$ dotnet publish -c Release

Есть разные под-проекты. В итоговом проекте есть включенная опция RunAOTCompilation и только в нем.

Сам код рабочий. В браузере все работает. Однако меня сильно смущает следующий момент.

Как будто после AOT некоторые файлы сборок, относящиеся к самой Авалонии, изменили размер (по маске *.wasm). Сильно распух файл dotnet.native.wasm до 45 мегабайт. Но мои собственные файлы, похоже, что вообще не меняются в размере, компилирую я c AOT или без. Причем в каталоге obj есть следы работы Emscripten по моим файлами, да и в консоли это видно во время сборки. Сам процесс публикации заметно дольше происходит с AOT. Речь о каталоге bin/Release/net8.0-browser/publish/wwwroot/_framework.

Что не так-то? Не могу удостовериться, что AOT прошелся по моим файлам сборок *.wasm.

Причем аналогичный десктопный клиент собирается через AOT. Там, буквально, получается один исполняемый файл и две авалоновские динамические библиотеки. Там работает все ожидаемо. А здесь не ожидаемо, хотя и работает.

Может быть, подскажите, как должно быть? Или укажите, где я недопонимаю? Есть еще версия, что такая связка .NET AOT с Avalonia WebAssembly просто необкатана.

P.S. Пытался еще задействовать Obfuscar, но исполняемая машина .NET ругается внутри браузера на обфусцированную сборку.

Прошло время, и у меня сформировалась позиция по этому вопросу. Готов поделиться. Возможно, что кому-то пригодится.

Первое. Очень похоже, что AOT действительно двоично компилирует в WASM. В распухшем файле dotnet.native.wasm я нашел названия своих пространств имен. Из-за того, что там UTF16, то это можно увидеть в Far Manager под виндой, а вот в линуксе в mc это не так просто разглядеть, что меня и смутило поначалу.

Второе. Мои файлы *.wasm по оригинальному байт-коду по-прежнему присутствуют. Они идентичны тем, что были получены без AOT. То есть, фактически файлы с байт-кодом (или как это называется по другому) по-прежнему торчат в интернет. Удалить их нельзя — веб-приложение не может без них загрузиться. Даже если эти файлы *.wasm фейковые, они все равно нужны. Например, нужны для проверки целостности или типа того.

Выводы.

Скорее всего, Техника AOT действительно позволяет ускорить нам приложение, уйдя от интерпретации в сторону исполнения двоичного кода wasm.

Однако если вы желаете защитить свою интеллектуальную собственность через AOT, то здесь в .NET 8 мы пролетаем как фанера над Парижем.

P.S. К сожалению, код после Obfuscar не пожелал загружаться интерпретатором в браузере. Здесь был бы интересен опыт других людей, которые использовали другие обфускаторы для того, чтобы успешно загрузить свой код