Runtime: exe واحد مستقل التطبيق وحدة التحكم

هذا السيناريو غير مدعوم الآن. راقب https://github.com/dotnet/corert repo للعمل الذي سيؤدي إلى هذا المسار.

CoreRT هو المكان المناسب للبحث عن هذا الحل.

شكر. يبدو أن CoreRT هو بالضبط ما كنت أبحث عنه.

بالنسبة للآخرين الذين قد يتعثرون في هذا ، اقرأ هنا

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

NET Framework هو "غش" لأن لديك الكثير من الملفات الموجودة بالفعل في نظام التشغيل.
يمكنك تحقيق الشيء نفسه مع .NET Core ، عن طريق تثبيت NET Core المشتركة على مستوى الجهاز إذا كان هذا هو ما تريده.

إعادة هيكلة CoreCLR لدمج جميع ملفاته في ملف واحد (بما في ذلك الملف الأصلي + المُدار) هو عمل غير تافه ولا أعتقد أن السيناريو مثير للاهتمام للعديد من العملاء.

الفرق هو أن كل جهاز يعمل بنظام Windows مضمون أن يكون لديه .NET Framework وليس NET Core ، لذلك ما لم يكن هناك سبب خاص يستحق جعل النشر أكثر تعقيدًا ، أعتقد أنني سأنتهي في النهاية بالبقاء هناك.
أعتقد أن العملاء لا يكتبون عادةً أدوات مساعدة exe واحدة. ربما ذات يوم. :-)

ما لم يكن هناك سبب خاص يستحق جعل النشر أكثر تعقيدًا

هناك العديد من الأسباب لتفضيل .NET Core على .NET Framework. الأداء ، والنمطية ، وإمكانية الخدمة ، والعزل ، وما إلى ذلك ، وهذا يتجاهل النظام الأساسي المشترك.

إن وجود أداة exe واحدة هو في الغالب مصدر قلق تجميلي. لا يوجد فرق وظيفي حقيقي (لأي شخص معني) إذا كان الملف القابل للتنفيذ ملفًا واحدًا أو مجلدًا واحدًا به عدد قليل من الملفات.

mellinoe يا أوافق على المشاريع بشكل عام ، هذا صحيح بالتأكيد. في المرافق الصغيرة حيث يكون هذا المستحضر التجميلي مرغوبًا فيه ، قام .NET Framework حتى الآن بعمل جيد بما فيه الكفاية. أوافق على أنها مستحضرات التجميل بنفس معنى القدرة على تحديد شركة تجميع ورسالة حقوق النشر. لكن كوني شيئًا تجميليًا لا يجعلني أحبه أقل. من الواضح أنها ليست أولوية هنا ، هذا مفهوم تمامًا.

يحتمل أن تكون ذات صلة: https://github.com/dotnet/core/issues/600

انها ليست مستحضرات التجميل في الغالب. تخيل أنني أريد توزيع تطبيق يحتوي على العديد من المكونات المضمنة في الداخل ، مثل Idsrv4 أو RavenDb + عناصري الخاصة. يأخذون الاعتماد على البتات الأساسية aspnet. كل هذا يعمل بشكل جيد طالما أنهم يعتمدون على نفس الإصدار من aspnet core. بمجرد أن ينتقل أحدهم إلى الإصدار التالي ، من المحتمل ألا يعمل. إذا كان بإمكاني دمج كل مكون في ملف .dll واحد ، فستختفي المشكلة.

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

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

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

لم أقصد إصدار وقت التشغيل ، أعلم أن هذا لن ينجح. ما أعنيه هو ، ما يحدث في السيناريو الخاص بي عندما يعتمد كل مكون على [email protected]. ثم يتم تحديث المكون a إلى [email protected]. عادةً ما يكون ذلك جيدًا ، ولكن في هذا الافتراض لا يعرف مؤلفو LibXYZ / لا يهتمون بإصدار الدلالي. جعل Ilmerge هذه المشكلة تختفي.

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

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

بصفتي مطور lib ، سأقدر عودة ILMerge إلى Core. 👍

Dotnet.exe هو ملف واحد. NuGet.exe هو ملف واحد. أعتقد أن مستحضرات التجميل مهمة ، وملف واحد يصرخ بالبساطة بطريقة لا تحتوي على مجلد يحتوي على 100 ملف! سيكون من الرائع إيجاد طريقة لتحقيق ذلك باستخدام dotnetcore

افترضت أن هذا كان ممكنًا ، وبعد عدة أسابيع من العمل ، أتيت لنشر أداة وحدة تحكم CLI على exe. واحد ... يبدو ummm في الوقت الحالي لا يمكنني الحصول على ملف واحد * .exe ؟؟
اعتقدت أن هذا هو الهدف من التطبيقات الأساسية المستقلة؟

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

اعتقدت أن هذا هو الهدف من التطبيقات الأساسية المستقلة؟

