هل تريد توفير اسم تجميع صريح لمجلد App_Code الخاص بموقع ASP.NET المترجم ديناميكيًا؟

Question

في مشروع موقع ويب ASP.NET تم تجميعه ديناميكيًا، هل يمكن تسمية التجميع الخاص بمجلد App_Code بشكل صريح؟

على سبيل المثال، في ظل الظروف العادية عندما أقوم بتشغيل موقع ويب ASP.NET، يتم إنشاء اسم التجميع في ملف Temporary ASP.NET Files\ المجلد عشوائي جزئيًا مثل App_Code.neizakfo.dll أين com.neizakfo هو الجزء الذي يمكن أن يختلف.هل يمكنني تقديم اسم صريح للتجميع مثل App_Code_Web1.dll?

إيضاح

وفقًا لمتطلبات العمل، لا يمكن تجميع/نشر موقع الويب مسبقًا.لذلك أبحث عن حل في سياق Temporary ASP.NET Files المجلد والتجمعات المترجمة ديناميكيًا كما هو مذكور أعلاه.

---

خلفية:
لقد صادفني هذا السؤال أثناء البحث عن طريقة لإجراء إنشاء مثيل للنوع الديناميكي على فئة في مجلد App_Code لموقع ويب باستخدام اسم مؤهل للتجميع مخزّن في التكوين، ولكن تم إنشاء مثيل له من صفحة الويب، وبالتالي عبور حدود التجميع.نظرًا لأنه يتم تجميع صفحة الويب والتعليمات البرمجية app_code في مجموعتين مختلفتين بشكل افتراضي، فإن السلوك الافتراضي لأسلوب Type.GetType(..) للبحث عن اسم النوع إما في التجميع التنفيذي الحالي (صفحة الويب) أو في mscorlib لا يحدث يكفي اختيار أي نوع من مجموعة App_Code.نظرًا لكونه عشوائيًا، فإن اسم تجميع app_code غير معروف بالنسبة لي لتضمينه في السلسلة المؤهلة للتجميع.

يمكنني وضع نوع البيانات في مكتبة فصل دراسي (لأنه يحتوي على اسم محدد مسبقًا/دقيق) للتخلص من هذه المشكلة، ومع ذلك أود معرفة كيفية القيام بذلك داخل موقع الويب نفسه دون إنشاء مشروع مكتبة فصل دراسي لـ الغرض.

Answer 1

يمكنك القيام بذلك نوعًا ما في مشروع موقع ويب.

هناك مقالة MSDN حول استخدام علامة -fixednames عند تجميع المشروع.

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

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

وأخيرًا، يمكنك تعداد كافة ملفات dll الموجودة في دليل bin، والبحث في كل منها عن النوع الذي تبحث عنه.نظرًا لأن هذا مكلف إلى حد ما، قم بذلك مرة واحدة، واحتفظ بالنتيجة مؤقتًا في مكان ما حتى لا تستمر في القيام بذلك في كل مرة تبحث فيها عن هذا النوع.ربما هذا هو الحل الأسوأ.

يعد هذا أمرًا تافهًا للقيام به في مشروع WebApplication، لكنني أفترض أنك عالق في مشروع WebSite؟

يحرر: كتحديث للتعليقات؛إذا استخدمت أداة Publish Web Tool، فسيتم نقل كل التعليمات البرمجية الموجودة في app_code إلى دليل bin في ملف dll يسمى App_Code.dll - لا يتغير هذا السلوك حتى إذا استخدمت تسمية ثابتة (تؤثر جميع الأسماء الثابتة على تسمية ملفات dll لـ كل صفحة، تحكم المستخدم).إذا كنت تستخدم ILSpy في هذا الملف، أستطيع أن أرى فصولي هناك.لذا فأنا أعرف اسم التجميع وموقعه - ويجب أن أكون قادرًا على الوصول إلى الأنواع الموجودة به بأقل جهد.أتساءل لماذا أرى سلوكًا مختلفًا عنك!

لقد أنشأت فئة بسيطة تسمى "الشخص" بمعرف واسم، ووضعتها في App_Code، وقمت بتجميع الموقع، ثم قمت بتشغيل الكود التالي:

  Type myType = Assembly.LoadFrom(Server.MapPath("~/bin/App_Code.dll")).GetType("Person", true);
  Response.Write(myType.ToString());

لقد كتب "شخص"، كما هو متوقع.

مزيد من التحرير

يسقط البنس!إذا قمت بعد ذلك:

  object myObject= Activator.CreateInstance("App_Code.dll", "Person");

وحاول إرسال myObject إلى شخص ما، أحصل على الرسالة التالية:

The type 'Person' exists in both 'App_Code.dll' and 'App_Code.jydjsaaa.dll'

لذا فقد حان الوقت لتكون مخادعًا.

في Global.asax، على Application_OnStart، قم بما يلي:

Application["App_Code_Assembly"] = Assembly.GetAssembly(typeof(Person));

في صفحتي الافتراضية للاختبار، قمت بعد ذلك بما يلي:

  Assembly app_Code = Application["App_Code_Assembly"] as Assembly;
  Response.Write(app_Code.FullName);

مما أعطاني رمز التطبيق المسمى عشوائيًا والذي يعمل به بالفعل في ملفات ASP.Net المؤقتة.

ولهذا السبب أكره مشاريع مواقع الويب ;-)