Приховані особливості ASP.NET [закрито]

Це питання існує тому, що воно має історичне значення, але воно не вважається хорошим актуальним питанням для цього веб-сайту, тому, будь ласка, не використовуйте його як доказ того, що ви можете задавати подібні запитання тут.

Більше інформації: https://stackoverflow.com/faq

Завжди є функції, які були б корисні у сценаріях бахроми, але саме тому більшість людей їх не знає. Я прошу особливості, які зазвичай не викладаються підручниками.

Які ви знаєте?

Під час тестування ви можете надсилати електронні листи в папку на комп'ютері замість SMTP-сервера. Помістіть це у свій web.config:

<system.net>
    <mailSettings>
        <smtp deliveryMethod="SpecifiedPickupDirectory">
            <specifiedPickupDirectory pickupDirectoryLocation="c:\Temp\" />
        </smtp>
    </mailSettings>
</system.net>

Якщо ви помістите файл з іменем app_offline.htm у корінь каталогу веб-додатків, ASP.NET 2.0+ вимкне програму та припинить нормальну обробку будь-яких нових вхідних запитів для цього додатка, показуючи лише вміст app_offline.htm файл для всіх нових запитів .

Це найшвидший і найпростіший спосіб відобразити повідомлення "Сайт тимчасово недоступний" під час повторного розгортання (або відкочування) змін на виробничому сервері.

Також, як зазначає marksidad , переконайтеся, що у вас є принаймні 512 байт вмісту у файлі, щоб IE6 візуалізував його правильно.

throw new HttpException(404, "Article not found");

Це підхопить ASP.NET, який поверне сторінку customErrors. Про це дізналися в нещодавній .NET Повідомленні дня

Ось найкращий. Додайте це до свого web.config для МНОГО швидшої компіляції. Це повідомлення 3.5SP1 через цей QFE .

<compilation optimizeCompilations="true">

Короткий підсумок: ми вводимо новий перемикач optimizeCompilations в ASP.NET, який може значно підвищити швидкість компіляції в деяких сценаріях. Існує декілька уловів, тому читайте детальніше. Зараз цей перемикач доступний як QFE для 3.5SP1 і буде частиною VS 2010.

Система компіляції ASP.NET застосовує дуже консервативний підхід, який змушує її знищити будь-яку попередню роботу, яку вона робила будь-коли, коли змінився файл "верхнього рівня". Файли "верхнього рівня" включають все, що стосується біна та App_Code, а також global.asax. Хоча це працює добре для невеликих додатків, він стає майже непридатним для дуже великих додатків. Наприклад, замовник зіткнувся з випадком, коли для оновлення сторінки знадобилося 10 хвилин після внесення змін до збірки "бін".

Щоб полегшити біль, ми додали «оптимізований» режим компіляції, який використовує набагато менш консервативний підхід до перекомпіляції.

Через тут :

• HttpContext.Current завжди надасть вам доступ до запиту / відповіді поточного контексту тощо тощо, навіть якщо ви не маєте доступу до властивостей сторінки (наприклад, із слабко пов'язаного допоміжного класу).

• Ви можете продовжити виконання коду на одній сторінці після перенаправлення користувача на іншу, зателефонувавши на Response.Redirect ( URL , false )

• Вам не потрібні файли .ASPX, якщо все, що вам потрібно, - це складена сторінка (або будь-який IHttpHandler ). Просто встановіть шлях та методи HTTP, щоб вказати на клас у <httpHandlers>елементі файлу web.config.

• Сторінка об'єкт може бути витягнутий з .aspx файлу програмного шляхом виклику PageParser.GetCompiledPageInstance (віртуальний_путь, aspxFileName, Context)

Режим роздрібної торгівлі на рівні machine.config:

<configuration>
  <system.web>
    <deployment retail="true"/>
  </system.web>
</configuration>

Переорієнтовує налаштування web.config, щоб застосувати налагодження до помилкового, вмикає власні помилки та відключає трасування. Більше не забудьте змінити атрибути перед публікацією - просто залиште їх усі налаштовані для середовищ розробки або тестування та оновіть виробничі налаштування роздрібної торгівлі.

Увімкнення intellisense для MasterPages на сторінках із вмістом.
Я впевнений, що це дуже мало відомий хак

Більшу частину часу вам доводиться використовувати метод findcontrol і передавати елементи керування на головну сторінку зі сторінок вмісту, коли ви хочете їх використовувати, директива MasterType дозволить інтелігенції у візуальній студії після того, як ви перейдете до цього

просто додайте ще одну директиву на сторінку

<%@ MasterType VirtualPath="~/Masters/MyMainMasterPage.master" %>

Якщо ви не хочете використовувати Віртуальний шлях, а потім використовуйте ім'я класу

<%@ MasterType TypeName="MyMainMasterPage" %>

Повна стаття тут

HttpContext.Items як інструмент кешування на рівні запиту

У моїй голові виділяються дві речі:

1) Ви можете вмикати і вимикати Trace з коду:

#ifdef DEBUG 
   if (Context.Request.QueryString["DoTrace"] == "true")
                {
                    Trace.IsEnabled = true;
                    Trace.Write("Application:TraceStarted");
                }
#endif

2) Ви можете створити декілька сторінок .aspx, використовуючи лише один спільний "кодовий" файл.

Створіть один .cs-файл класу:

public class Class1:System.Web.UI.Page
    {
        public TextBox tbLogin;

        protected void Page_Load(object sender, EventArgs e)
        {

          if (tbLogin!=null)
            tbLogin.Text = "Hello World";
        }
    }

і тоді ви можете мати будь-яку кількість сторінок .aspx (після видалення .designer.cs та .cs-коду, за якими генерується VS):

  <%@ Page Language="C#"  AutoEventWireup="true"  Inherits="Namespace.Class1" %>
     <form id="form1" runat="server">
     <div>
     <asp:TextBox  ID="tbLogin" runat="server"></asp: TextBox  >
     </div>
     </form>

Ви можете мати елементи керування в ASPX, які не відображаються в Class1, і навпаки, але вам потрібно повторно проаналізувати, щоб перевірити ваші елементи керування на нулі.

Ви можете використовувати:

 Request.Params[Control.UniqueId] 

Щоб отримати значення елемента контролю, перед тим, як ініціалізувати перегляд, перегляд стану (Control.Text тощо буде порожнім у цій точці).

Це корисно для коду в Init.

WebMethods.

Ви можете використовувати зворотні виклики ASP.NET AJAX до веб-методів, розміщених на сторінках ASPX. Ви можете прикрасити статичний метод атрибутами [WebMethod ()] та [ScriptMethod ()]. Наприклад:

[System.Web.Services.WebMethod()] 
[System.Web.Script.Services.ScriptMethod()] 
public static List<string> GetFruitBeginingWith(string letter)
{
    List<string> products = new List<string>() 
    { 
        "Apple", "Banana", "Blackberry", "Blueberries", "Orange", "Mango", "Melon", "Peach"
    };

    return products.Where(p => p.StartsWith(letter)).ToList();
}

Тепер на своїй сторінці ASPX ви можете зробити це:

<form id="form1" runat="server">
    <div>
        <asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="true" />
        <input type="button" value="Get Fruit" onclick="GetFruit('B')" />
    </div>
</form>

І зателефонуйте на сторону вашого сервера методом JavaScript, використовуючи:

    <script type="text/javascript">
    function GetFruit(l)
    {
        PageMethods.GetFruitBeginingWith(l, OnGetFruitComplete);
    }

    function OnGetFruitComplete(result)
    {
        alert("You got fruit: " + result);
    }
</script>

Перевірте, чи клієнт все ще підключений, перш ніж розпочати тривале завдання:

if (this.Response.IsClientConnected)
{
  // long-running task
}

Однією з маловідомих і рідко використовуваних властивостей ASP.NET є:

Картографування тегів

Він рідко використовується, тому що там є лише конкретна ситуація, коли вам це потрібно, але коли це потрібно, це так зручно.

Деякі статті про цю маловідому функцію:

Картографування тегів у ASP.NET
Використання картографування тегів у ASP.NET 2.0

і з цієї останньої статті:

Відображення тегів дозволяє міняти сумісні елементи керування під час компіляції на кожній сторінці веб-програми. Корисний приклад - якщо у вас є запас ASP.NET управління, наприклад, DropDownList, і ви хочете замінити його на індивідуальне управління, яке походить від DropDownList. Це може бути елемент керування, налаштований для забезпечення більш оптимізованого кешування даних пошуку. Замість редагування кожної веб-форми та заміни вбудованих DropDownLists на вашу власну версію, ви можете мати ASP.NET по суті зробити це для вас, змінивши web.config:

<pages>
 <tagMapping>
   <clear />
   <add tagType="System.Web.UI.WebControls.DropDownList"
        mappedTagType="SmartDropDown"/>
  </tagMapping>
</pages>

Модули Http . Архітектура шалено елегантна. Можливо, не прихована функція, але все-таки крута.

Ви можете використовувати коментарі ASP.NET на сторінці .aspx, щоб коментувати всі частини сторінки, включаючи елементи керування сервером. І вміст, який коментується, ніколи не надсилатиметься клієнту.

<%--
    <div>
        <asp:Button runat="server" id="btnOne"/>
    </div>
--%>

Конструктор виразів коду

Зразок розмітки:

Text = '<%$ Code: GetText() %>'
Text = '<%$ Code: MyStaticClass.MyStaticProperty %>'
Text = '<%$ Code: DateTime.Now.ToShortDateString() %>'
MaxLenth = '<%$ Code: 30 + 40 %>'

Справжня краса конструктора виразів коду полягає в тому, що ви можете використовувати прив'язку даних, як вирази, у ситуаціях, що не пов’язують дані. Ви також можете створити інші конструктори виразів, які виконують інші функції.

web.config:

<system.web>    
    <compilation debug="true">
        <expressionBuilders>
            <add expressionPrefix="Code" type="CodeExpressionBuilder" />

Клас cs, завдяки якому все відбувається:

[ExpressionPrefix("Code")]
public class CodeExpressionBuilder : ExpressionBuilder
{
    public override CodeExpression GetCodeExpression(
        BoundPropertyEntry entry,
        object parsedData,
        ExpressionBuilderContext context)
    {            
        return new CodeSnippetExpression(entry.Expression);
    }
} 

Використання типу файлу ASHX:
Якщо ви хочете просто вивести якийсь основний HTML або XML, не проходячи через обробники подій сторінки, ви можете реалізувати HttpModule простим способом

Назвіть сторінку як SomeHandlerPage.ashx і просто введіть в неї код нижче (лише один рядок)

<%@ webhandler language="C#" class="MyNamespace.MyHandler" %>

Потім файл коду

using System;
using System.IO;
using System.Web;

namespace MyNamespace
{
    public class MyHandler: IHttpHandler
    {
        public void ProcessRequest (HttpContext context)
        {   
            context.Response.ContentType = "text/xml";
            string myString = SomeLibrary.SomeClass.SomeMethod();
            context.Response.Write(myString);
        }

        public bool IsReusable
        {
            get { return true; }
        }
    }
}

Налаштування управління властивостями на основі сервера на цільовий браузера і більш .

<asp:Label runat="server" ID="labelText" 
    ie:Text="This is IE text" 
    mozilla:Text="This is Firefox text" 
    Text="This is general text" 
/>

Цей вид мене зненацька прийняв.

System.Web.VirtualPathUtility

Я працював над додатком asp.net, який пройшов аудит безпеки провідною охоронною компанією, і я дізнався цей простий трюк, щоб запобігти менш відомій, але важливій вразливості безпеки.

Нижче пояснення: http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Guidelines_-_Parameter_Manipulation#Consider_Using_Page.ViewStateUserKey_to_Counter_One-Click_Attacks

Подумайте про використання Page.ViewStateUserKey для протидії атакам одним клацанням. Якщо ви автентифікуєте своїх абонентів і використовуєте ViewState, встановіть властивість Page.ViewStateUserKey в обробнику подій Page_Init, щоб запобігти атакам одним кліком.

void Page_Init (object sender, EventArgs e) {
  ViewStateUserKey = Session.SessionID;
}

Встановіть для властивості значення, яке ви знаєте, унікальне для кожного користувача, наприклад, ідентифікатор сесії, ім’я користувача або ідентифікатор користувача.