الهدف من التطبيقات القائمة بذاتها هي أنها قائمة بذاتها ، أي أنها لا تتطلب تثبيت Net Core على الجهاز المستهدف ، لأن التطبيق نفسه يحتوي على كل ما يحتاجه للتشغيل.

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

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

أكتب بانتظام أدوات سطر الأوامر في .NET وامتلاكها كـ 1 EXE يجعل عمليات الترقية / النشر / التغليف أسهل. أقوم دائمًا بحزم جميع ملفات التكوين والملفات الأخرى المطلوبة داخل EXE.

فكر في هذا EXE المنفرد كحاوية صغيرة. تنطبق هنا جميع مزايا عمليات النشر القائمة على الحاويات تقريبًا.

هذا أمر مروع ، أتساءل لماذا تمت الموافقة على ذلك أثناء عملية التصميم ، وأرغب في توزيع طلبك على أحد عملائك ، ثم حظًا سعيدًا للعثور على ما يفتح:

هذا مجرد فوضى قبيحة وكاملة

مدة العرض/
MyProgram.exe
MyLib.dll

كان من الممكن أن تكون هذه فكرة أفضل

حتى Java تتعامل مع ذلك بشكل أفضل:

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

ScellowPRIMETSS علي ان اوافق

كيف لا يزال هذا حتى مشكلة؟ الطلب من خلال السقف لهذا.

نعم لهذا المجلد المنفصل مع الإضافة إلى ضغط ذلك في حاوية ولديك ملفان ، exe و bin. توزيع سهل.

+1 آخر لإعادة فتحه وله كميزة.

كنت أتوقع أن يكون النشر المستقل قائمًا بذاته ووجد طريقي هنا. أود أيضًا أن أرى هذا يحدث.

كيف يمكن لأي شخص أن يقول هذه مجرد مسألة تجميلية؟ (مطورو Framework فقط ...)
لم يفكر أحد في الأدوات التي لم يتم تثبيتها؟ (NET محلول dll-hell و. net core يعيده)

أريد فقط أن تكون أداة سطر الأوامر الخاصة بي قائمة بذاتها.

هذا سيء ، حقا سيء!

+1

+1 لقد حاولت للتو تشغيل نشاط مخصص في Azure Batch على مجموعة بدون وقت تشغيل .net الأساسي ولا يمكنه التعامل مع العدد الكبير من الملفات التي ينشئها الإصدار "المستقل".

Total size of resourceFiles cannot be more than 32768 characters

هذا ليس حلاً رسميًا ، لكنه قد يكون مفيدًا. أنا مؤلف أداة warp ، وهي أداة تتيح لك إنشاء تطبيقات ثنائية فردية قائمة بذاتها: https://github.com/dgiagio/warp

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

الاعوجاج هو حل مبتكر ، هذا ليس ما نريده

ما نريده هو:

dotnet publish --self-contained -c Release -r win10-x64

وينتج:

App.exe
runtime/

أو أفضل مثل GO / Rust وما إلى ذلك

App.exe

كل شيء آخر غير مطلوب

ينتج برنامج Warp الملف App.exe ... كيف يتم اختراقه؟ من الواضح أنه ليس جزءًا من إطار العمل ، ولكنه يحقق هدف "ملف exe واحد".

هذا ما أعنيه ، يجب أن يكون سلوكًا افتراضيًا ، وليس استخدام حل جهة خارجية (على ما أعتقد)

يعمل الاعوجاج على علاج. شكرا لعملكdgiagio!

+1

أرغب بشدة في رؤية نوع من أرشيف الملف الفردي الذي يجمع الملف القابل للتنفيذ وجميع التبعيات. ليس من الضروري أن يتضمن تلك الأصلية - أعتقد أنه من الجيد تمامًا طلب تثبيت dotnet core على النظام. شيء مشابه جدًا لملفات Java jar. ملف دار؟

شيء مثل:
dotnet تنشر قائمة بذاتها
تشغيل dotnet - MyApp.dar مستقل بذاته

يبدو أن هناك اقتراحًا لهذا الآن: https://github.com/dotnet/designs/pull/52/files ؟short_path=28dba55

إليك مشكلة التتبع: https://github.com/dotnet/coreclr/issues/20287

أيضًا ، لدى shanselman منشور مدونة حول حل Warp:

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

قرأت الاقتراح ورأيت هذا:

هذا ليس ما كنت أفكر فيه ، هذا يبدو وكأنه عملية بطيئة ، في الأساس مجرد ضغط كل شيء ..
على الرغم من أنه سيتم دمج كل التعليمات البرمجية في ملف تنفيذي / dll واحد؟ أو ربما فاتني شيء في العرض؟

RUSshy هل تسأل عن

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

CC: jeffschwMSFT

لماذا تحتاج الملفات إلى الاستخراج؟ اعتدنا على التخلص من هذا في .NET باستخدام ILMerge.

@ phillip-haydon ، كما هو موضح هنا ، تحقق ILMerge وحلول الملف الواحد أهدافًا مختلفة.

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

