Runtime: المسح: الأصلي AOT

لم أتمكن من معرفة أفضل تسمية منطقة لإضافتها إلى هذه المشكلة. إذا كان لديك أذونات الكتابة ، فيرجى مساعدتي في التعلم عن طريق إضافة تسمية منطقة واحدة بالضبط.

يبدو وكأنه خطأ مطبعي - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) ربما يجب أن يكون "جزءًا من"؟

أنا سعيد جدًا برؤية هذه المشكلة! 😄🚀

سؤال: بالنسبة إلى مطوري UWP الذين عملوا مع .NET Native toolchain ، هل يجب أن نجيب على الاستطلاع فقط بالقول إننا لم نستخدم CoreRT من قبل ، أو نظرًا لأن .NET Native بها العديد من أوجه التشابه (وبعض الرموز المشتركة أيضًا؟) مع CoreRT ، يجب نذكر هذا فقط في الملاحظات ثم نجيب على أسئلة CoreRT الأخرى فقط فيما يتعلق بتجربتنا مع .NET Native؟ 🤔

@ Sergio0694 شكرا على سؤال UWP. أوافق ، أعتقد أنه من المنطقي أن أذكر ذلك في الملاحظات والرد على نصوص الاستخدام إذا كنت قد استخدمت الإصدار مفتوح المصدر.

شكرا لنشر هذا الاستطلاع!

لقد كنت مرتبكًا أيضًا بشأن كيفية الإجابة على أسئلة معينة بصفتي مطور UWP استخدم فقط .NET Native. لدي عدد من الآراء حول سلسلة أدوات NET Native الخاصة بـ UWP ولكني لم أر حقًا مكانًا لتدوينها. جيد تمامًا إذا كان ذلك خارج نطاق هذا الاستطلاع ولكن قد يكون من المفيد التوضيح.

أشك أيضًا في أن "نظرًا لأن .NET Native هو الإعداد الافتراضي لإصدارات UWP والمطلوبة في المتجر" ربما يكون السبب الأكثر شيوعًا لاستخدام الأشخاص لـ AOT ولكنه ليس أحد الإجابات التي تم ملؤها مسبقًا للسؤال 5.

شكرًا لتضمين Avalonia في خيارات واجهة المستخدم الرسومية :) لقد جربنا CoreRT + Avalonia من قبل وكانت النتائج عبارة عن تطبيقات رائعة وواضحة لواجهة المستخدم الرسومية: D على الرغم من أننا لم نحافظ على توافق منذ أن مرت عامين ...

غالبًا ما يُنسى جزء من .net هو تطوير الألعاب ، فالكثير من المنصات لا تسمح بتشغيل JIT أو التفكير في وحدات التحكم أو أجهزة IOS.
من المهم جدًا بالنسبة لمستقبل تطوير اللعبة الحصول على AOT أصلي .net كمواطن من الدرجة الأولى في النظام البيئي .net.
قامت بعض محركات اللعبة بتدوير AOT الخاصة بها (على سبيل المثال ، Unity تفعل مع il2cpp) لكنها حطام قطار مطلق.
لذا فإن الحل الرسمي سيكون أكثر من موضع ترحيب. يمكن أن يكون حدثا متغيرا للصناعة.
لا تنس أن صناعة الألعاب تتفوق على صناعة التصوير من حيث الربح والمبيعات.
لوحات المفاتيح هي المكان الذي يتم فيه تحقيق الربح الرئيسي.

تعمل الخيارات الحالية لتحسين التطبيقات المنشورة بشكل جيد مع معظم السيناريوهات التي تستهدفها .NET اليوم.

...

AOT مهم في الغالب في تطبيقات واجهة المستخدم الرسومية. هذا هو المكان الذي يحتاج إلى التركيز. لا أرى تطبيقات الويب والخدمات وما إلى ذلك التي تحتاج إلى ذلك

أنا أعترض. للحصول على أفضل تجربة مستخدم نهائية ، هناك حاجة إلى ربط AOT مع ثابت لمحركات الألعاب ، والخدمات الصغيرة بدون خادم ، وتطبيقات واجهة المستخدم الرسومية لسطح المكتب ، وتطبيقات iOS و Android ، والمكتبات / المكتبات الخاصة بجانب العميل المستندة إلى WASM وأدوات CLI الأساسية (حوالي بضعة ميجابايت).

لقد تمنيت أن أتمكن من تجميع الكود الخاص بي بسهولة أثناء تجربة جميع السيناريوهات المذكورة أعلاه في C # على مدار السنوات القليلة الماضية وأشعر أن .NET مفقود بشكل كبير مقارنة باللغات المستندة إلى LLVM مثل Rust.

السبب وراء ظهور خيارات النشر الحالية "تعمل بشكل جيد" هو أن .NET لم تكن من الناحية التاريخية مناسبة للسيناريوهات المذكورة أعلاه وأن الأشخاص قاموا فقط بتنفيذ AOT الخاصة بهم (على سبيل المثال: Unity و UWP و Mono) عند استخدام C #. حلول AOT الجزئية مثل كصورة أصلية (على سبيل المثال ، ReadyToRun) قد "تساعد" في سيناريوهات البدء البارد لتطبيقات الخادم المتجانسة أو تطبيقات عميل سطح المكتب الكبيرة ، لكن الحجم الثنائي لا يزال أكبر بعدة مرات مما ينتج عن وقت تشغيل AOT الكامل.

NET بالفعل لا "تعمل بشكل جيد" للخدمات المصغرة بدون خادم / حاويات - فهذه يمكن أن تستفيد بشكل كبير من تجميع AOT ، وتقليل الحجم الثنائي والحد الأدنى من التبعيات .
لقد وصل حل ReadyToRun + Tiered Compilation + IL Linker الحالي بالفعل إلى الحد الأقصى لحجم الملف وهو أمر مزعج لعمليات النشر المستقلة ، مثل تلك التي أوصت بها AWS Lambda في منشور المدونة الخاص بهم.

