visual-studio - موقع ويب ASP.NET أو تطبيق ويب ASP.NET؟




projects-and-solutions (21)

عند بدء تشغيل مشروع ASP.NET جديد في Visual Studio ، يمكنني إنشاء تطبيق ويب ASP.NET أو يمكنني إنشاء موقع ويب ASP.NET.

ما هو الفرق بين تطبيق ASP.NET على ويب و ASP.NET Web Site؟ لماذا اخترت واحدة على أخرى؟

هل تختلف الإجابة استنادًا إلى إصدار Visual Studio الذي أستخدمه؟


Answers

يحتوي "موقع ويب" على التعليمات البرمجية الخاصة به في دليل App_Code خاص ويتم تجميعها في العديد من DLLs (التجميعات) في وقت التشغيل. يتم "ترجمة تطبيق ويب" إلى واحد DLL واحد.


موقع الكتروني:

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

إذا لم يُطلب من Visual Studio إعادة استخدام نفس الأسماء باستمرار ، فسيظهر بأسماء جديدة لملفات DLL التي يتم إنشاؤها بواسطة الصفحات طوال الوقت. يمكن أن يؤدي ذلك إلى وجود عدة نسخ قريبة من ملفات DLL تحتوي على نفس اسم الفئة ، مما يؤدي إلى توليد الكثير من الأخطاء. تم تقديم مشروع موقع ويب مع Visual Studio 2005 ، ولكن تبين أنه لا يحظى بشعبية كبيرة.

تطبيق الويب:

تم إنشاء "مشروع تطبيق ويب " كوظيفة إضافية وهو موجود الآن كجزء من SP 1 لـ Visual Studio 2005. الاختلافات الرئيسية هي تم تصميم "مشروع تطبيقات ويب" للعمل مشابهة لمشاريع ويب التي يتم شحنها مع Visual Studio 2003. سوف ترجمة التطبيق في ملف DLL واحد في وقت البناء. لتحديث المشروع يجب أن يتم recompiled وملف DLL نشر التغييرات تحدث.

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

Reference

المقالة ASP.NET 2.0 - موقع ويب مقابل مشروع تطبيق ويب أيضاً يعطي أسباب لماذا استخدام واحد وليس الآخر. هنا مقتطف من ذلك:

  • تحتاج إلى ترحيل تطبيقات Visual Studio .NET 2003 كبيرة إلى VS 2005؟ استخدام مشروع تطبيقات الويب.
  • تريد فتح وتحرير أي دليل كمشروع ويب دون إنشاء ملف مشروع؟ استخدام مشروع موقع الويب.
  • أنت في حاجة لإضافة خطوات ما قبل البناء وما بعد البناء أثناء التجميع؟ استخدام مشروع تطبيقات الويب.
  • تحتاج إلى بناء تطبيق ويب باستخدام مشاريع ويب متعددة؟ استخدام مشروع تطبيقات الويب.
  • تريد توليد تجميع واحد لكل صفحة؟ استخدام مشروع موقع الويب.
  • أنت تفضل التصنيف الديناميكي وتعمل على الصفحات بدون إنشاء موقع كامل على كل مشاهدة صفحة؟ استخدام مشروع موقع الويب.
  • أنت تفضل نموذج التعليمات البرمجية صفحة واحدة إلى نموذج التعليمات البرمجية خلف؟ استخدام مشروع موقع الويب.

تشرح مشاريع تطبيقات الويب مقابل مشاريع مواقع الويب (MSDN) الاختلافات بين مشاريع الويب ومشروعات تطبيقات الويب. أيضا ، فإنه يناقش التكوين المراد إجراؤها في Visual Studio.


Compilation أوﻻً ، ھﻧﺎك اﺧﺗﻼف ﻓﻲ اﻟﺗﺟﻣﯾﻊ. لم يتم ترجمة الموقع مسبقا على الخادم ، يتم تجميعه في الملف. قد تكون ميزة لأنه عندما تريد تغيير شيء ما في موقع الويب الخاص بك ، يمكنك فقط تنزيل ملف معين من الخادم ، وتغييره وتحميل هذا الملف مرة أخرى إلى الخادم وسيعمل كل شيء بشكل جيد. في تطبيق ويب لا يمكنك القيام بذلك لأن كل شيء تم تجميعه مسبقًا وينتهي بك الأمر مع dll واحد فقط. عندما تقوم بتغيير شيء ما في ملف واحد من مشروعك ، عليك إعادة تجميع كل شيء مرة أخرى. لذلك إذا كنت ترغب في الحصول على إمكانية تغيير بعض الملفات على موقع ويب الخادم هو الحل الأفضل لك. كما يسمح للعديد من المطورين بالعمل على موقع ويب واحد. على الجانب الآخر ، إذا كنت لا تريد أن تكون التعليمة البرمجية متوفرة على الخادم ، فعليك بدلاً من ذلك اختيار تطبيق ويب. يعد هذا الخيار أيضًا أفضل لاختبار الوحدة نظرًا لإنشاء ملف DLL واحد بعد نشر موقعك على الويب.