CoreRT هو شيء آخر ، تجميع AOT لرمز .NET الخاص بك ، يبدو مثيرًا للاهتمام ، لكنه غير جاهز بعد (أتمنى أن يركز MS عليه ، ويخصص المزيد من الموارد .. هذا هو بالضبط ما يريده الناس ، ولماذا انتقلوا إلى GO )

على أي حال ، ليس لدي معرفة تقنية للحديث عن التفاصيل ، لكن حالة الاستخدام هي:

انشر ملفًا تنفيذيًا واحدًا قائمًا بذاته ، وفقط ، لا شيء مضغوط ، لا شيء مستخرج ، لا يوجد حمل ، فقط الملف التنفيذي

@ swaroop-sridhar هل لديك مثال على هذا العمل لنواة dotnet على لينكس؟ وفقًا لـ https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13 هذا مشروع windows / mono فقط.

thefringeninja ILMerge هي أداة Windows ، ولا أعرف أي خطط
سيتم تنفيذ حل الملف المنفرد عبر الأنظمة الأساسية. هذا في طور التطوير.

تضمين التغريدة
نشر نشر نشر!إذا كان ملفًا واحدًا أو أقل مثل 1-3 ملفات ، فسيكون ذلك أفضل للنشر (Inlcude نشر ، تحديث)!

CoreRT هو AOT
لكن شركته تنوي تريد AOT؟
لا يكون المشروع (CoreRT) دائمًا جاهزًا للاستخدام (من 2014). الآن هو عام 2019! ( حوالي 5 سنوات )
يا لها من 5 سنوات ثمينة للغة الرسم التخطيطي!CoreRT حتى لا توجد أي خطة للإصدار القادم !!!دعنا ننتظر 5 سنوات أخرى؟

@ swaroop-sridhar هذا مؤسف. يعد ILMerge / ILRepack أمرًا رائعًا لمطوري المكتبات لتجنب مشكلة التبعية الماسية.

هناك خطط لدعمه في .NET Core 3.0 - يمكن لـ richlander إطلاعك على الحالة.
تم ذكره في منشورات مدونة .NET Core 3.0 - على سبيل المثال هنا: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ في "جنبًا إلى جنب- الجانب ونشر التطبيقات المحلية ".
اقرأ أيضًا: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfcontainedExecutableOutOfANETCoreApplication.aspx

لا ينبغي أن تحتاج .net إلى كل هذه الاختراقات لإنتاج ملف تنفيذي صغير واحد قائم بذاته .. يجب أن يكون سلوكًا افتراضيًا ، يتم أكلك حيًا بواسطة GO ، يأتي Rust أيضًا ، والتركيز على CoreRT أو ILMerge ، تطبيقات .net الأساسية موجودة بالفعل أيضًا طويل للبدء بسبب كل الملفات المراد تحميلها ، لا تضف المزيد من الاستماع إلى هذا مع zip / unzip كما هو مذكور في الاقتراح ، فهذه ليست الطريقة المناسبة

لا ينبغي أن تحتاج .net إلى كل هذه الاختراقات لإنتاج ملف تنفيذي صغير واحد قائم بذاته .. يجب أن يكون سلوكًا افتراضيًا ، يتم أكلك حيًا بواسطة GO ، يأتي Rust أيضًا ، والتركيز على CoreRT أو ILMerge ، تطبيقات .net الأساسية موجودة بالفعل أيضًا طويل للبدء بسبب كل الملفات المراد تحميلها ، لا تضف المزيد من الاستماع إلى هذا مع zip / unzip كما هو مذكور في الاقتراح ، فهذه ليست الطريقة المناسبة

كما تريد. net لا يجب أن يكون على قيد الحياة ، لأن ppl لديه جافا.
يجب ألا يدعم go or rust أو dlang هدف البناء لبرنامج واحد قابل للتنفيذ ، لأن لديهم Fuck Zip / Unzip!

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

لا ينبغي أن يحتاج .net إلى كل هذه الاختراقات لإنتاج ملف تنفيذي صغير واحد قائم بذاته

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

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

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

هل فكر الفريق في إنشاء إصدار منفصل من .net يركز على التطوير المحلي والبيئات المقيدة ، كما فعلت Jetbrains مع kotlin JVM / kotlin NATIVE؟

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

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

بعد قراءة https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md يبدو أن هناك المزيد من الخطوات للاقتراح ، ولا ينتهي عند zip / unzip لذا معركة خاسرة ، نأمل أن يتمكن الفريق من تقديم شيء أخف ، وهو مذكور في تلك الوثيقة ، جيد!

أشياء كهذه هي سبب بقاء Windows نظام تشغيل ألعاب.

kjkrum أشياء مثل ماذا؟

cryru هذا ما يقوله الناس عندما لا يعرفون ماذا يفعلون.

Cryru أشياء مثل عدم القدرة على إنشاء ملف تنفيذي مستقل ،

Cryru أشياء مثل عدم القدرة على إنشاء ملف تنفيذي مستقل ،

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

تم حل هذا.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

تفاصيل:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-installables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

تم حل هذا.
TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

تفاصيل:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-installables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