المشكلة الحقيقية هي أن هناك حاليًا عددًا كبيرًا جدًا من أوقات التشغيل / مولدات الكود / سلاسل الأدوات / التجارب المتاحة مع المراوغات الخاصة بهم: IL2CPP / Burst (Unity) ، Mono's AOT backend (Xamarin / Blazor / Uno) ، .NET Native / CoreRT (UWP) ، واجهة Mono LLVM الخلفية ، CrossGen / ReadyToRun (.NET Core) ، وما إلى ذلك ، ومن غير المقبول ببساطة أن NET ليس لديها سلسلة أدوات تجميع AOT موحدة.

إذا جمعت كل هذه الفرق جهودها الهندسية على شيء شائع مثل CoreRT أو Mono LLVM backend أو dotnet / lilic التي تم التخلي عنها الآن ، فستكون AOT تجربة أفضل بكثير لمطوري .NET.

يمكن الوصول إلى ربط AOT w / static لعدد كبير من المطورين الآن باستخدام CI / CD للجماهير ولم يعد مجرد مصدر إزعاج لزيادة هامشية في الأداء بعد الآن.

C # endgame: الكود الأصلي ، واجهة المستخدم الأصلية ، التشغيل المتداخل السريع والسهل ، الصادرات الأصلية وواجهات برمجة التطبيقات الموجهة نحو الأداء (على سبيل المثال ، System.IO.Pipelines ، System.Text.Json).

أنا لا أتفق مع البيان القائل بأن تطبيقات الويب لن تستفيد من هذا. ستساعد AOT بشكل كبير في أعباء العمل بدون خادم (ويعرف أيضًا باسم وظائف Azure). ناهيك عن فوائد وقت بدء تشغيل أدوات CLI.

لقد أجبت على الاستبيان ، ولكن لأكون صادقًا ، لم أحصل على هذا السؤال المستمر عن الاستطلاعات منذ بدء .NET Core 1.0 ، بدون توجيه واضح إلى أين تسير الأمور.

NET Native هو ما كان يجب أن يكون .NET عليه طوال الوقت ، عندما بدأ مشروع Ext-VOS ، وهناك تجربة من Singularity و Midori يمكنك بالتأكيد الارتباط بها ، أو حتى الحصول على بعض الخوادم الداخلية معهم.

حتى Java قررت اللحاق بقدرات AOT المفقودة ، فإن الفريق لا يسأل عن أحمال العمل التي نريد أن نجعلها تعمل.

نادرًا ما نستخدم NGEN ، لأنه منذ إصدار .NET ، لم يتم تحسين جودة الكود مطلقًا ، كما أن سير عمل النشر يمثل مشكلة مقارنة باللغات الأخرى المترجمة من AOT.

لذا إذا تم المضي قدمًا ، تم إسقاط AOT مرة أخرى من .NET ، ضع في اعتبارك أن جميع المنافسة في اللغات المدارة تركز الآن في سلاسل أدوات AOT ، كما أنهم لا يسألون عن سير العمل الذي نرغب في استخدام المترجم.

أريد أن أرى .NET تستمر في الازدهار وكونها الخيار الأول بغض النظر عن السيناريو ، وإذا كان هناك أي شيء لتولي مهام سير العمل حيث لا تزال Microsoft تجبرنا على استخدام C ++ جنبًا إلى جنب مع .NET ، والتي لا تواجه لغات AOT المترجمة الأخرى مشاكل معها.

لقد أجبت على الاستبيان ، ولكن لأكون صادقًا ، لم أحصل على هذا السؤال المستمر عن الاستطلاعات منذ بدء .NET Core 1.0 ، بدون توجيه واضح إلى أين تسير الأمور.

أعتقد أنه شيء رائع أن تحاول MS الاستماع إلى المجتمع ، بدلاً من مجرد إملاء ما نريد.

jkotas لقد لاحظت انتشار رابطين مختلفين لهذا الاستطلاع ، فهل هذا جيد؟
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

اسأل texasbruce مطوري البرامج الذين أجابوا على استطلاعات مماثلة بخصوص واجهة المستخدم الرسومية متعددة المنصات وأدوات WCF و EF التي تدعم مدى مساعدتها.

لذلك ، في حين أنه من الجيد أن يسألونا ، سيكون من الأجمل أن تحدث الأفعال بالفعل. حتى بالنسبة إلى واجهة المستخدم الرسومية عبر الأنظمة الأساسية ، يبقى أن نرى ما إذا كان MAUI سيحدث بالفعل أم أننا سنحصل على Blazor في Web Widgets كحل.

بالنسبة لي ، الحل الوحيد المقبول لـ AOT هو عندما يُنشئ تطبيقًا أصليًا حقيقيًا بدون JIT على الإطلاق في وضع الإصدار (لا يوجد حل بديل جاهز للتشغيل جنبًا إلى جنب) وعندما يعمل على all¹ يعمل مطورو مشاريع .NET تشغيل. يتضمن هذا على وجه التحديد Winforms و WPF. في أفضل الأحوال ، يجب أن تعمل أيضًا بشكل مستقل دون أي تبعيات لوقت التشغيل دون تضخيم نفسها من 3 ميجابايت إلى 80 ميجابايت.

¹ لأسباب فنية قد تكون هناك حالات / لا يمكن لـ apis دعم AOT. إن قول "على الكل" يعني عدم دعم جميع واجهات برمجة التطبيقات ولكن جميع أنواع المشاريع التي يدعمها .NET Core: dll / winforms / wpf / winui / console / maui / ... شيء مشابه للتغيير من .NET Framework إلى .NET Core مما أتاح لمعظم المطورين لتولي تطبيقاتهم الحالية هو ما يدور في خلدي.

_ لقد كتبت أيضًا تطبيقات في دلفي وقد أزعجني أن أرى أنني أقوم بتجميع ثم شحن ملف دلفي المنفرد القابل للتنفيذ في مكان آخر ويتم تشغيله للتو. وهو فقط أسرع. الأمر نفسه ينطبق على تطبيق C ++ عند تجميعه بطريقة معينة. ولا يزال بإمكانك تصحيح أخطاء كلا التطبيقين ولا يزال كلا التطبيقين يوفران تتبع مكدس / تفريغ مفيد عندما تقرر تضمين PDB. ولكن لأسباب أمنية ، يمكنك أيضًا أن تقرر عدم تضمينها والتي تعمل أيضًا بشكل جيد. يزعجني أن أسأل نفسي لماذا لا يمكننا الحصول على ذلك مع C #؟ عندما سمعت عن خطط AOT توقعت هذا.

