Fable: خطوات لدعم ملف المشروع الذي يستهدف إطار عمل. net كامل؟

أنا آسف لكنني لن أتمكن من تخصيص أي وقت لهذا ، إذا كان أي شخص مهتمًا بـ Fable 1.0 يدعم تنسيق المشروع القديم ، فسيتعين عليه العمل على هذه الميزة بأنفسهم. من الصعب بالفعل جعل Fable يعمل مع المجموعة الحالية من الأدوات ونحن فريق صغير جدًا لتغطية العديد من السيناريوهات. في الوقت الحالي ، يعد VS for Windows هو المحرر الوحيد الذي لم يدعم ملف .fsproj الجديد حتى الآن ، وسوف يتم قريبًا. لا أعتقد أن تخصيص موارد التطوير لدعم التنسيق القديم يستحق الجهد 😕

تحليل ملف المشروع القديم (تم بالفعل في v0.7.x)

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

استخدم باكيت

AFAIK ، Paket مع المشروع القديم يعمل عن طريق حقن الكثير من العناصر الشرطية في ملف fsproj. ، وليس بالملف .fsproj.references الذي نستخدمه الآن. سيتعين علينا التفاعل مع Paket بطريقة مختلفة تمامًا.

انشر Fable.Tools كحزمة nuget حيث يكون البرنامج الخفي هو تطبيق وحدة تحكم في دليل الأدوات

لم أستخدم هذا مطلقًا ، لذا لست متأكدًا من كيفية عمله.

أعتقد أنني ارتكبت "المشكلة" الخاطئة هنا ، كان ينبغي أن يكون هذا سؤالًا: ابتسم:

كان لدي بعض التفكير في سير عمل مختلف وأردت أن أجربه بمفردي ولكني لم أكن متأكدًا مما هو مطلوب لكي يعمل هذا من الناحية النظرية.

هل صحيح أن حزم nuget المنشورة بـ dotnet pack لا يمكن استخدامها في net45؟

هل صحيح أن حزم nuget المنشورة مع حزمة dotnet لا يمكن استخدامها في net45؟

لا ، يمكنك استهداف net45 كأحد أهدافك.

ctaggart نيس ، من الجيد معرفة ذلك. شكرا لك!

@ Zaid-Ajaj بينما sdk الجديد (fsproj الجديد المستخدم في الخرافة) يعمل بنفس الطريقة في mono / msbuild.exe / dotnet cli (من fsharp.net.sdk> = 1.0.3 ، لم يتم دعمه بعد في VS 2017.
لذا يمكنك استهداف net45 (يمكنك استهداف أهداف متعددة في نفس fsproj ، باستخدام sdk جديد راجع للشغل) ، لكنها لا تعمل في VS على أي حال. ليس جوهر صافي ، القضية ، هو sdk وتنسيق المشروع الجديد.
قديم sdk كمشكلة أكثر بكثير في الدعم عبر النظام الأساسي وهو أمر مؤلم للقائمين على الصيانة (فقط اقرأ معلومات المشروع يمثل ألمًا ولديه مشكلات ، كما قال

في خارطة طريق VF # ، التاريخ المتوقع هو تحديث يوليو ، عندما يدعم VS 2017 sdk الجديد في Visual F #.

لذا بدلاً من القيام بالكثير من العمل لدعم sdk القديم (الألم للحفاظ على تطبيقين) الذي أصبح قديمًا قريبًا ، من الأفضل أن تنتظر ihmo قليلاً (دعم الصراف الآلي المتقاطع مع الخرافة والمحررين مثل vscode / vsonmac رائع) حتى يوليو وقم فقط بتحسين VS بـ net4* لاحقًا ، باستخدام sdk الجديد

لذلك في النهاية ، سيكون وقت تشغيل msbuild .net (mono / vs / netcore) أقل أهمية (thx إلى sdk الجديد) ، وربما سيكون شفافًا للمستخدمين (بالتأكيد لمستخدمي Windows) ، ولكن أجهزة الصراف الآلي بدون دعم VS ، غير مجدية لقضاء الوقت ihmo ، لأن الخبرة (للمستخدمين) تحتاج إلى صقلها ويجب التقليل من الصيانة (لفريق الخرافة).
سيساعدك sdk الجديد ، ولكنه يحتاج إلى مزيد من الوقت. قديم sdk هو بالوعة الوقت ، الذي أصبح عفا عليه الزمن على أي حال في عالم. net.

enricosada السبب الرئيسي الذي كنت أفكر فيه في القيام بذلك ، هو تبسيط تجربة البدء للوافدين الجدد. مما يسهل على الأشخاص استخدام ما لديهم الآن (الإصدار 2015 أو أقل) للتلاعب بالخرافة. أنا أستخدم vs code الآن مع dotnet core وهذا يعمل بشكل جيد. ولكن كان هذا بعد سلسلة من المحاولات المحبطة لتشغيله في المقام الأول على جهازي. لم أتمكن حتى من تثبيت VS2017 على جهازي وهذا سبب آخر جعلني أفكر في هذا الأمر.

ومع ذلك ، بعد قراءة ملاحظاتك ، يجب أن أوافق على أن تركيز موارد التطوير على sdk الجديد أفضل وأن الانتظار قليلاً يستحق ذلك.

شكرا مرة أخرى على وقتك في هذا.