في أي إصدار من dotnet-core تمت إضافة هذه الميزة؟ أنا أستخدم 3.0.100-preview5-011568 وتلقيت هذا الخطأ:
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

جنيه: في الواقع ، يبدو أنه يوجد خطأ في بناء الجملة فقط في https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md والذي ينص على النشر بـ dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true وهو في الواقع بدون إضافة --self-contained .

شكرًا mihaimyh سأصلح الخطأ المطبعي في مستند التصميم.

أنا دائما ضد استخدام حل zip / unzip لميزة واحدة قائمة بذاتها .
لأن هذا سيؤدي إلى المشكلة التالية.
كيفية تقليل حجم ملف exe المفرد!

في الواقع ، منذ البداية يجب استخدام طرق مماثلة IL-Merge.

لا ينبغي أن يكون هناك نقاش ، فهذه مضيعة للوقت ، ولم يطلب أحد ضغط / فك ضغط كل شيء ، ومع ذلك فقد جاءوا بهذا التصميم وأهدروا وقتهم ووقتنا

يسأل الناس عن ملف واحد قابل للتنفيذ و AOT ، توقف عن إضاعة وقتنا Microsoft

أريد صراحة ملف واحد بدون AOT. أنا أفضل القدرة على JIT حتى أتمكن من استخدام الانعكاس والأدوية العامة والتعليمات البرمجية التي تم إنشاؤها في وقت التشغيل.

أعتقد أن MS لا تريد أن تسمع ، حسنًا

أنا دائما ضد استخدام حل zip / unzip لميزة واحدة قائمة بذاتها .
لأن هذا سيؤدي إلى المشكلة التالية.
كيفية تقليل حجم ملف exe المفرد!

لست متأكدًا من فهمي ، كما لو كان مضغوطًا مضغوطًا بالفعل. أم أنك تقصد تقليل التبعيات الزائدة وبالتالي تقليل الحجم قبل الضغط؟

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

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

أعتقد أن MS لا تريد أن تسمع ، حسنًا

على العكس من ذلك ، فهم يطلبون ويجمعون مجموعة واسعة من حالات الاستخدام التي يمكنك رؤيتها في سلاسل الرسائل ذات الصلة. رأيك مهم ، لكن آراء الآخرين في المجتمع لا تقل أهمية ولا يجب أن تسخر من Microsoft للاستماع إليها.

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

أنا دائما ضد استخدام حل zip / unzip لميزة واحدة قائمة بذاتها .
لأن هذا سيؤدي إلى المشكلة التالية.
كيفية تقليل حجم ملف exe المفرد!

لست متأكدًا من فهمي ، كما لو كان مضغوطًا مضغوطًا بالفعل. أم أنك تقصد تقليل التبعيات الزائدة وبالتالي تقليل الحجم قبل الضغط؟

إذا كنت تستخدم WebApi أو MVC أو ConsoleApp ، فاكتب HelloWorld! أنت تعرف جيدًا ما يعنيه.
الملف المحزّم كبير جدًا. يجلب الكثير من التعليمات البرمجية ولكن لن يتم تنفيذه أبدًا.
إذا كانت طرق IL-Merge ستقلل من فرع الكود غير المستخدم.

نعم متأكد من أنني قمت بعمل وحدة تحكم HelloWorld ونعم متأكد من 68 ألف

كان عدم احتواء الذات 67 كيلو
لكن C # ليس التجميع. إذا أردت <1K HelloWorld فلماذا أستخدم c #؟
تستخدم التطبيقات الأكبر حجمًا قدرًا أكبر من إطار العمل ، لذلك في مرحلة ما ، يكون رمزها المخصص أكثر من إطار العمل ..
هل نحن قلقون حقًا بشأن بضع 100 ألف؟ إذا كان الأمر كذلك ، لا تستخدم إطار عمل وتقضي الوقت في كتابة كل شيء من البداية ؟؟
ما الذي افتقده هنا؟

أنا دائما ضد استخدام حل zip / unzip لميزة واحدة قائمة بذاتها .
لأن هذا سيؤدي إلى المشكلة التالية.
كيفية تقليل حجم ملف exe المفرد!
إذا كنت تستخدم WebApi أو MVC أو ConsoleApp ، فاكتب HelloWorld! أنت تعرف جيدًا ما يعنيه.
الملف المحزّم كبير جدًا. يجلب الكثير من التعليمات البرمجية ولكن لن يتم تنفيذه أبدًا.
إذا كانت طرق IL-Merge ستقلل من فرع الكود غير المستخدم.

sgf هناك

• كيف تقلل رمز التطبيق؟
• كيف تحزم التطبيق في ملف واحد؟

لتقليل الشفرة ، هناك العديد من التقنيات الأخرى