أرى دائمًا أن المشكلات المتعلقة بالانعكاس مذكورة كثيرًا ، وأعتقد أنه في الواقع لا يهم كثيرًا إذا كان ASP.net الأساسي ينتج ملفًا تنفيذيًا كبيرًا.

معظم الأماكن التي تكون فيها AOT متطلبًا صعبًا هي أشياء مثل أدوات CLI والألعاب وتطبيقات واجهة المستخدم ، ويمكن أن تكون انتقائية بشأن المكتبات التي يجب تضمينها ويمكنها تجنب بعض مشكلات الانعكاس. يجب أن تكون الأولوية لتمكين تطبيقات "سجل نظيف".

أرى دائمًا أن المشكلات المتعلقة بالانعكاس مذكورة كثيرًا ، وأعتقد أنه في الواقع لا يهم كثيرًا إذا كان ASP.net الأساسي ينتج ملفًا تنفيذيًا كبيرًا.

مع إصدار Blazor WebAssembly ، أعتقد أن الحجم القابل للتنفيذ وسرعة التنفيذ سيكون لهما أهمية كبيرة ويمكن أن يستفيد بشكل كبير من AOT. ولكن لأي سبب من الأسباب لم يتم ذكرها على وجه التحديد في الاستطلاع.

نعم جميلة من فضلك! كنت أفكر في استخدام Rust أو CoreRT من أجل الحفاظ على أمان الذاكرة واكتساب سرعات أصلية وجعل الكود الخاص بي قابلاً للاستدعاء. ولكن سيكون من الرائع أن يكون لديك AOT في .NET ، لأنها غنية وقوية بشكل لا يصدق ، بينما Rust ، رغم كونها رائعة ، ليس من السهل الانتقال إليها.

jkotas لقد لاحظت انتشار رابطين مختلفين لهذا الاستطلاع ، فهل هذا جيد؟

نعم ، نحن نستخدم روابط مختلفة لـ SurveyMonkey لمنشورات مختلفة. تشير جميع الروابط إلى نفس الاستطلاع. يسمح لنا بمعرفة كيف يختلف توزيع الردود حسب المكان الذي وجد فيه الأشخاص الاستطلاع.

بالنسبة إلى gamedev ، نحتاج إلى هذا ، لقد علقت العمل على محرك اللعبة الخاص بي https://github.com/amerkoleci/alimer_sharp لصالح المحرك الأصلي باستخدام c ++ ، وأحتفظ بربط DirectX ans vulkan أيضًا ، والأداء مطلوب هنا

بالنسبة إلى gamedev ، نحتاج إلى هذا ، لقد علقت العمل على محرك اللعبة الخاص بي https://github.com/amerkoleci/alimer_sharp لصالح المحرك الأصلي باستخدام c ++ ، وأحتفظ بربط DirectX ans vulkan أيضًا ، والأداء مطلوب هنا

سيناريو متطابق هنا 😄 ، إلا أنني لم أعلقه. أنا أحب AOT على حد سواء لأوقات بدء التشغيل الأفضل ولكن أيضًا (وفي حالتي ، الأهم من ذلك) ، فرصة الحصول على كود أكثر تحسينًا - أنا بخير مع زيادة بنسبة 50٪ في أوقات الإنشاء لتسريع 10٪ ، وهو ما من الواضح أنه ليس ' ر حقا موقف JIT

أنا بخير مع زيادة بنسبة 50٪ في أوقات الإنشاء لتسريع بنسبة 10٪ ، ومن الواضح أنه ليس موقفًا من JIT

هذا في الواقع أحد الأسباب الثانوية الكبيرة التي أريد بها AOT في .NET بدلاً من التبديل إلى نظام بيئي مختلف. لقد أفسدت تمامًا أوقات الترجمة السريعة لمشاريع .NET الكبيرة مقارنة بمشاريع C ++ أو Rust الكبيرة.

أريد JIT للتكرار السريع أثناء التطوير ، ولكن بمجرد أن أقوم بشحن شيء إلى عملائي.

لقد استخدمت CoreRT لإنشاء مكتبات أصلية عبر الأنظمة الأساسية (وعبر الأنظمة الأساسية).

AOT w / static linking مطلوب بشكل عاجل لمحركات الألعاب في iOS ومنصة وحدة التحكم التي تعطل jit ، وتريد أيضًا أوضاع تجميع aot متعددة:

1. aot الكامل
2. هجين aot التي تدعم jit + aot أو مترجم + aot وضع التشغيل
   aot الهجين مهم حقًا لصناعة الألعاب ، يمكن أن يغير قواعد اللعبة

AOT w / static linking مطلوب بشكل عاجل لمحركات الألعاب في iOS ومنصة وحدة التحكم التي تعطل jit ، وتريد أيضًا أوضاع تجميع aot متعددة:

1. aot الكامل
2. هجين aot التي تدعم jit + aot أو مترجم + aot وضع التشغيل
   aot الهجين مهم حقًا لصناعة الألعاب ، يمكن أن يغير قواعد اللعبة

مثل mono على نظام iOS الأساسي ، وضع تشغيل aot + مترجم.

Aot الكامل ، exe الفردي ، وقت التشغيل المستقل وقص الرموز غير الضرورية ، يجعلني بالتأكيد kreygasm XD

لقد كنت أنتظر هذا السؤال لمدة 10 سنوات. اللعنة ، لدي 5 مشاريع رائعة تجمع الغبار على القرص الصلب ، لأنني إذا قمت بتحريرها ، يمكن لأي طفل عكسها وإضافة تغييرات بسيطة إلى واجهة المستخدم الرسومية وبيعها على أنها خاصة به.