Project structure هناك أيضا اختلاف في هيكل المشروع. في تطبيق الويب لديك ملف مشروع تمامًا كما لو كنت تستخدمه في التطبيق العادي. في موقع الويب لا يوجد ملف مشروع تقليدي ، كل ما لديك هو ملف الحل. يتم تخزين جميع المراجع والإعدادات في ملف web.config. @Page directive هناك سمة مختلفة فيPage التوجيه للملف الذي يحتوي على فئة مرتبطة بهذه الصفحة. في تطبيق ويب هو معيار "CodeBehind" ، في موقع ويب تستخدم "CodeFile". يمكنك رؤية ذلك في الأمثلة أدناه:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

موقع الكتروني:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

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

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

ASP.NET MVC (Model View Controller) هو الخيار الأفضل و الافتراضي هو Web Application. على الرغم من أنه من الممكن استخدام MVC في موقع الويب إلا أنه غير مستحسن.

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


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

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

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

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

يمكن العثور على تحليل أكثر تفصيلاً في:


لتلخيص بعض الإجابات أعلاه:

المرونة ، هل يمكنك إجراء تغييرات مباشرة على صفحة الويب؟

الموقع على الإنترنت : ممكن. المؤيد: فوائد قصيرة الأجل. يخدع: خطر على المدى الطويل من الفوضى المشروع.

تطبيق الويب : Con: غير ممكن. تحرير صفحة ، أرشفة التغييرات إلى عنصر تحكم مصدر ، ثم إنشاء ونشر الموقع بأكمله. برو: الحفاظ على جودة المشروع.

قضايا التنمية

موقع ويب : بنية مشروع بسيطة بدون ملف .csproj. قد يكون .2 صفحات aspx نفس اسم الفئة دون تعارضات. اسم دليل المشروع عشوائي يؤدي إلى بناء أخطاء مثل لماذا يتعارض إطار .net مع الملف الخاص به ولماذا يتعارض إطار .net مع الملف الذي تم إنشاؤه . المؤيد: بسيط (بسيط). يخدع: غير منتظم.

تطبيق الويب : بنية مشروع مشابهة لمشروع WebForms ، مع ملف .csproj. يجب أن تكون أسماء الفئات لصفحات asp فريدة. برو: بسيطة (ذكية). الاشتراك: لا شيء ، لأن تطبيق الويب لا يزال بسيطًا.


بالتأكيد تطبيق ويب ، ملف DLL واحد وسهلة للحفاظ على. لكن موقع الويب أكثر مرونة ؛ يمكنك تحرير ملف aspx أثناء التنقل.


من اختبار MCTS الذاتي الاجتياح عدة التدريب 70-515 كتاب:

مع تطبيق الويب (مشروع) ،

  1. يمكنك إنشاء تطبيق MVC.
  2. يخزن Visual Studio قائمة الملفات في ملف مشروع (.csproj أو .vbproj) ، بدلاً من الاعتماد على بنية المجلد.
  3. لا يمكنك خلط Visual Basic و C #.
  4. لا يمكنك تحرير التعليمات البرمجية دون إيقاف جلسة تصحيح.
  5. يمكنك إنشاء التبعيات بين مشاريع الويب المتعددة.
  6. يجب أن تقوم بتجميع التطبيق قبل النشر ، مما يمنعك من اختبار صفحة إذا لم يتم ترجمة صفحة أخرى.
  7. ليس لديك لتخزين الكود المصدري على الخادم.
  8. يمكنك التحكم في اسم التجميع والإصدار.
  9. لا يمكنك تحرير ملفات فردية بعد النشر دون إعادة التركيب.

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

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


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

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

خطأ ووقت التشغيل مع هذا الخطأ:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

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


يعتمد ذلك على ما تقوم بتطويره.