Атака одним клацанням миші виникає, коли зловмисник створює веб-сторінку (.htm або .aspx), яка містить приховане поле форми під назвою __VIEWSTATE, яке вже заповнене даними ViewState. ViewState може бути створений зі сторінки, яку зловмисник раніше створив, наприклад сторінки кошика зі 100 предметами. Зловмисник заманює нічого не підозрюючого користувача переглядати сторінку, а потім зловмисник призводить до того, що сторінка буде надіслана серверу, де ViewState є дійсним. Сервер не може знати, що ViewState походить від зловмисника. Перевірка ViewState та HMAC не протидіють цій атаці, оскільки ViewState є дійсним, а сторінка виконується в контексті безпеки користувача.

Встановлюючи властивість ViewStateUserKey, коли зловмисник переходить на сторінку для створення ViewState, властивість ініціалізується на його ім’я. Коли законний користувач подає сторінку на сервер, вона ініціалізується з ім'ям зловмисника. Як результат, перевірка HSM ViewState виходить з ладу і створюється виняток.

HttpContext.Current.IsDebuggingEnabled

Це чудово для визначення, які сценарії виводити (мінімум або повні версії) або що-небудь інше, що ви можете захотіти в програмі dev, але не в прямому ефірі.

Входить у ASP.NET 3.5 SP1:

• customErrors тепер підтримує атрибут "redirectMode" зі значенням "ResponseRewrite". Показує сторінку помилок без зміни URL-адреси.
• Тег форми тепер розпізнає атрибут дії. Чудово підходить, коли ви використовуєте переписування URL-адрес

Властивість DefaultButton у панелях.

Він встановлює кнопку за замовчуванням для певної панелі.

У ScottGu є маса хитрощів на веб- сайті http://weblogs.asp.net/scottgu/archive/2006/04/03/441787.aspx

Використання configSource для розділення файлів конфігурації.

Ви можете використовувати атрибут configSource у файлі web.config, щоб перемістити елементи конфігурації до інших .config файлів, наприклад, замість:

    <appSettings>
        <add key="webServiceURL" value="https://some/ws.url" />
        <!-- some more keys -->
    </appSettings>

... Ви можете зберегти весь розділ Налаштування додатків в іншому файлі конфігурації. Ось нове web.config:

    <appSettings configSource="myAppSettings.config" />

myAppSettings.configфайл:

    <appSettings>        
        <add key="webServiceURL" value="https://some/ws.url" />
        <!-- some more keys -->
    </appSettings>

Це досить корисно для сценаріїв, коли ви розгортаєте програму для клієнта, і ви не хочете, щоб вони втручалися у сам файл web.config, і просто хочете, щоб вони могли змінити лише декілька налаштувань.

посилання: http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx

Атрибут MaintainScrollPositionOnPostback в директиві Page. Він використовується для підтримки позиції прокрутки сторінки aspx у поштових списках.

HttpContext.IsCustomErrorEnabled - це класна функція. Я вважав її корисною не раз. Ось короткий пост про це.

За замовчуванням будь-який вміст між тегами для спеціального елемента керування додається як дочірнє управління. Це може бути перехоплено в перезавантаженні AddParsedSubObject () для фільтрації або додаткового розбору (наприклад, текстового вмісту в LiteralControls):

    protected override void AddParsedSubObject(object obj)
     { var literal = obj as LiteralControl;
       if (literal != null) Controls.Add(parseControl(literal.Text));
       else base.AddParsedSubObject(obj);
     }

...

   <uc:MyControl runat='server'>
     ...this text is parsed as a LiteralControl...
  </uc:MyControl>

Якщо у вас ASP.NET генерує RSS-канал, іноді він додаватиме додатковий рядок у верхній частині сторінки. Це не підтверджується звичайними RSS-валідаторами. Ви можете обійти її, поставивши директиву сторінки <@Page>внизу сторінки.

До того, як ASP.NET v3.5 додав маршрути, ви можете створити власні дружні URL-адреси, просто написавши HTTPModule і перезаписавши запит на початку конвеєра сторінки (як подія BeginRequest).

Такі URL-адреси, як http: // ім'я сервера / сторінка / Param1 / SomeParams1 / Param2 / SomeParams2, будуть відображені на іншій сторінці, як нижче (часто використовуючи регулярні вирази).

HttpContext.RewritePath("PageHandler.aspx?Param1=SomeParms1&Param2=SomeParams2");

DotNetNuke має дійсно хороший HttpModule, який робить це для своїх дружніх URL-адрес. Досі корисний для машин, де ви не можете розгорнути .NET v3.5.