لقد قمت بتطوير Robocraft و Cardlife و Gamecraft مع Unity على منصة الكمبيوتر الشخصي ولم أحتاج مطلقًا إلى استخدام IL2CPP ، ما لم يكن مطلوبًا (اقرأ Xbox one) ، ولا حتى لخوادم اللعبة. أنا شخصياً أرى مزيجًا من تجميع JIT وحل مثل Burst (الذي يقوم بعمل أفضل من أي وقت مضى باستخدام الجوهر الصريح) أكثر من كافٍ عندما يكون الأداء ضروريًا. ومع ذلك ، أنا أفهم أن AOT ضروري للأنظمة الأساسية التي تتطلب كودًا أصليًا بالكامل وللأنظمة الأساسية التي تكون فيها موارد الأجهزة ثمينة. أفهم كيف يمكن لمطوري منصة .net أن يكون لديهم مشاعر مختلطة حول AOT ، لكنني لا أعتقد أنه خيار إذا أردنا أن يتم تبنيها على نطاق أوسع في تطوير اللعبة. لأكون صريحًا ، هذا يخيفني قليلاً أن Unity تحتكر التكنولوجيا مثل IL2CPP و Burst.

نحن نطور أجهزة محاكاة مالية / علمية عالية الأداء وقابلة للتطوير. يمكن أن تعمل عمليات المحاكاة الخاصة بنا في أي مكان من بضع دقائق إلى عدة أيام اعتمادًا على مدى تعقيد النموذج الذي ينشئه المستخدم.

نظرًا لطبيعة برنامج المحاكاة الخاص بنا ، فإن أوقات بدء التشغيل لا تمثل أي قلق على الإطلاق ، وكذلك البرامج / الأحجام الثنائية. لهذا الأمر ، لا يستغرق تثبيت المنتج أيضًا الوقت المستغرق. على سبيل المثال ، سيكون مقبولًا تمامًا بالنسبة لنا ، إذا كان التجميع جزءًا من التثبيت ، حتى لو استغرقت هذه العملية وقتًا طويلاً.

أود أن أقول إن حوالي 25٪ من الكود أثناء التشغيل يتم إنشاؤه ديناميكيًا ، لذلك يفضل اتباع نهج مختلط ؛ مزيج من تجميع AOT و JIT. إذا كان لابد من تفسير البتات الديناميكية ، أعتقد أن الكثير من فوائد AOT سوف تتضاءل ، على الأقل في حالة الاستخدام لدينا.

إن GC هي مشكلتنا الأولى التي تمنعنا من تحقيق قابلية تطوير أعلى (على سبيل المثال بمجرد أن نحصل على حوالي 44 مركزًا). إن امتلاك المحول البرمجي قادر على القيام بمزيد من التحسينات المتعمقة للتجميع الداخلي ، والتحليل القوي للبطانة الداخلية ، والتحليل الهروب قد يسمح بتخصيص كائن قصير العمر على المكدس بدلاً من الكومة.

هناك العديد من الأماكن في قاعدة الكود لدينا حيث تصبح جودة كود JIT عنق الزجاجة خاصة مع تخصيصات التسجيل والتعامل مع العديد من الهياكل. هذا يجبرنا على كتابة تعليمات برمجية للتعامل مع مترجم JIT للقيام بالشيء الصحيح (لعبة شد الحبل التي تكون هشة ومبهمة ويصعب الحفاظ عليها) أو تسقط في الكود الأصلي (ونفقد الكثير من الفوائد من نقص التضمين والنفقات العامة من انتقالات GC / PInvoke).

في بعض الأحيان ، يمكن أن تؤدي التحسينات الصغيرة في جودة الشفرة إلى تحقيق انتصارات مجنونة على مدار نموذج يتم تشغيله لساعات عبر العديد من النوى. بالنسبة لنا ، أصبح JIT هشًا بعض الشيء (حتى أقل حتمية) مع الأداء ، حيث تتغير قاعدة الكود لدينا مع التطوير. نأمل أن يستغرق مترجم AOT وقتًا أطول في تجميع وتوليد كود عالي الجودة ، مما يقلل من بعض تقلبات الأداء غير الضرورية ، ويسمح لنا بالاحتفاظ بالمزيد من قاعدة الكود الخاصة بنا في C #.

بشكل عام ، أود أن أرى المزيد من الاستثمار في كل من تقنيات JIT و AOT.

تضمين التغريدة

AOT w / ثابت الارتباط ضروري لمحركات الألعاب في iOS ومنصة وحدة التحكم التي تعطل jit ،