سيتغير محتوى موقع الويب الخاص بالمحتوى بشكل متكرر ويكون موقع الويب أفضل لذلك.

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


موقع الويب هو ما تقوم بنشره على خادم ويب ASP.NET مثل IIS. مجرد حفنة من الملفات والمجلدات. لا يوجد شيء في موقع ويب يربطك بـ Visual Studio (لا يوجد ملف مشروع). يتم إنشاء التعليمات البرمجية وتجميع صفحات الويب (مثل .aspx و .ascx و .master) بشكل ديناميكي في وقت التشغيل ، ويتم الكشف عن التغييرات على هذه الملفات بواسطة الإطار وإعادة تجميعها تلقائيًا. يمكنك وضع التعليمات البرمجية التي تريد مشاركتها بين الصفحات الموجودة في المجلد App_Code الخاص ، أو يمكنك تجميعها مسبقًا ووضع التجميع في مجلد سلة المحذوفات.

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

App_Code vs Bin

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

CodeBehind

هذا الموضوع محدد لملفات .aspx و .ascx. هذا الموضوع ذو أهمية متناقصة في إطارات التطبيقات الجديدة مثل ASP.NET MVC و ASP.NET Web Pages التي لا تستخدم ملفات codebehind.

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

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

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

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

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

استوديو مرئي

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

ميزة أخرى لطيفة المقدمة في Visual Studio 2010 هو Web.config التحول . هذا أيضا غير متوفر في مواقع الويب. يعمل الآن مع مواقع الويب في VS 2013.

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

في مشروع MVC Web Application لديك أوامر ومربعات حوار إضافية للمهام الشائعة ، مثل 'Add View' ، 'Go To View' ، 'Add Controller' ، وما إلى ذلك. هذه ليست متوفرة في موقع MVC.

إذا كنت تستخدم IIS Express كخادم تطوير ، في مواقع الويب ، يمكنك إضافة أدلة ظاهرية. هذا الخيار غير متوفر في تطبيقات الويب.

NuGet Package Restore لا يعمل على مواقع الويب ، يجب عليك تثبيت الحزم المدرجة يدويًا على packages.config تعمل حزمة Restore الآن مع مواقع الويب التي تبدأ بـ NuGet 2.7