• دمج IL: هذا ليس لجميع التطبيقات ، لأنه يفقد هوية التجميع في هذه العملية. هذا ليس هدفًا للعمل المفرد الحالي.
• تقليم IL غير المستخدم: يهدف ILLinker إلى تقليم IL غير المستخدم. تم دمج هذه الميزة في dotnet SDK (خاصية PublishTrimmed ) ، وهناك المزيد من التحسينات في ILLinker قيد التطوير.
• Zip / Unzip: dotnet publish لا يضغط حاليًا الملف الفردي المنشور ، ولكن يمكن القيام به.

كيف تحزم التطبيق في ملف واحد؟
يدعم dotnet publishing النشر في ملف واحد - سيكون الملف المنشور بحجم التطبيق بخلاف ذلك.

فيما يتعلق بإنشاء الكود الأصلي:

• يتم حاليًا دعم إنشاء التعليمات البرمجية الأصلية من خلال برنامج التحويل البرمجي الجاهز للتشغيل (خاصية PublishReadyToRun ).
• النشر عبر تجميع AOT رائع (

نعم متأكد من أنني قمت بعمل وحدة تحكم HelloWorld ونعم متأكد من 68 ألف

كان عدم احتواء الذات 67 كيلو
لكن C # ليس التجميع. إذا أردت <1K HelloWorld فلماذا أستخدم c #؟
تستخدم التطبيقات الأكبر حجمًا قدرًا أكبر من إطار العمل ، لذلك في مرحلة ما ، يكون رمزها المخصص أكثر من إطار العمل ..
هل نحن قلقون حقًا بشأن بضع 100 ألف؟ إذا كان الأمر كذلك ، لا تستخدم إطار عمل وتقضي الوقت في كتابة كل شيء من البداية ؟؟
ما الذي افتقده هنا؟

آسف كما هو موضح ، مع استمرار وجوده. هذا 68626 كيلو بايت ، حوالي 68 ميجا بايت = 68 كيلو بايت ، وليس 68 كيلو بايت فقط !!!
لن نحتاج إلى <1 كيلو بايت (مع استمرار هذا مستحيل) ، <3000 كيلو بايت على ما يرام ، قبول.
لكن 68 ميجابايت هو أكثر من 30X +
لن تكتب دائمًا برنامج HelloWorld !!!

الاعتذار ، في وقت متأخر من الليل خطأ مع K's
شكرًا على الشرح / المعلومات المضافة swaroop-sridhar ، بعض المفاتيح الجديدة هناك لم أكن على دراية بها.
جربت للتو 3. معاينة 6 مع المفاتيح التالية

dotnet publish -r RID / p: PublishTrimmed = صحيح / p: PublishSingleFile = صحيح
والآن انخفض العدد إلى 29000 ألف

بالتأكيد لن تكون جميع التطبيقات عبارة عن تطبيق Hello World ، ولكن بالنسبة لتطبيق C # Core SelfContained ، الذي يحتوي أيضًا على وقت التشغيل ... أنا شخصياً لا تقلق. من المؤكد أنني أفهم ما إذا كنت تكتب أداة وحدة تحكم صغيرة ، فسيكون من الجيد الحصول عليها 3K. لكن لماذا نستخدم C # لذلك في المقام الأول؟
مناقشة مثيرة للاهتمام على الرغم من الرجال!

30 ميغا بايت LOL ، اتصل بي عندما يكون هناك شيء مثل 1-3 ميغا بايت ، وقت التشغيل مليء بالسخام ، تحقق من GO ، الناس يهاجرون في موجة

https://www.jetbrains.com/lp/devecosystem-2019/

حتى kotlin تبدأ في اكتساب الأسهم ، ومع وجود لغة kotlin الأصلية ، فإنها تضع c # للعار

وسويفت ينتقل إلى الويندوز https://forums.swift.org/t/swift-win32-programming/20686

لذا إليك بعض الاقتراحات:

• إضافة خيار لإزالة الانعكاس
• إضافة خيار لإزالة عناصر JIT
• تحسين أفضل لرمز C # حتى لا تعتمد على JIT

30 ميغا بايت LOL ، اتصل بي عندما يكون هناك شيء مثل 1-3 ميغا بايت ، وقت التشغيل مليء بالسخام ، تحقق من GO ، الناس يهاجرون في موجة

https://www.jetbrains.com/lp/devecosystem-2019/

حتى kotlin تبدأ في اكتساب الأسهم ، ومع وجود لغة kotlin الأصلية ، فإنها تضع c # للعار

وسويفت ينتقل إلى الويندوز https://forums.swift.org/t/swift-win32-programming/20686

لذا إليك بعض الاقتراحات:

• إضافة خيار لإزالة الانعكاس
• إضافة خيار لإزالة عناصر JIT
• تحسين أفضل لرمز C # حتى لا تعتمد على JIT

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

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

تقوم Microsoft بعمل رائع مع .NET منذ بدايتها وأكثر من ذلك في العامين الماضيين ، لذا شكرًا لك على ذلك.

ما الرد على مثل هذا اللامعنى والأكاذيب وقلة الكفاءة؟

لقد فشلت في إدراك مدى خطأ الاتجاه الأساسي .net ، وفقط مؤخرًا بدأوا في إدراك ذلك من خلال العمل على Distribution / IL Merge / AOT

والآن ، للتحرك في عربة تجميع الويب ، لا يمكنهم ذلك لأن وقت تشغيل .net يمثل ضخامة لدرجة أنهم غير قادرين على نشر الملفات ذات الحجم المناسب

وما زلت عالقًا مع عبارة "من يهتم بالحجم على الخادم." ، فإن طريقة التفكير هذه هي التي جعلت من "من المفترض أن يكون حديثًا". net core إلى كومة تقنية قديمة وغير ملائمة

لا تقوم Microsoft بعمل رائع مع .net ، لقد فشلوا لأنهم أرادوا إرضاء كبار السن من أجل توافق إطار عمل .net ، وكان ذلك أحد أخطائهم

آسف إذا بدوت وقحًا ولكن في بعض الأحيان تحتاج إلى إجراء تغييرات

آسف إذا كنت أبدو فظا ولكن

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

الاعتذار ، في وقت متأخر من الليل خطأ مع K's
شكرًا على الشرح / المعلومات المضافة swaroop-sridhar ، بعض المفاتيح الجديدة هناك لم أكن على دراية بها.
جربت للتو 3. معاينة 6 مع المفاتيح التالية

dotnet publish -r RID / p: PublishTrimmed = صحيح / p: PublishSingleFile = صحيح
والآن انخفض العدد إلى 29000 ألف

بالتأكيد لن تكون جميع التطبيقات عبارة عن تطبيق Hello World ، ولكن بالنسبة لتطبيق C # Core SelfContained ، الذي يحتوي أيضًا على وقت التشغيل ... أنا شخصياً لا تقلق. من المؤكد أنني أفهم ما إذا كنت تكتب أداة وحدة تحكم صغيرة ، فسيكون من الجيد الحصول عليها 3K. لكن لماذا نستخدم C # لذلك في المقام الأول؟
مناقشة مثيرة للاهتمام على الرغم من الرجال!

ألا يجب أن يكون لكلغة حديثة القليل من الطموح لتوحيد العالم؟
هل تريد جميع المطورين الذين يكتبون c # العودة إلى الوطن لـ C ++؟ أو دفعهم للذهاب ، Kotlin ، Swift؟
حصة السوق ومزيد من تآكل ج #؟

غاب .Net لأنه لا ينفذ عبر الأنظمة الأساسية أول 15+ عامًا من فرصة التطوير العظيمة.
ولكن الآن. net عاد إلى الطريق الصحيح.

نعم كما علقت من قبل لست متأكدًا من سبب السلبية.
لم يكن NET Core سوى رائعًا إذا كنت قادمًا من Full Framework. وأعتقد أن رؤية الاندماج .Net Standard + Core معقولة وتقدمية.

لا جدوى من مقارنة .NET بـ GO أو أي لغة / إطار عمل آخر.
على أي حال ، أنا خارج عن هذا الموضوع ، حيث أعتقد أن الحل الذي يعملون عليه وتحسينه لـ Single .exe قد حل "السؤال" الخاص بي منذ عدة سنوات إلى الوراء ... جيد بما يكفي بالنسبة لي ، ويلائم احتياجاتي الفورية.

لذا شكرًا يا شباب وبنات!

خارج

أود أن أذكر الجميع في هذا الموضوع بمدونة قواعد السلوك .

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

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

شكرا لك!

أنا دائما ضد استخدام حل zip / unzip لميزة واحدة قائمة بذاتها .
لأن هذا سيؤدي إلى المشكلة التالية.
كيفية تقليل حجم ملف exe المفرد!
إذا كنت تستخدم WebApi أو MVC أو ConsoleApp ، فاكتب HelloWorld! أنت تعرف جيدًا ما يعنيه.
الملف المحزّم كبير جدًا. يجلب الكثير من التعليمات البرمجية ولكن لن يتم تنفيذه أبدًا.
إذا كانت طرق IL-Merge ستقلل من فرع الكود غير المستخدم.

sgf هناك

• كيف تقلل رمز التطبيق؟
• كيف تحزم التطبيق في ملف واحد؟

لتقليل الشفرة ، هناك العديد من التقنيات الأخرى

• دمج IL: هذا ليس لجميع التطبيقات ، لأنه يفقد هوية التجميع في هذه العملية. هذا ليس هدفًا للعمل المفرد الحالي.
• تقليم IL غير المستخدم: يهدف ILLinker إلى تقليم IL غير المستخدم. تم دمج هذه الميزة في dotnet SDK (خاصية PublishTrimmed ) ، وهناك المزيد من التحسينات في ILLinker قيد التطوير.
• Zip / Unzip: dotnet publish لا يضغط حاليًا الملف الفردي المنشور ، ولكن يمكن القيام به.

كيف تحزم التطبيق في ملف واحد؟
يدعم dotnet publishing النشر في ملف واحد - سيكون الملف المنشور بحجم التطبيق بخلاف ذلك.

فيما يتعلق بإنشاء الكود الأصلي:

• يتم حاليًا دعم إنشاء التعليمات البرمجية الأصلية من خلال برنامج التحويل البرمجي الجاهز للتشغيل (خاصية PublishReadyToRun ).
• النشر عبر تجميع AOT رائع (

كما هو مطلوب دمج ديناميكي - DLLs الأصلية إلى اسم واحد يحب: XXX.exe (غير مدار).
استخدام التحليل الثابت للتحليل عند تجميع ارتباط مستوى الوظيفة الأصلي (غير المدار).

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

إذا قمت بعمل جيد ، فربما تكون النتيجة 2-3 ميغابايت. عندما تم تعبئتها مباشرة مع 7zip ، يستغرق الأمر حوالي 4.85 ميغابايت. الآن نحصل على XXX.exe

تطوير ارتباط مستوى الوظيفة المماثل مع IL-merge.
ل DLL المدارة نفس الخدعة القديمة مرة أخرى.
في الماضي ، قم بتضمين DLL المُدار كأقسام PE.exe (ضع علامة على قسم .net).

ليعكس ، تحليل DLL من نوع الانعكاس. احتفظ بالبيانات الوصفية ونوع الانعكاس (بما في ذلك الوظيفة) وكل شجرتها المعتمدة.

أعتذر ، لا أريد أن أستغرق المزيد من الوقت للمشاركة في النقاش حول هذا بعد الآن. لا يمكن توحيد الآراء.
في البداية كنت أتوقع النتيجة. ولكن الآن ، ربما ينبغي علي التفكير في لغات برمجة أخرى لتلبية احتياجاتي (ربما يكون Dlang ربما Go ربما Kotlin أو Nim أو ربما Rust هو الأفضل).

شكرا على كل هذا الحديث معي. آسف لتذمر بلدي. خارج

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

1. يدعم Mono بالفعل تجميع AOT مع Linking لتقليل حجم الملف. هذا هو أحد أسباب اختيار mono لتطبيق وقت تشغيل المتصفح .net. https://www.mono-project.com/docs/advanced/aot/ وافترض أن هذا هو السبب في أن مشاريع Blazor يمكن أن يكون لها رابط.

2. أعلنت Microsoft أنها تريد دمج أوقات تشغيل .NET الخاصة بهم في واحدة "قوية للغاية". بدلاً من استخدام mono لبعض الأشياء ، و .NET Core للآخرين ، فإنهم يريدون وقت تشغيل واحد يمكنه تقديم جميع السيناريوهات. يعني هذا الأمر فعليًا أنه سيحتاج إلى دعم AOT وربط / تجريد الكود وما إلى ذلك. لذلك أتوقع على مدار السنوات القليلة القادمة ، إما وقت تشغيل .NET Core للحصول على هذه الميزات ، أو دمج ميزات Mono و .NET Core في نسخة جديدة مدة العرض.

إذا كان أي شخص يعرف أفضل ، من فضلك أبلغني.

+ 2

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

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

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

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

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

@ Alan-FGR

ولكن حتى الآن يبدو أنه يتم اتخاذ القرارات دون أخذ ذلك في الاعتبار.

هل لديك أمثلة محددة لمثل هذه القرارات لمشاركتها ، حيث سأكون فضوليًا لمعرفة المزيد.

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

ما عليك سوى إلقاء نظرة على ملاحظات الإصدار لمعاينة .net core 3.0.0 6:

اليوم ، نعلن عن .NET Core 3.0 Preview 6. وهو يتضمن تحديثات لتجميع التجميعات لتحسين بدء التشغيل وتحسين التطبيقات حسب الحجم باستخدام تحسينات linker و EventPipe. لقد أصدرنا أيضًا صور Docker جديدة لـ Alpine على ARM64.

يبدو لي أنهم يدركون تمامًا أن حجم التطبيق مهم لسيناريوهات معينة - خاصة الآن مع Blazor في هذا المزيج.

@ وافق Alan-FGR ، التركيز على الويب غريب نوعًا ما بالنظر إلى أن IIS لديها حوالي 8 ٪ من حصة السوق وتتراجع. ASP.NET غير ذي صلة ، ولن يؤدي أي تحسين لـ C # أو مكتباتها القياسية إلى تغيير ذلك. يتم الحفاظ على C # من خلال تطبيقات وحدة التحكم وخدمات Windows وتطبيقات الأجهزة المحمولة وألعاب الكمبيوتر. يعود الفضل في استمرار وجودها إلى Unity و Xamarin. إنه لأمر مخز ، لأن C # هي لغة ممتعة حقًا للتطوير فيها. هذا مدح كبير قادم من مطور Java منذ فترة طويلة والذي لا يزال يعتقد أن Microsoft تركت علامة مائية عالية مع Windows XP.

كما هو مطلوب دمج ديناميكي - DLLs الأصلية إلى اسم واحد يحب: XXX.exe (غير مدار).
استخدام التحليل الثابت للتحليل عند تجميع ارتباط مستوى الوظيفة الأصلي (غير المدار).

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

تطوير ارتباط مستوى الوظيفة المماثل مع IL-merge.
ليعكس ، تحليل DLL من نوع الانعكاس. احتفظ بالبيانات الوصفية ونوع الانعكاس (بما في ذلك الوظيفة) وكل شجرتها المعتمدة.

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

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

ولكن حتى الآن يبدو أنه يتم اتخاذ القرارات دون أخذ ذلك في الاعتبار.

هل لديك أمثلة محددة لمثل هذه القرارات لمشاركتها ، حيث سأكون فضوليًا لمعرفة المزيد.

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

dazinator أعتقد أن حقيقة أن MS تعتقد بطريقة ما أن Mono هو حل لائق لأي شيء

متفق عليه ، التركيز على الويب غريب نوعًا ما بالنظر إلى أن IIS لديها حوالي 8٪ من حصة السوق وتتراجع. ASP.NET غير ذي صلة ، ولن يؤدي أي تحسين لـ C # أو مكتباتها القياسية إلى تغيير ذلك. يتم الحفاظ على C # من خلال تطبيقات وحدة التحكم وخدمات Windows وتطبيقات الأجهزة المحمولة وألعاب الكمبيوتر.

@ kjkrum هذا هو بيت القصيد. ومع ذلك ، ربما لا تزال حصة 8٪ في السوق بالنسبة لهم على الويب أهم بكثير من تطبيقات Windows والأجهزة المحمولة. تساعد تقنيات الويب الجيدة على الأقل مبيعات خوادم Windows ، لذا فإن اهتمامهم بذلك واضح تمامًا ، لكن التركيز كثيرًا عليها يعد أيضًا استراتيجية ضحلة جدًا وأنا أرفض تصديق أن هذا هو ما يدفع قراراتهم. يبدو أن MS يسير في الاتجاه الصحيح مع مؤسسة dotnet والعديد من المشاريع الواعدة الجارية ، لكن يبدو أنهم يتركون الفرصة للحصول على تكنولوجيا مهيمنة.

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

يعود الفضل في استمرار وجودها إلى Unity و Xamarin.

نعم ما هي نعمة ونقمة بسبب مشاكل فنية كثيرة. الوحدة على سبيل المثال لها سمعة سيئة للغاية ولكن لحسن الحظ لا يبدو أنها تؤثر على .NET / C #.
ومع ذلك ، فإن XNA ، على الرغم من أنه بعيد عن الكمال ، لا يزال يتمتع بسمعة كبيرة بشكل لا يصدق بين المستخدمين والمطورين.

سعيد لرؤية هذه الأرض مع .NET Core 3.0 اليوم. شكرا يا رفاق! 👍

لست متأكدًا من أن هذا هو ما يريده الناس ، إذا انتهى بنا المطاف باستخدام آلة حاسبة بسيطة تبلغ 141 ميجابايت إكس ، فإن الميزة فاشلة (وأعتقد أن التكلفة الحقيقية هي 141 ميجابايت * 2 ، لأنها ستستخرج الأشياء في مكان ما بشكل صحيح)

نعم ، هذا بالتأكيد ما أريده. لا يزال أصغر من النشر العادي المستقل.

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

أوه هذا ما تريده؟ سيئة ، لم أكن أعرف أن التطبيق المتضخم كان شائعًا

لا تحتاج الآلة الحاسبة إلى JIT ، ولا حتى الانعكاس ، ولكن بما أن هذا ما تريده ، أعتقد أنني مخطئ منذ البداية ، يجب أن أتوقف عن البرمجة

RUSshy إنه ليس أكثر قائم بذاته ، أليس كذلك؟

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

لست متأكدًا من أن هذا هو ما يريده الناس ، إذا انتهى بنا المطاف باستخدام آلة حاسبة بسيطة تبلغ 141 ميجابايت إكس ، فإن الميزة فاشلة (وأعتقد أن التكلفة الحقيقية هي 141 ميجابايت * 2 ، لأنها ستستخرج الأشياء في مكان ما بشكل صحيح)

يقوم باستخراج الملفات الموجودة في C: Users [YourUserName] AppDataLocalTemp.net

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

eiva أي نظام تشغيل كان هذا؟ هل كانت AWS lambda؟
https://github.com/dotnet/core-setup/issues/7940 المسارات التي تعمل على إصلاح هذه المشكلة.

في غضون ذلك ، يمكنك تعيين متغير البيئة DOTNET_BUNDLE_EXTRACT_BASE_DIR للتحكم في مكان استخراج الملفات المجمعة.

@ swaroop-sridhar شكرا على الرد!
إنه centos.7 الذي يتم تشغيل التطبيق من حساب الخدمة "المقيدة".

@ jnm2 أقدر أنك تحب C # ، وأنا كذلك. لكن لنكن صادقين ، من الجنون أن تبلغ مساحة الآلة الحاسبة 128 ميغا بايت.

TechnikEmpire أشعر أنه من الضروري أن أشير إلى أن "أنا أحب C #" هو تخفيض مكثف جدًا لما قلته أعلاه: D

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