أنا أتفق هنا تمامًا. نظرًا لأننا بحاجة إلى حل لهذه المشكلة (رمز C # يعمل على وحدات تحكم الألعاب لمشروع غير Unity) ، فإننا نستخدم سلسلة أدوات تعتمد على Mono-AOT. لكن لديها بعض القيود الخطيرة ولا تؤدي أداءً جيدًا.

لذلك نحن نتطلع إلى تشغيل CoreRT على 3 وحدات تحكم لألعاب الحور (XBox One ؛ PlayStation 4 و Nintendo Switch). يوضح الأستاذ الأولي للمفهوم أنه يعمل بالفعل (لا يزال مع بعض القيود) ولكن بالفعل مع تحسن كبير في أداء وقت التشغيل مقارنة بالحل القائم على Mono.

ولكن مع موقف NDA حول وحدات التحكم في الألعاب ، فإن الدعم الرسمي لهذا الاستخدام يكون بعيد المنال بشكل صحيح أكثر من الحصول على AOT الأصلي الرسمي في المقام الأول.

بالنسبة لنا ، أصبح JIT هشًا بعض الشيء (حتى أقل حتمية) مع الأداء ، حيث تتغير قاعدة الكود لدينا مع التطوير.

@ jpapp05 أود أن أسمع المزيد عن تطبيقك ، والمشكلة المذكورة أعلاه على وجه التحديد ، لأنها أحد اهتماماتي الرئيسية. لا تتردد في الاتصال بي في وضع عدم الاتصال (عبر البريد الإلكتروني في الملف الشخصي) إذا كان ذلك يساعدك.

مرحبًا AndyAyersMS ، سيكون ذلك رائعًا. سأتصل بك في وضع عدم الاتصال حيث يمكنني التحدث بحرية أكبر قليلاً ولكن يسعدني إعادة نشر أي ملخص من مناقشاتنا لصالح الآخرين.

لا أعرف ما إذا كانت هذه مشكلة ولكن فقط أذكرها هنا.
تتمثل إحدى الميزات المهمة بالنسبة لنا في القدرة على تحميل التجميعات الأصلية وإلغاء تحميلها ديناميكيًا في وقت التشغيل.

movedoa راجع واجهات برمجة التطبيقات NativeLibrary https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary؟view=netcore-3.1

مشكلتي الأكبر هي أنه عادةً ما يمكن فك ترجمة .NET بسهولة ، باستثناء UWP Native ، على الأقل بقدر ما اختبرت (أتمنى أن أكون على حق). ليس في عقلية الشركة "العادية" ، سيضع شخص ما الكثير من الملكية الفكرية في مشروع يمكن تفكيكه بسهولة.
نظام Linux رائع ، ولكن جميع تطبيقات سطح المكتب مخصصة لنظام التشغيل Windows في عالم المؤسسات.

ربما لجعل الحياة أسهل ، ضع مربع اختيار يقول:
التجميع الأصلي (يعمل مع WINDOWS 10 DESKTOP فقط!)
يا رجل ، افعل ذلك ولم أعد أهتم بـ AOT بعد الآن. إذا كان يعمل مع ASP.NET Core ، فهذا رائع! إذا لم يكن الأمر كذلك ، فأنا لا أهتم حقًا.

بالمناسبة ، شكرًا لك على طرح المشكلة وإجراء الاستبيان ، لقد قمت بعمل رائع لأنك تطلب رأي الأشخاص الذين يستخدمون التكنولوجيا في وظائفهم. أعتقد (في الحقيقة أنا متأكد) أنك ما زلت تفتقد الكثير من آراء مطوري سطح المكتب الذين لا يشاركون عادةً في هذه الأشياء على Github. لا يتذكر الجميع (أو يعرف) أنه يمكن فك شفرة .NET البرمجية بسهولة وأنا متأكد من أن رؤسائهم سيصابون بالجنون إذا عرفوا: ابتسامة : .

لا يتذكر الجميع (أو يعلم) أنه يمكن فك شفرة .NET بسهولة

Shhh ... حقيقة أن Rider يقوم بذلك تلقائيًا هي أمر مذهل عندما أحاول اكتشاف كيفية عمل شيء ما خلف الكواليس في Unity أو حزم الطرف الثالث. ليست مهمة تقريبًا الآن ، على الرغم من أن الكثير من الشفرات مفتوحة المصدر في المقام الأول ، لكنك تحصل على ما أعنيه.

jcbeppler أنت مخطئ ، هذا هو سوء فهم شائع بين bytecode مقابل original ، إنها مجرد مسألة امتلاك الأدوات الصحيحة.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays هو مجرد حل ممكن ، وهناك حلول أخرى للاختيار من بينها.

MostHated نعم ، فهمت. في الواقع ، من السهل جدًا فك تجميع برنامج في .NET بحيث يبدو أنه مفتوح المصدر والعديد من الشركات لا تريد أن تكون برامجها مفتوحة المصدر. "لا يوجد شيء اسمه وجبة غداء مجانية" 😄

pjmlp أعرف الفرق بين التفكيك مقابل التفكيك. لا يمكنني فعل أي شيء ضد تفكيك برنامجي ، لكن التجميع الأصلي يمكن أن يجعل البرنامج أكثر أمانًا لأن الشخص لا يمكنه القيام بعملية فك تجميع بسيطة للغاية. سيبدو البرنامج المفكك غريبًا بالتأكيد وقد لا يعمل الكود المفكك بشكل صحيح.

jcbeppler أنت مخطئ ، هذا هو سوء فهم شائع بين bytecode مقابل original ، إنها مجرد مسألة امتلاك الأدوات الصحيحة.

حاليا برنامج NET. يكشف فك شفرة المصدر بالكامل. يتضمن هذا أيضًا جميع أسماء العمليات وأسماء المتغيرات. يعد هذا أمرًا رائعًا لتصحيح الأخطاء ويتيح لنا الحصول على تتبع مكدس "قابل للقراءة" عند حدوث استثناء. ومع ذلك ، فهو يمثل عيبًا أمنيًا كبيرًا وسببًا لوجود سوق ضخم لـ .NET obfuscators.

يمكن تفكيك التطبيق الأصلي. لكنها لا تنخفض لتكشف عن الكود المصدري الكامل لـ C ++ / Delphi وما إلى ذلك (هناك بعض الأدوات التي تحاول إعادة بناء هذا الكود المصدري ولكن النتائج مروعة). ما تحصل عليه هو رمز المجمع والتحكم في مخططات التدفق على الأكثر. إذا كنت محظوظًا وتم شحنه بملف رمز ، فستحصل أيضًا على أسماء الوظائف ولكن في وضع الإصدار ، لا يتم تضمين ملف الرمز هذا عادةً ، مرة أخرى لأغراض أمنية.

يمكننا أن نفقد أنفسنا في التفاصيل عندما نتحدث عن الكود الأصلي الذي يمثل حماية حقيقية. في رأيي ، لا يمثل هذا حماية من حيث الاختراق (على الرغم من أنه بفضل الطريقة الكاملة / أسماء المتغيرات الكاملة وتوليد مصدر C # الكامل ، يمكن إزالة فحص الترخيص دون الحاجة إلى أي معرفة خاصة) أو تصحيح الأخطاء ، ولكن حماية ضد المتسللين. يمكن لأدوات مثل dnSpy تصدير تطبيق .NET إلى مشروع VS كامل بواسطة نقرة واحدة. لا توجد أداة من هذا القبيل تعمل بنفس الطريقة للتعليمات البرمجية الأصلية. لذلك بالنسبة للتطبيقات التجارية ، سيكون إنشاء كود أصلي مكسبًا كبيرًا ، إلى جانب حقيقة أنه لم يعد يتعين عليهم دفع آلاف الدولارات سنويًا مقابل شيء يقوم فقط بإعادة تسمية جميع الأساليب والمتغيرات في التطبيق النهائي.

أشعر بالفضول بشأن نتيجة هذا الاستطلاع. هل هناك أي خطط لجعلها علنية حول كيفية تصويت الناس؟

Symbai إنها ليست حماية ضد أي شيء ، حيث سيخبرك أي مطور Android حاول استخدام NDK كوسيلة لحماية IP الخاص به. يمكن للتطبيقات التي ذكرتها بإيجاز أن تفعل الشيء نفسه بنقرة واحدة ، وعلى الرغم من أنها عادة ما تفترض كود C أو C ++ كرمز مصدر أصلي ، إلا أنها جيدة بما يكفي لسرقة الخوارزميات الخاصة بك.

أريد AOT ، للسيناريوهات التي يخسر فيها .NET على المدى الطويل ضد Rust و Go و Swift و C ++ و Java (GraalVM) وسطح المكتب ووحدة التحكم وتطبيقات الهاتف المحمول / IoT حيث يكون وقت بدء التشغيل مهمًا حقًا ، وهناك قيود عالية على استخدام الذاكرة وفقدان السرعة بسبب JIT عند تحميل التجميع أمر غير مقبول ، تمامًا كما هو الحال في بعض سيناريوهات ASP.NET ، قد يكون رمز AOT مناسبًا عندما يقوم المرء بتوسيع نطاق 100 K8S pods.

على الجانب الآخر ، أجد أنه من المناسب أيضًا الحفاظ على قدرات JIT ، وتحسينها أيضًا ، في السيناريوهات التي يكون فيها JIT هو السبيل للذهاب.

هناك الكثير من اللغات التي تقدم كلا من نماذج التجميع ، مما يسمح لمستخدميها بالاختيار والاختيار اعتمادًا على الموقف ، لذلك يتيح أساسًا الاحتفاظ بـ JIT ، وتحسين قصة AOT في اتجاه .NET الأصلي ، مع نسيان المحاولة الخجولة المسماة NGEN.

Symbai إنها ليست حماية ضد أي شيء ، حيث سيخبرك أي مطور Android حاول استخدام NDK كوسيلة لحماية IP الخاص به. يمكن للتطبيقات التي ذكرتها بإيجاز أن تفعل الشيء نفسه بنقرة واحدة ، وعلى الرغم من أنها عادة ما تفترض كود C أو C ++ كرمز مصدر أصلي ، إلا أنها جيدة بما يكفي لسرقة الخوارزميات الخاصة بك.

سرقة خوارزمية يمكنني التعايش معها ، ولكن ليس ما تسمح به .NET اليوم (مثل WPF) ، حيث يكون لدى الشخص تطبيقك الكامل بشكل جميل وسهل التشغيل كمشروع VS. أعتقد أن UWP مع التجميع الأصلي يقوم بعمل جيد ، إذا أراد شخص ما تفكيكه ، حسنًا ، حظًا سعيدًا! سأستخدم دائمًا الترجمة الأصلية ، بغض النظر عن أي شيء. عالم Android الذي لا يمكنني التحدث عنه ، جربت AOT مع Xamarin Forms مرة واحدة ولم تنجح حقًا كما توقعت.

أعتقد أن UWP مع التجميع الأصلي يقوم بعمل جيد ، إذا أراد شخص ما تفكيكه ، حسنًا ، حظًا سعيدًا! سأستخدم دائمًا الترجمة الأصلية ، بغض النظر عن أي شيء. عالم Android الذي لا يمكنني التحدث عنه ، جربت AOT مع Xamarin Forms مرة واحدة ولم تنجح حقًا كما توقعت.

المفسد - من المحتمل أن يحاول الأشخاص الذين يحاولون الوصول إلى مصدرك تحسين / توسيع / ​​الاندماج معك ، وليس تمزيقك. إذا كانوا يحاولون خداعك ، فإن مقاييسك سخيفة حقًا.

إذا كتبت كتابًا ، فطلب من شخص ما ترجمته إلى اليابانية قبل أن أنشره - قد أعتقد أنني ذكي حقًا ، لأنني لا أفهم اللغة اليابانية ، ولا يفعل أي من أصدقائي أيضًا. لكن الحقيقة هي أن هناك دولًا بأكملها يمكنها قراءة هذا الكتاب - وأنا لا أفعل شيئًا أكثر من خداع نفسي إذا تظاهرت بخلاف ذلك.

أقول هذا كمطور ليس لديه خبرة في الثنائيات الأصلية المفككة ، وقرر إجراء هندسة عكسية لتنسيقات التشفير والبيانات على Star Citizen.

استغرق الأمر مني ، كشخص ليس لديه خبرة سابقة ، أسبوعين للانتقال من لا شيء ، إلى امتلاك برنامج لا يمكنه فقط فك تشفير ملفات البيانات المشفرة ، ولكن أيضًا تحويل تنسيقات البيانات الخاصة بهم إلى XML / JSON.

بعد هذين الأسبوعين - قد لا يكون طلبك الكامل جاهزًا للتشغيل كمشروع VS - لكنني أدرك أيضًا أنني لست بحاجة إلى ذلك. من الأسهل بكثير إدخال الكود الخاص بي في التطبيق الحالي ، وعدم الاضطرار إلى التعامل مع جميع الكود الخاص بهم.

إلى امتلاك برنامج لا يمكنه فقط فك تشفير ملفات البيانات المشفرة

التشفير شيء مختلف تمامًا. يعد تفكيك لعبة VIDEO GAME لإنشاء تعديلات أمرًا مختلفًا تمامًا. لا يمانع معظم مطوري الألعاب إذا قام معجبوهم بإنشاء تعديلات ، بل يُظهر شغفهم وحبهم للعبة. وربما لم يكن "التشفير" عبارة عن تشفير على الإطلاق ولكن كانت الملفات معبأة فقط بحجم أصغر؟ لعدم الاضطرار إلى تخزين آلاف الملفات الفردية على القرص. قد يكون الأداء سببًا أيضًا ... قراءة العديد من الملفات الصغيرة من القرص أبطأ من قراءة ملف ضخم واحد. وبعد أسبوعين تمكنت من تفريغ الصور المعبأة. كنت قادرا على تغيير النص داخل بعض ملفات البيانات. هذا شيء عظيم ولكن ليس السبب الذي يجعل الناس مثلي يريدون التخلص من JIT.

المشكلة التي نواجهها الآن هي أن كود JIT يمكن فكه بالكامل لإكمال كود المصدر ، Java لديها نفس المشكلة مثل أي لغة JIT أخرى. يمكن تفكيك الكود الأصلي (سيؤدي ذلك إلى تحويل رمز الجهاز إلى رمز تجميع) ، ويمكن كسر التطبيقات الأصلية بما يكفي من المال ، كل هذا صحيح ولكن لا يمكن تجميع الكود الأصلي لإكمال كود المصدر. هل سبق لك أن رأيت أداة مثل dnSpy لرمز C ++؟ كود دلفي؟ أنا لم أفعل. نظرًا لأنه لا يمكن الحصول على أسماء المتغيرات والطرق ، فهي بسيطة لم تعد موجودة بعد الآن عند تجميعها بشكل صحيح. لا يمكن تحويل التفكيك إلى C ++ وإنشاء مشروع يعمل بالكامل يمكنك تجميعه. يجب أن يبدو هذا شيئًا غير مهم جدًا بالنسبة لك ، ولكنه شيء ضخم للتطبيقات التجارية. نريد فقط التخلص من حقيقة أن تطبيق .NET هو كتاب مفتوح يمكن للجميع القراءة منه بدون أي معرفة على الإطلاق. عندما نضع آلاف الدولارات في البحث ، لا نريد أن ينظر الجميع إليها وينسخها في غضون ثوانٍ قليلة. نريد التخلص من دفع آلاف الدولارات مقابل مُعتِم يكون الغرض الوحيد منه هو إعادة تسمية جميع المتغيرات وأسماء الطرق ، حتى لا يتمكن الأشخاص من فتح التطبيق والبحث عن "ترخيص" للوصول إليه على الفور. ليس فقط (ولكن في الغالب) تكاليف التعتيم ولكن أيضًا أن أدوات التعتيم تخلق مشاكل إضافية. واجهت هذا بنفسي في كثير من الأحيان خاصة مع تكرار إصدارات NET Core. كان علينا الانتظار عدة أسابيع فقط للحصول على التصحيح الذي يجعل obfuscator يعمل مع أحدث إصدار من .NET Core.

وبينما تواجه كل هذه المشكلات بصفتك مطورًا ، يتعين عليك أيضًا شرحها لمدير عملك. في مرحلة ما قد يسألك عما إذا كان من الأفضل اختيار لغة برمجة مختلفة بعد ذلك.

مع C ++ و Delphi ، ببساطة لا تواجه هذه المشكلة. أعلم أن هذه ليست مشكلة للجميع. سيجد مطورو البرامج مفتوحة المصدر أن JIT أكثر إثارة للاهتمام وفائدة. من الصعب أن أشرح لهم لماذا يريد شخص ما أن يكون كود المصدر الخاص به كتابًا مغلقًا ، في حين أنهم يعتقدون أن الكتب المفتوحة أفضل. لذلك من الناحية المثالية ، لا يتعين علينا أن نشرح لبعضنا البعض وجهات نظرنا المختلفة تمامًا وستكون AOT مجرد مفتاح يمكنك تشغيله في وضع الإصدار إذا كنت تريد ذلك. وإذا كنت لا تريد ، فابدأ في JIT.

أنا ممتن حقًا لفريق .NET الذي سمح لنا باختيار "الحماية" كسبب وراء رغبتنا في AOT ❤. يظهر أنهم على دراية باحتياجات بعض الناس. وإذا كشفت استطلاعات الرأي أن الرجل يصوت لصالحها ، فقد تكون لدينا فرصة أخيرًا لأن تطبيق AOT سيهتم بهذا الأمر بنفس طريقة مترجم C ++. لمعلوماتك: لقد وضعتها في علامات اقتباس لتجنب مزيد من المناقشة حول مقدار الحماية التي توفرها AOT في الواقع ، وجهات النظر واسعة للغاية حول هذا ، كما قد لاحظنا بالفعل.

الأمن ليس كل شيء أو لا شيء. لا تؤدي إزالة IL إلى منع المهاجم المصمم من عكس أحد التطبيقات. لكنها تخلق عقبات ذات صلة بالمعنى العملي. إنه دفاع في العمق. هذا هو السبب في أن منتجات التشويش IL يمكن أن تكون منطقية للاستخدام.

قام أحد أصدقائي بتكسير منتجات .NET عن طريق فك ترجمة IL إلى C # وإجراء تعديلات تافهة إلى حد ما. إنه غير قادر على كسر التطبيقات المحلية. إنه أصعب بكثير. كان عليه أيضًا أن يستسلم في وجود IL obfuscators لأن أداة فك التحويل تحطمت على تلك الثنائيات. مرة أخرى ، كانت هذه المنتجات محمية بالمعنى العملي. انها عملت.

تضمين التغريدة

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

تقوم Hex-Rays بعمل جيد لـ C ، ولديها وحدات ماكرو للمساعدة في عملية اتخاذ القرار.

وجود مصدر C هو عبارة عن مسرحية للأطفال لتحويلها إلى C ++ أو Delphi.

بالإضافة إلى أننا نمتلك الآن ذكاءً اصطناعيًا لمساعدة أولئك الذين ليسوا ماهرين بما يكفي.

الهندسة العكسية العصبية للثنائيات المقطوعة

تقوم Hex-Rays بعمل جيد لـ C ، ولديها وحدات ماكرو للمساعدة في عملية اتخاذ القرار.

هل تعمل في Hex-Rays أم في شركة تبيع برامج التشويش؟ يبدو أنه.

على أي حال ، حتى إذا قمت بتحويله إلى C ، فسيكون الرمز بعيدًا جدًا عن بنية C # الجيدة. حتى إذا حصلت على أجزاء من الكود ، فسيتعين عليك بذل قدر كبير من الجهد لتغييره وتحسينه وما إلى ذلك ...
إذا كان التجميع الأصلي غير ذي صلة بالنسبة لك ، حسنًا. لكن بالنسبة لكثير من الناس هو ذو صلة.

راجع للشغل: تبدو مهتمًا جدًا بمواكبة تجميع JIT ويبدو أيضًا أن لديك خبرة كبيرة في تفكيك البرامج. أتساءل لماذا وأين كان عليك استخدام ذلك ؟!

بغض النظر عن ما يشعر به أي منكم بشأن سهولة فك ترجمة كود الآلة مقابل IL ، فإنه لا يغير حقيقة أنه مطلب حقيقي في الأعمال التجارية الحقيقية. (ويمكننا أن نتجادل حول مدى صحة أو عدم صلاحية هذا الشرط حتى تعود الأبقار إلى المنزل).

كان صاحب العمل السابق يحظر صراحةً شحن أدوات .NET أو JVM خارجيًا لهذا السبب. قبل أن أترك فريقًا واحدًا ، أقنع الشركات العليا بالسماح لهم بشحن أداة بها تشويش شديد مطبق ، لكننا بخلاف ذلك كنا نكتب أدوات خارجية في C ++ لإرضاء سياسة الشركة.

هذه المناقشة ذهبت بعيدا عن القضبان. إذا كنت تريد جميعًا أن يكون لديك حرب مشتعلة حول ما إذا كانت AOT مناسبة لحماية IP ، فالرجاء القيام بذلك في مكان آخر.

تقوم Hex-Rays بعمل جيد لـ C ، ولديها وحدات ماكرو للمساعدة في عملية اتخاذ القرار.

هل تعمل في Hex-Rays أم في شركة تبيع برامج التشويش؟ يبدو أنه.

على أي حال ، حتى إذا قمت بتحويله إلى C ، فسيكون الرمز بعيدًا جدًا عن بنية C # الجيدة. حتى إذا حصلت على أجزاء من الكود ، فسيتعين عليك بذل قدر كبير من الجهد لتغييره وتحسينه وما إلى ذلك ...
إذا كان التجميع الأصلي غير ذي صلة بالنسبة لك ، حسنًا. لكن بالنسبة لكثير من الناس هو ذو صلة.

راجع للشغل: تبدو مهتمًا جدًا بمواكبة تجميع JIT ويبدو أيضًا أن لديك خبرة كبيرة في تفكيك البرامج. أتساءل لماذا وأين كان عليك استخدام ذلك ؟!

على العكس من ذلك ، فأنا أمتلك المهارات اللازمة لعكس هندسة الكود الأصلي إلى الكود المصدري الذي يمكن أن تستخدمه أطراف ثالثة بشكل أكبر ، لذلك أنا أدرك تمامًا أن التحويل البرمجي إلى الكود الأصلي لا يمثل سوى عقبة أمام أطفال البرنامج النصي ، وهو ما يبدو أنه الفهم المفقود هنا.

تحرير: وقف تعليقاتي أيضا. أردت فقط الرد على الهجوم الشخصي.

يجب أن يكون Cloud Native و WPF AOT.
عميل Windows لا يوجد وقت تشغيل! لا JIT

تم نشر نتائج الاستطلاع - https://github.com/dotnet/runtime/issues/41522. نحن الآن بصدد المتابعة مع الأشخاص الذين قدموا معلومات الاتصال الخاصة بهم ولديهم بعض أسئلة المتابعة الإضافية.

AOT w / ثابت الارتباط ضروري لمحركات الألعاب في iOS ومنصة وحدة التحكم التي تعطل jit ،

أنا أتفق هنا تمامًا. نظرًا لأننا بحاجة إلى حل لهذه المشكلة (رمز C # يعمل على وحدات تحكم الألعاب لمشروع غير Unity) ، فإننا نستخدم سلسلة أدوات تعتمد على Mono-AOT. لكن لديها بعض القيود الخطيرة ولا تؤدي أداءً جيدًا.

لذلك نحن نتطلع إلى تشغيل CoreRT على 3 وحدات تحكم لألعاب الحور (XBox One ؛ PlayStation 4 و Nintendo Switch). يوضح الأستاذ الأولي للمفهوم أنه يعمل بالفعل (لا يزال مع بعض القيود) ولكن بالفعل مع تحسن كبير في أداء وقت التشغيل مقارنة بالحل القائم على Mono.

ولكن مع موقف NDA حول وحدات التحكم في الألعاب ، فإن الدعم الرسمي لهذا الاستخدام يكون بعيد المنال بشكل صحيح أكثر من الحصول على AOT الأصلي الرسمي في المقام الأول.

RalfKornmannEnvision هل تستخدم منافذ Xamarin Xbox One / PS4 Mono مع كود LLVM؟

RalfKornmannEnvision هل تستخدم منافذ Xamarin Xbox One / PS4 Mono مع كود LLVM؟

lateralusX بما أن الدمج تم بواسطة شخص آخر ، فلا أعرف أي تفاصيل. لكن على حد علمي ، استخدموا المنافذ الأحادية المتوفرة لجهاز XBox One / PS4 وصنعوا منفذًا بسيطًا للمحول. أنفسهم.

RalfKornmannEnvision سيكون رائعًا للتواصل ومناقشة التجربة المتعلقة بهذا الأمر. يحتوي LLVM codegen (اعتمادًا على المشروع) على تأثيرات أداء إيجابية للغاية على الكود الذي تم إنشاؤه ، لذا إذا لم يتم استخدامه (يحتاج إلى التمكين) ، فعادة ما يمكن تحقيق الكثير من خلال تمكين ذلك. هل أنت على خادم الخلاف DotNetEvolution ، إذا كان الأمر كذلك فربما يمكننا إجراء مناقشة غير متصلة بهذا الأمر؟

lateralusX أنا متأكد من أن أعضاء الفريق الذين عملوا على هذا قد مكّنوا LLVM codegen وجربوا أشياء أخرى. كان بيانهم الأخير قبل الانتقال إلى مشروع آخر هو أن هذا هو أفضل ما يمكنهم فعله.

كجزء من التحقيق الذي أجريته ، قمت بإنشاء معيار مع المكون الأساسي باستخدام Xamarin Android وتشغيله على جهاز يستند إلى Tegra X1 لمعرفة ما إذا كنا قد فقدنا الأداء بسبب مشكلة في منفذ Switch المخصص الخاص بنا من Mono. لسوء الحظ ، لم يكن أداء مشروع Xamarin مختلفًا عما رأيناه على Switch.

أنا آسف لأنني لست على خادم الخلاف هذا ، ولكي أكون صادقًا ، فإنهم لا أعرف الكثير عن تكامل MONO الحالي على أي حال. من وجهة نظري ، إنه طريق مسدود على أي حال لهذا المشروع. النموذج الأولي الحالي لـ CoreRT (مع وجود دعم رسمي أقل) هو بالفعل أفضل بكثير عندما يتعلق الأمر بالأداء وسهولة الاستخدام.

RalfKornmannEnvision حسنًا ، شكرًا لمعلوماتك وتعليقاتك ، كلها قيمة جدًا.