نعم تطبيق الويب أفضل بكثير من مواقع الويب ، لأن تطبيقات الويب تمنحنا الحرية:

  1. أن يكون لديك عدة مشاريع تحت مظلة واحدة وإنشاء تبعيات المشروع بين. على سبيل المثال ، بالنسبة للحواسيب الشخصية ، يمكننا المتابعة من خلال تطبيق الويب

    • بوابات الويب
    • وحدة تحكم الإعلام (لإرسال البريد الإلكتروني)
    • طبقة الأعمال
    • طبقة الوصول إلى البيانات
    • مدير استثناء
    • فائدة الخادم
    • خدمات WCF (الشائعة لكافة الأنظمة الأساسية)
    • قائمة الاغراض
  2. لتشغيل اختبارات الوحدة على التعليمة البرمجية الموجودة في ملفات الفئة المقترنة بصفحات ASP.NET

  3. للإشارة إلى الفصول التي ترتبط بالصفحات وعناصر تحكم المستخدم من الفئات المستقلة
  4. لإنشاء تجميع واحد للموقع بأكمله
  5. التحكم في اسم التجميع ورقم الإصدار الذي تم إنشاؤه للموقع
  6. لتجنب وضع شفرة المصدر على خادم الإنتاج. (يمكنك تجنب نشر التعليمات البرمجية المصدر إلى خادم IIS. في بعض السيناريوهات ، مثل بيئات الاستضافة المشتركة ، قد تشعر بالقلق بشأن الوصول غير المصرح به إلى التعليمات البرمجية المصدر على ملقم IIS. (بالنسبة لمشروع موقع ويب ، يمكنك تجنب هذا الخطر عن طريق قبل التحويل البرمجي على كمبيوتر تطوير ونشر التجميعات التي تم إنشاؤها بدلاً من التعليمات البرمجية المصدر ، ومع ذلك ، في هذه الحالة تفقد بعض فوائد تحديثات الموقع سهلة.)
  7. إصدار الأداء مع موقع الويب (قد يتطلب الطلب الأول إلى موقع الويب تجميع الموقع ، مما قد يؤدي إلى حدوث تأخير. وإذا كان موقع الويب يعمل على خادم IIS قصير في الذاكرة ، بما في ذلك الموقع بالكامل في التجميع المفرد قد يستخدم ذاكرة أكبر من العدد المطلوب من التجميعات المتعددة.)


الموقع والمشروع >> موقع الويب هما طريقتان مختلفتان لإنشاء تطبيق ASP.NET باستخدام استوديو مرئي. واحد هو مشروع وأخر هو بيئة المشروع. الاختلافات هي

  1. يتم تخزين ملف الحل في نفس الدليل كدليل الجذر في بيئة المشروع.
  2. تحتاج إلى إزالة الملفات الحل والمشروع قبل نشر في بيئة المشروع.
  3. يتم نشر الدليل الجذر الكامل في بيئة بلا مشروع.

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


نموذج مشروع تطبيقات الويب

  • يوفر نفس دلالات مشروع الويب كمشاريع Visual Studio .NET Web. يحتوي على ملف مشروع (هيكل يستند إلى ملفات المشروع). بناء النموذج - يتم تجميع جميع التعليمات البرمجية في المشروع في تجميع واحد. يدعم كل من IIS وخادم تطوير ASP.NET المدمج. يدعم جميع الميزات من Visual Studio 2005 (إعادة بيعها ، والأدوية ، وما إلى ذلك) ومن ASP.NET (الصفحات الرئيسية ، العضوية وتسجيل الدخول ، والتنقل في الموقع ، والموضوعات ، الخ). استخدام ملحقات ملقم FrontPage (FPSE) لم تعد متطلبًا.

نموذج مشروع موقع الويب

  • لا يوجد ملف مشروع (على أساس نظام الملفات).
  • نموذج تجميع جديد.
  • تجميع ديناميكي والعمل على الصفحات بدون إنشاء موقع كامل على كل عرض صفحة.
  • يدعم كل من IIS وخادم تطوير ASP.NET المدمج.
  • كل صفحة لديها التجمع الخاص بها.
  • نموذج كود غختلاف.

موقع الويب = الاستخدام عندما يتم إنشاء الموقع من قبل مصممي الغرافيك والمبرمجين فقط تحرير واحد أو صفحتين

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

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

(يتم العثور على بعض أخطاء التشفير في تطبيقات الويب في وقت الترجمة التي لم يتم العثور عليها في مواقع الويب حتى وقت التشغيل.)

تحذير: كتبت هذه الإجابة منذ سنوات عديدة ولم أستخدم Asp.net منذ ذلك الحين. أتوقع أن الأمور قد انتقلت الآن.


هو دائما يعتمد على متطلبات العميل. يشمل ASP.NET فقط الميزات المرنة التي يحتاجها المستخدم للأمان وسهولة صيانة التطبيق الخاص بك.

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

لكن ميزة وعيوب هذه التقنيات ASP.NET اثنين تأتي ما هو جيد.


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

ميزة التطبيق هي أنه لا يوجد إعادة تجميع وبالتالي ستكون أوقات البدء الأولية أسرع.


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


مواقع الويب - لن يتم إنشاء ملف الحل. إذا كنا نريد إنشاء مواقع الويب لا حاجة للاستوديو المرئي.

تطبيق الويب - سيتم إنشاء ملف الحل. إذا أردنا إنشاء تطبيق ويب يجب أن تحتاج إلى الاستوديو المرئي. سيقوم بإنشاء ملف .dll واحد في مجلد bin.


كانت لدي مشكلة مشابهة باستثناء أن مشكلتي كانت سخيفة - كان لديّ مثالين على خادم الويب المدمج الذي يعمل ضمن منفذين مختلفين وكان لدي مشروعي -> خصائص -> ويب -> "عنوان URL للبدء" يشير إلى منفذ ثابت ولكن لم يكن تطبيق الويب يعمل بالفعل تحت هذا المنفذ. لذلك تم إعادة توجيه المتصفح إلى "عنوان URL للبدء" الذي أشار إلى 1539 ولكن تم تشغيل نسخة الأكواد / debug تحت المنفذ 50803.

لقد قمت بتغيير خادم الويب المدمج لتعمل تحت منفذ ثابت وقمت بتعديل "عنوان URL للبدء" الخاص بي لاستخدام هذا المنفذ أيضًا. project -> properties -> web -> "Servers" section -> "استخدم Visual Studio Development Server" -> منفذ معين





asp.net .net visual-studio projects-and-solutions