این افزونه برای پشتیبانی از آپلود چندین فایل بهبود یافت.
- تغییرات انجام شده
- پروژه‌ی کامل برای بررسی
- تغییرات انجام شده
- پروژه‌ی کامل برای بررسی
با سلام و خسته نباشید. امید است این سری مطالب هم مانند مطالب MVC فراتر از مقالات و کتب موجود باشد.
سه سوال:
1- چطور می توان با Code First برخی از موارد ابتدایی ایجاد بانک مانند Collation و Compatibility Level و Schema و User و Role را به DBMS ارسال کرد.
2- اگر از پروایدرهای دیگر مثلا برای MySQL یا Oracle استفاده شود، آیا Code First قادر است بدون هیچ تغییری نسبت به SQL Server کد را به بانکهای دیگر نگاشت کند؟ در مورد بانک های NOSQL چطور؟
3- آیا اگر این پروژه Code First را در یک هاست اشتراکی Deploy کنیم و در آن هاست برنامه Start شود (مثلا یک پروژه MVC)، آیا پروژه قادر خواهد بود به طور خودکار بانک را تولید نماید و دیگر نخواهیم بصورت دستی بانک و یوزر را در کنترل پنل هاست تعریف کنیم.
سه سوال:
1- چطور می توان با Code First برخی از موارد ابتدایی ایجاد بانک مانند Collation و Compatibility Level و Schema و User و Role را به DBMS ارسال کرد.
2- اگر از پروایدرهای دیگر مثلا برای MySQL یا Oracle استفاده شود، آیا Code First قادر است بدون هیچ تغییری نسبت به SQL Server کد را به بانکهای دیگر نگاشت کند؟ در مورد بانک های NOSQL چطور؟
3- آیا اگر این پروژه Code First را در یک هاست اشتراکی Deploy کنیم و در آن هاست برنامه Start شود (مثلا یک پروژه MVC)، آیا پروژه قادر خواهد بود به طور خودکار بانک را تولید نماید و دیگر نخواهیم بصورت دستی بانک و یوزر را در کنترل پنل هاست تعریف کنیم.
Micro Frontend چیست؟
micro frontend یک الگوی معماری (architecture pattern) میباشد؛ جایی که یک front-end app، به چند app کوچکتر تقسیم میشود و هر کدام از آنها به صورت مستقل توسعه داده و تست می‌شوند. مفهومی شبیه به مایکروسرویس‌ها است؛ اما برای سورس کدهای یکپارچه‌ی سمت کلاینت.
چرا؟
خیلی سخت است که بخواهیم روی سورس کدهای یکپارچه سمت کلاینت تست نویسی، به‌روز رسانی و هم چنین نگهداری کنیم. این در حالی است که توانایی تیم را به منظور مستقل کار کردن بر روی بخش‌های مختلفی از app، محدود میکند. شکستن یک app یکپارچه به micro frontendهای کوچکتر و قابل مدیریت، این امکان را فراهم میسازد که چندین تیم، به صورت مستقل کار کنند و از فریم ورک‌های ترجیحی خود استفاده کنند.
چگونه؟
اساسا 3 راه برای ادغام کردن ماژول‌های micro frontend با container app وجود دارد.
1-Server integration
هر micro frontend در یک وب سرور احتمالا جداگانه هاست شدهاست که مسئول رندر کردن و خدمت دادن markupهای مربوطه میباشد. به محض دریافت درخواستی از سمت مرورگر، container app در خواست را برای markup، با برقراری تماس به سرور، برای micro frontend مربوطه انجام میدهد.
این یک روش ایده آل نمی‌باشد؛ به‌طوریکه چندین تماس به سرور برای رندر کردن محتوا در صفحه برقرار میشود و همچنین مستلزم پیاده سازی استراتژی cache، به منظور کاهش تاخیر است.
2-Compile time integration
container app دسترسی به کدهای micro frontendها را در طول توسعه و زمان کامپایل دارد. یکی از راه‌های انجام این روش این است که micro frontendها را به عنوان بسته‌های npm منتشر کنیم و سپس از آنها به عنوان یک وابستگی در container app استفاده کنیم.
در حالیکه راه اندازی و پیاده سازی، در این حالت ساده است، اما یک وابستگی محکم بین container app و micro frontend وجود دارد. هر زمانکه یک micro frontend بروزرسانی میشود، نیاز است که container app ، به منظور یکپارچه کردن بروز رسانی، دوباره استقرار یابد.
3-Run time integration
container app دسترسی به کدهای micro frontendها را زمانیکه در مرورگر اجرا می‌شوند، دارد. یکی از راه‌های انجام این روش، استفاده از پلاگین Module Federation مربوط به Webpack است که مراقب ساختن، در دسترس قرار دادن و استفاده از وابستگی‌ها در زمان اجرا میباشد (در ادامه، این حالت را با جزئیات بیشتری مورد بررسی قرار خواهیم داد).
در این حالت وابستگی بین container app و micro frontendها وجود ندارد و یکپارچگی در زمان اجرا اتفاق می‌افتد. هر micro frontend میتواند به صورت مستقل توسعه داده شود و استقرار یابد، بدون اینکه container app را دوباره استقرار دهیم.
در این حالت راه اندازی در مقایسه با compile-time integration پیچیده‌تر است.
Webpack Module Federation Plugin
پلاگین module federation در Webpack 5.0 معرفی شد که امکان توسعه appهای micro frontend را با بارگذاری پویای کدهای appهای micro frontend را در container app ، فراهم میسازد.
همچنین این امکان را فراهم میکند که dependency ها را بین remote appها و host app، به منظور جلوگیری از کدهای تکراری و کاهش دادن سایز build، به اشتراک بگذاریم.
در این مقاله ما یک مثال را بررسی خواهیم کرد که شامل دو micro frontend ساده میباشد و سپس آنها را در یک host app ادغام میکنیم.
ساختار نهایی به‌صورت زیر خواهد بود:
ایجاد کردن اولین Remote app
یک پوشه را به نام remote1 ایجاد کنید و سپس یک فایل را به نام package.json، در پوشه‌ی ایجاد شده، با دستور زیر ایجاد کنید.
npm init --yes
پوشه‌ی ایجاد شده را در code editor خود باز کنید (من از vs code استفاده می‌کنم) و سپس وابستگی‌های زیر را به فایل package.json اضافه کنید.
npm install html-webpack-plugin webpack webpack-cli webpack-dev-server --save
1) webpack/ webpack-CLI: برای استفاده از webpack و دستورات webpack CLI
2) html-webpack-plugin/webpack-devserver: سرور توسعه محلی با live reloading
و همچنین اسکریپت webpack serve را در بخش scripts، به منظور serve کردن application در مرورگر اضافه کنید.
اکنون فایل package.json شما همانند زیر میباشد:
{
"name": "remote1",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} <!DOCTYPE html>
<html>
<head>
<title>
Remote1(Localhost:7001)
</title>
</head>
<body>
<div id="dev-remote1"></div>
</body>
</html> در ادامه یک پوشه‌ی جدید را به نام src ایجاد کنید و دو فایل را با نام‌های index.js و startup.js در آن قرار دهید. در ادامه به این دو فایل برمیگردیم و کدهای لازم را در آن قرار میدهیم.
یک فایل جدید را به نام webpack.config.js در ریشه‌ی پروژه ایجاد میکنیم که در آن تنظیمات webpack را قرار میدهیم. در این فایل، دو پلاگین را به نام‌های Webpack و Module Federation، اضافه میکنیم.
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7001,
},
plugins: [
new ModuleFederationPlugin({
name: 'remote1',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp1': './src/startup',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; فایل remoteEntry.js شامل یک لیست از فایلهای در معرض قرار داده شده‌ی توسط remote app به همراه مسیر‌های آنها میباشد. از این فایل در زمان ادغام کردن remote app در host app استفاده میشود.
index.js نقطه‌ی ورودی remote app ما میباشد. به منظور جلوگیری از eager loading، کدهای startup را در یک js فایل جداگانه به نام startup.js قرار میدهیم. از این رو فایل index.js شامل فقط یک import میباشد.
import('./startup'); در درون فایل startup.js ، یک تابع به نام mount را export میکنیم. این تابع یک element را دریافت میکند؛ جائیکه قرار است خروجی app در آن قرار گیرد. در حالت development، خروجی در یک div نگهدارنده با شناسه dev-remote1 در فایل محلی index.html قرار میگیرد.
const mount = (el) => {
el.innerHTML = '<div>Remote 1 Content</div>';
};
if (process.env.NODE_ENV === 'development') {
const el = document.querySelector('#dev-remote1');
if (el) {
mount(el);
}
}
export { mount }; 
ایجاد کردن دومین Remote app
در اینجا نیز مراحل، دقیقا شبیه به ایجاد remote app قبلی میباشد. یک پوشه را به نام remote2 در کنار پوشه‌ی remote1 ایجاد کنید و یک فایل را به نام package.json، با وابستگی‌های معرفی شده ایجاد کنید و سپس دستور npm install را بزنید تا وابستگی‌ها نصب شوند.
{
"name": "remote2",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} سپس یک فایل را با نام index.html و با محتوای زیر، در پوشه‌ی public ایجاد کنید:
<!DOCTYPE html>
<html>
<head>
<title>
Remote2(Localhost:7002)
</title>
</head>
<body>
<div id="dev-remote2"></div>
</body>
</html> در ادامه یک فایل را با نام webpack.config.js در ریشه‌ی پروژه‌ی remote2 ایجاد کنید و محتوای زیر را در آن قرار دهید. مطمئن باشید که پورت اجرایی برنامه 7002 میباشد.
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7002,
},
plugins: [
new ModuleFederationPlugin({
name: 'remote2',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp2': './src/startup',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; فایل فایل index.js برای remote2
import('./startup'); فایل startup.js برای remote2
const mount = (el) => {
el.innerHTML = '<div>Remote 2 Content</div>';
};
if (process.env.NODE_ENV === 'development') {
const el = document.querySelector('#dev-remote2');
if (el) {
mount(el);
}
}
export { mount }; اکنون میتوانید با اجرای دستور npm start برنامه را بر روی پورت 7002 اجرا کنید . ( http://localhost:7002 )
ایجاد کردن Host app و یکپارچه کردن آن با Remote app ها
یک پوشه‌ی جدید را به نام container در کنار دو پوشه‌ی قبلی (remote1, remote2) ایجاد کنید. در پوشه‌ی ایجاد شده، یک فایل را به نام package.json ایجاد کنید و محتوای زیر را در آن قرار دهید و سپس دستور npm install را بزنید تا لیست وابستگی‌ها دریافت شود.
{
"name": "container",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "webpack serve"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"html-webpack-plugin": "^5.3.2",
"webpack": "^5.57.0",
"webpack-cli": "^4.8.0",
"webpack-dev-server": "^4.3.1"
}
} اکنون یک پوشه را به نام public، در ریشه‌ی پروژه ایجاد کنید و یک فایل را به نام index.html، در آن قرار دهید. در این فایل دو div نگهدارنده به منظور هاست کردن محتوا، از هر remote app قرار دارد.
<!DOCTYPE html>
<html>
<head>
<title>Host App (Localhost:7000)</title>
</head>
<body>
<div id="remote1-app"></div>
<div id="remote2-app"></div>
</body>
</html> یک فایل را با نام webpack.config.js، با تنظیمات زیر در ریشه‌ی پروژه قرار دهید. در اینجا پورت اجرایی برنامه، 7000 تعیین شدهاست:
const HtmlWebpackPlugin = require('html-webpack-plugin');
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
mode: 'development',
devServer: {
port: 7000,
},
plugins: [
new ModuleFederationPlugin({
name: 'container',
remotes: {
remote1: 'remote1@http://localhost:7001/remoteEntry.js',
remote2: 'remote2@http://localhost:7002/remoteEntry.js',
},
}),
new HtmlWebpackPlugin({
template: './public/index.html',
}),
],
}; 
دقیقا مثل remote app ها، در فایل index.js مربوط به import ، host app زیر را انجام میدهیم:
import('./startup'); import { mount as remote1Mount } from 'remote1/RemoteApp1';
import { mount as remote2Mount } from 'remote2/RemoteApp2';
remote1Mount(document.querySelector('#remote1-app'));
remote2Mount(document.querySelector('#remote2-app')); در ادامه جهت مشاهده خروجی، app میزبان را با دستور npm start اجرا میکنیم. اکنون شما میتوانید خروجی remote app ها را در host app ببینید. لازم به ذکر است که در هنگام اجرای دستور npm start برای host app ، هر دو remote app ایجاد شده باید در حالت اجرا باشند.
ملاحظات
Module federation در Webpack نسخه 5 به بالا، در دسترس قرار دارد. شما میتوانید وابستگی‌های بین remote app و host app را به اشتراک بگذارید. این کار را با اضافه کردن آنها به تنظیمات پلاگین module federation برای remote app و host app انجام دهید.
new ModuleFederationPlugin({
name: 'remote1',
filename: 'remoteEntry.js',
exposes: {
'./RemoteApp1': './src/startup',
},
shared:['react', 'react-dom']
}), ارتباط بین host و remote app میتواند از طریق callbackها انجام شود.
از ویژگی‌های جدید و البته جالب شیرپوینت 2013 امکان استفاده از Appها میباشد. برای شناخت بیشتر appها پیشنهاد می‌کنم به MSDN مراجعه کنید. در این پست قصد دارم مراحل استفاده از SharePoint Marketplace مایکروسافت را برای دریافت و نصب app در سرور شیرپوینت و طریقه پیکر بندی سروربیان کنم.
اگر برای بار اول بخواهید یک app را روی سرور شیرپوینت نصب کنید ممکن است این پیغام به شما نمایش داده شود :
Sorry, apps are turned off. If you know who tuns the server, tell them to enable apps.
دقت کنید که کم رنگ بودن آیکون App به معنی عدم پشتیبانی در سرور شیرپوینت شما است و در صورت تلاش برای نصب آن این پیغام را خواهید دید :
دلیل این پیغام ( apps are turned off) تنظیم نبودن سرور شیرپوینت (Front-End) برای پشتیبانی و میزبانی از Appها میباشد . برای استفاده از appها در شیرپوینت نیازمند یک sub-domain و دیگر تنظیمات هستید تا بتوانید از appها استفاده کنید . برای این منظور مراحل زیر را پی بگیرید :
وارد سایت Office Store مایکروسافت شده و app مورد نظر خود را بیابید . در اینجا من از appهای رایگان1 مورد را انتخاب می‌کنم و با آن شروع می‌کنم : نمایش وضعیت آب و هوا در شیرپوینت .
روی Add کلیک کنید تا جزییات app و شناسه آن نمایش داده شود . سپس آن شناسه را کپی کنید : ( شناسه app مذکور WA103062091 است )
در اینجا یک بار مراحل را برای نصب app تا رسیدن به خطا پیگیری میکنیم. سپس راه حل آن بیان میشود. توجه داشته باشید که باید پس از رفع مشکل ، مراحل این قسمت از نصب app مجدد انجام شوند .
وارد سایت شده و روی آیکون چرخدنده (تنظیمات) کلیک کنید :
در پنجره باز شده شناسه app را paste کنید و جستجو را آغاز کنید :
باید در نتیجه جستجو نمایش داده شود که app در SharePoint Store یافت شد
روی لینک کلیک کنید تا نتیجه جستجو در Store نمایش داده شود :
توجه داشته باشید که در صفحه باز شده حتما یک واحد پولی و یک زبان را انتخاب نمایید .
ودر این مرحله خطای مذکور که گفته شد نمایش داده میشود :
حال به بیان راه حل می‌پردازیم :
برای استفاده از Appها در شیرپوینت باید سرویس‌های مرتبط و زیر دامنه (CNAME) سرور مرتبط برای آن تنظیم شده باشد .
برای این منظور ابتدا تنظیمات DNS را انجام میدهیم :
برای دامنه جاری یک CNAME تعریف کنید :
Alias Name پنجره فوق به این معنا است که تمام appها در مسیری با فرمت زیر مدیریت می‌شوند :
AppID.app.vm-seifollahi.iri
اگر به جای *.app فقط * قرار دهید ، هر شناسه app به عنوان زیر دامنه آدرس دهی میشود که در کل تفاوتی ندارد و برای مشخص شدن بهتر این کار را انجام دادم .
برای چک کردن صحت تنظیمات خود روی مسیری مانند Apps-12345678ABCDEF.app.vm-seifollahi.iri دستور ping را اجرا نمایید.
پس از تایید این تنظیمات باید وارد CA شوید و سرویس‌ها را تنظیم کنید : باید دو سرویس App Management Service و Subscription Setting Service در وضعیت Started باشند .
پس از چک کردن سرویس‌ها باید تنظیمات مربوط به App Poolهای IIS و دیتابیس برای App Managemetn Service و Subscription Service تنظیم شود . برای این منظور از Power Shell کمک می‌گیریم و دستورات زیر را در آن اجرا میکنیم (توضیحات در کامنت‌ها وجود دارند ) :
$account = Get-SPManagedAccount "vmseifollahi\administrator"
# Gets the name of the managed account and sets it to the variable $account for later use.
$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
# Creates an application pool for the Subscription Settings service application.
# Uses a managed account as the security account for the application pool.
# Stores the application pool as a variable for later use.
$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
# Creates an application pool for the Application Management service application.
# Uses a managed account as the security account for the application pool.
# Stores the application pool as a variable for later use.
$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName MBS_SettingsServiceDB
# Creates the Subscription Settings service application, using the variable to associate it with the application pool that was created earlier.
# Stores the new service application as a variable for later use.
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc
# Creates a proxy for the Subscription Settings service application.
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName MBS_AppServiceDB
# Creates the Application Management service application, using the variable to associate it with the application pool that was created earlier.
# Stores the new service application as a variable for later use.
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc
# Creates a proxy for the Application Management service application.
پس از نصب مشاهده میکنید که دیتابیس‌ها با موفقیت نصب شدند :
حال به CA رفته ( DOMAIN/_admin/ServiceApplications.aspx ) و از Start بودن سرویس‌های تنظیم شده اطمینان پیدا کنید : (از همین صفحه نیز میتوانید تنظیماتی که قبلا در power shell انجام شد را انجام دهید)
حال در CA به صفحه Apps می‌رویم :
و روی Configure App URL کلیک کنید :
در صورتی که پیغام زیر را مشاهده کردید ، IIS را باز کنید :
در قسمت Application Pools به دنبال SharePoint Web Service Root بگردید و آن را Start نمایید :
حال صفحه تنظیمات باز میشود . مقادیر domain و prefix را تنظیم کنید :
سپس روی OK کلیک کنید در این مرحله تنظیمات سرور شیرپوینت تمام شد و باید به ترتیب زیر آنها را restart کنید :
ابتدا SharePoint Timer service را Stop کنید.
سپس سرویس IIS را Restart کنید
حال SharePoint Timer service را Start کنید .
اکنون مراحل را مجدد از سر بگیرید یعنی روی منوی تنظیمات سایت و روی add App کلیک کنید و app را جستجو کنید و مراحل نصب را اجرا کنید تا به مرحله Add کردن app برسید . حال مشاهده میکنید که دکمه فعال بوده و میتوانید آن را نصب کنید :
پس از کلیک روی add به store preview منتقل خواهید شد : (این تصویر مربوط به محصولی دیگر است)
ممکن است پس از زدن دکمه continue خطایی مانند تصویر زیر را مشاهده کنید :
در این صورت احتمالا با کاربر System Account وارد سیستم شده اید که باید از آن خارح شده و با نام کاربری دیکری که دسترسی لازم را دارد وارد شوید .
با کلیک روی continue به marketplace مایکروسافت منتقل خواهید شد که نیازمند یک حساب کاربری در مایکروسافت میباشد :
حال پنجره زیر نمایش داده میشود و به شما اجازه‌ی دانلود app داده میشود :
روی return to site کلیک کنید تا پنجره بعدی برای گرفتن اعتماد شما برای نصب نمایش داده شود :
روی trust it کلیک کنید تا به صفحه site Content منتقل شوید :
همانطور که مشاهده میکنید app در حال دانلود شدن است :
حال در سمت چپ سایت روی نام App کلیک کنید (ترجیحا از مرور گر IE و ورژن 9 یا 10 استفاده کنید )
حال وارد تنظمیات app می‌شوید (در صورت درخواست نام کاربری و کلمه عبور آن را وارد کنید)
و نتیجه این هفت خوان رستم :
فرض کنید کنید هدرهای کش کردن عناصر پویا و یا ثابت سایت را برای مدتی مشخص تنظیم کرده‌اید.
سؤال: مرورگر چه زمانی از کش محلی خودش استفاده خواهد کرد (بدون ارسال درخواستی به سرور) و چه زمانی مجددا از سرور درخواست دریافت مجدد این عنصر کش شده را میکند؟
برای پاسخ دادن به این سؤال نیاز است با مفهومی به نام Conditional Requests (درخواست‌های شرطی) آشنا شد که در ادامه به بررسی آن خواهیم پرداخت.
درخواست‌های شرطی
مرورگرهای وب دو نوع درخواست شرطی و غیر شرطی را توسط پروتکل HTTP و HTTPS ارسال می‌کنند. دراینجا، زمانی یک درخواست غیرشرطی ارسال میشود که نسخه‌ی ذخیره شده‌ی محلی منبع مورد نظر، مهیا نباشد. در این حالت، اگر منبع درخواستی در سرور موجود باشد، در پاسخ ارسالی خود وضعیت 200 یا HTTP/200 OK را باز می‌گرداند. اگر هدرهای دیگری نیز مانند کش کردن منبع در اینجا تنظیم شده باشند، مرورگر نتیجه‌ی دریافتی را برای استفاده‌ی بعدی ذخیره خواهد کرد.
در بار دومی که منبع مفروضی درخواست میگردد، مرورگر ابتدا به کش محلی خود نگاه خواهد کرد. همچنین در این حالت نیاز دارد که بداند این کش معتبر است یا خیر؟ برای بررسی این مورد ابتدا هدرهای ذخیره شده به همراه منبع، بررسی می‌شوند. پس از این بررسی اگر مرورگر به این نتیجه برسد که کش محلی معتبر است، دیگر درخواستی را به سرور ارسال نخواهد کرد.
اما در آینده اگر مدت زمان کش شدن تنظیم شده توسط هدرهای مرتبط، منقضی شده باشد (برای مثال با توجه به max-age هدر کش شدن منبع)، مرورگر هنوز هم درخواست کاملی را برای دریافت نسخه‌ی جدید منبع مورد نیاز، به سرور ارسال نمی‌کند. در اینجا ابتدا یک conditional request را به وب سرور ارسال میکند (یک درخواست شرطی). این درخواست شرطی تنها دارای هدرهای If-Modified-Since و یا If-None-Match است و هدف از آن سؤال پرسیدن از وب سرور است که آیا این منبع خاص، در سمت سرور اخیرا تغییر کرده‌است یا خیر؟ اگر پاسخ سرور خیر باشد، باز هم از همان کش محلی استفاده خواهد شد و مجددا درخواست کاملی برای دریافت نمونه‌ی جدیدتر منبع مورد نیاز، به سرور ارسال نمی‌گردد.
پاسخی که سرور جهت مشخص سازی عدم تغییر منابع خود ارسال میکند، با هدر HTTP/304 Not Modified مشخص میگردد (این پاسخ هیچ body خاصی نداشته و فقط یک سری هدر است). اما اگر منبع درخواستی اخیرا تغییر کرده باشد، پاسخ HTTP/200 OK را در هدر بازگشت داده شده، به مرورگر بازخواهد گرداند (یعنی محتوا را مجددا دریافت کن).
چه زمانی مرورگر درخواست‌های شرطی If-Modified-Since را به سرور ارسال میکند؟
اگر یکی از شرایط ذیل برقرار باشد، مرورگر حتی اگر تاریخ کش شدن منبع ویژه‌ای به 10 سال بعد تنظیم شده باشد، مجددا یک درخواست شرطی را برای بررسی اعتبار کش محلی خود به سرور ارسال میکند:
الف) کش شدن بر اساس هدر خاصی به نام vary صورت گرفته‌است (برای مثال بر اساس id یا نام یک فایل).
ب) اگر نحوه‌ی هدایت به صفحه‌ی جاری از طریق META REFRESH باشد.
ج) اگر از طریق کدهای جاوا اسکریپتی، دستور reload صفحه صادر شود.
د) اگر کاربر دکمه‌ی refresh را فشار دهد.
ه) اگر قسمتی از صفحه توسط پروتکل HTTP و قسمتی دیگر از آن توسط پروتکل HTTPS ارائه شود.
و ... اگر بر اساس هدر تاریخ مدت زمان کش شدن منبع، زمان منقضی شدن آن فرا رسیده باشد.
مدیریت درخواست‌های شرطی در ASP.NET MVC
تا اینجا به این نکته رسیدیم که قرار دادن ویژگی Output cache بر روی یک اکشن متد، الزاما به معنای کش شدن آن تا مدت زمان تعیین شده نخواهد بود و مرورگر ممکن است (در یکی از 6 حالت ذکر شده فوق) توسط ارسال هدر If-Modified-Since ، سعی در تعیین اعتبار کش محلی خود کند و اگر پاسخ 304 را از سرور دریافت نکند، حتما نسبت به دریافت مجدد و کامل آن منبع اقدام خواهد کرد.
سؤال: چگونه میتوان هدر If-Modified-Since را در ASP.NET MVC مدیریت کرد؟
پاسخ: اگر از فیلتر OutputCache استفاده میکنید، به صورت خودکار هدر Last-Modified را اضافه میکند؛ اما این مورد کافی نیست.
در ادامه یک کنترلر و اکشن متد GetImage آن‌را ملاحظه میکنید که تصویری را از مسیر app_data/images خوانده و بازگشت میدهد. همچنین این تصویر بازگشت داده شده را نیز با توجه به OutputCache آن به مدت یک ماه کش میکند.
با این View که تصویر خود را توسط اکشن متد GetImage تهیه میکند:
در سطر اول متد GetImage، یک break point قرار دهید و سپس برنامه را توسط VS.NET اجرا کنید.
بار اول که صفحه‌ی اول برنامه درخواست میشود، یک چنین هدرهایی رد و بدل خواهند شد (توسط ابزار‌های توکار مرورگر وب کروم تهیه شدهاست؛ همان دکمه‌ی F12 معروف):
چون status code آن مساوی 200 است، بنابراین دریافت کامل فایل صورت خواهد گرفت. فیلتر OutputCache نیز مواردی مانند Cache-Control، Expires و Last-Modified را اضافه کرده‌است.
در همین حال اگر صفحه را ریفرش کنیم (فشردن دکمه‌ی F5)، اینبار هدرهای حاصل چنین شکلی را پیدا می‌کنند:
در اینجا چون یکی از حالات صدور درخواست‌های شرطی (ریفرش صفحه) رخداده است، هدر If-Modified-Since نیز در درخواست حضور دارد. پاسخ آن از طرف وب سرور (و نه برنامه؛ چون اصلا متد کش شده‌ی GetImage دیگر اجرا نخواهد شد و به break point داخل آن نخواهیم رسید)، 304 یا تغییر نکرده‌است. بنابراین مرورگر مجددا درخواست دریافت کامل فایل را نخواهد داد.
در ادامه بجای اینکه صفحه را ریفرش کنیم، یکبار دیگر در نوار آدرس آن، دکمه‌ی Enter را فشار خواهیم داد تا آدرس موجود در آن (ریشه سایت) مجددا در حالت معمولی دریافت شود.
همانطور که ملاحظه میکنید اینبار پاسخ نمایش داده شده 200 است اما در ادامه‌ی آن ذکر شدهاست from cache. یعنی درخواستی را به سرور برای دریافت فایل ارسال نکرده است. عدم رسیدن به break point داخل متد GetImage نیز مؤید آن است.
مشکل! مرورگر را ببندید، تا کار دیباگ برنامه خاتمه یابد. مجددا برنامه را اجرا کنید. مشاهده خواهید کرد که ... اجرای برنامه در Break point قرار گرفته در سطر اول متد GetImage متوقف میشود. چرا؟! مگر قرار نبود تا یک ماه دیگر کش شود؟! هدر رد و بدل شده نیز Status Code:200 OK کامل است (که سبب دریافت کامل فایل میشود).
راه حل: هدر If-Modified-Since را باید برای اولین بار فراخوانی اکشن متدی که حاصل آن نیاز است کش شود، خودمان و به صورت دستی مدیریت کنیم (فیلتر OutputCache این‌کار را انجام نمی‌دهد). به نحو ذیل:
در این حالت اگر مرورگر هدر If-Modified-Since را ارسال کرد، یعنی آدرس درخواستی هم اکنون در کش آن موجود است؛ فقط نیاز دارد تا شما پاسخ دهید که آیا آخرین تاریخ تغییر فایل درخواستی، از زمان آخرین درخواست صورت گرفته از سایت شما، تغییری کرده‌است یا خیر؟ اگر خیر، فقط کافی است 304 یا HttpStatusCode.NotModified را بازگشت دهید (بدون نیاز به بازگشت اصل فایل).
برای امتحان آن همانطور که عنوان شد فقط کافی است یکبار مرورگر خود را کاملا بسته و مجددا برنامه را اجرا کنید.
موارد کاربرد
اکثر فید خوان‌های معروف نیز ابتدا هدر If-Modified-Since را ارسال می‌کنند و سپس (اگر چیزی تغییر کرده بود) محتوای فید شما را دریافت خواهند کرد. بنابراین برای کاهش بار برنامه و هچنین کاهش میزان انتقال دیتای سایت، مدیریت آن در حین ارائه محتوای پویای فیدها نیز بهتر است صورت گیرد. همچنین هر جایی که قرار است فایلی به صورت پویا به کاربران ارائه شود؛ مانند مثال فوق.
تبدیل این کدها به روش سازگار با ASP.NET MVC
ما در اینجا رسیدیم به یک سری کد تکراری if و else که باید در هر اکشن متدی که OutputCache دارد، تکرار شود. روش AOP وار آن در ASP.NET MVC، تبدیل این کدها به یک فیلتر با قابلیت استفاده‌ی مجدد است:
در اینجا توسط filterContext، میتوان به مقادیر پارامترهای ارسالی به یک اکشن متد، توسط filterContext.ActionParameters دسترسی پیدا کرد. بر این اساس میتوان مقدار پارامتر نام فایل درخواستی را یافت. سپس مسیر کامل آن‌را بازگشت داد. اگر فایل موجود باشد، هدر If-Modified-Since درخواست، استخراج میشود. اگر این هدر تنظیم شده باشد، آنگاه بررسی خواهد شد که تاریخ تغییر فایل درخواستی جدیدتر است یا قدیمی‌تر از آخرین بار مرور سایت توسط مرورگر.
و برای استفاده از آن خواهیم داشت:
البته بدیهی است اگر منطق ارسال 304 بر اساس تاریخ تغییر فایل باشد، روش فوق جواب خواهد داد. برای مثال اگر این منطق بر اساس تاریخ ثبت شده در دیتابیس است، قسمت محاسبه‌ی lastWriteTime را باید مطابق روش مطلوب خود تغییر دهید.
خلاصه‌ی بحث
چون فیلتر OutputCache در ASP.NET MVC، هدر If-Modified-Since را پردازش نمی‌کند (از این جهت که پردازش آن برای نمونه در مثال فوق وابسته به منطق خاصی است و عمومی نیست)، اگر با هر بار گشودن سایت خود مشاهده کردید، تصاویر پویایی که قرار بوده یک ماه کش شوند، دوباره از سرور درخواست می‌شوند (البته به ازای هرباری که مرورگر از نو اجرا میشود و نه در دفعات بعدی که صفحات سایت با همان وهله‌ی ابتدایی مرور خواهند شد)، نیاز است خودتان دسترسی کار پردازش هدر If-Modified-Since را انجام داده و سپس status code 304 را در صورت نیاز، ارسال کنید.
و در حالت عمومی، طراحی سیستم caching محتوای پویای شما بدون پردازش هدر If-Modified-Since ناقص است (تفاوتی نمی‌کند که از کدام فناوری سمت سرور استفاده میکنید).
برای مطالعه بیشتر
Understanding Conditional Requests and Refresh
Use If-Modified-Since header in ASP.NET
Make your browser cache the output of an HttpHandler
304 Your images from a database
Conditional GET
Website Performance with ASP.NET - Part4 - Use Cache Headers
ASP.NET MVC 304 Not Modified Filter for Syndication Content
سؤال: مرورگر چه زمانی از کش محلی خودش استفاده خواهد کرد (بدون ارسال درخواستی به سرور) و چه زمانی مجددا از سرور درخواست دریافت مجدد این عنصر کش شده را میکند؟
برای پاسخ دادن به این سؤال نیاز است با مفهومی به نام Conditional Requests (درخواست‌های شرطی) آشنا شد که در ادامه به بررسی آن خواهیم پرداخت.
درخواست‌های شرطی
مرورگرهای وب دو نوع درخواست شرطی و غیر شرطی را توسط پروتکل HTTP و HTTPS ارسال می‌کنند. دراینجا، زمانی یک درخواست غیرشرطی ارسال میشود که نسخه‌ی ذخیره شده‌ی محلی منبع مورد نظر، مهیا نباشد. در این حالت، اگر منبع درخواستی در سرور موجود باشد، در پاسخ ارسالی خود وضعیت 200 یا HTTP/200 OK را باز می‌گرداند. اگر هدرهای دیگری نیز مانند کش کردن منبع در اینجا تنظیم شده باشند، مرورگر نتیجه‌ی دریافتی را برای استفاده‌ی بعدی ذخیره خواهد کرد.
در بار دومی که منبع مفروضی درخواست میگردد، مرورگر ابتدا به کش محلی خود نگاه خواهد کرد. همچنین در این حالت نیاز دارد که بداند این کش معتبر است یا خیر؟ برای بررسی این مورد ابتدا هدرهای ذخیره شده به همراه منبع، بررسی می‌شوند. پس از این بررسی اگر مرورگر به این نتیجه برسد که کش محلی معتبر است، دیگر درخواستی را به سرور ارسال نخواهد کرد.
اما در آینده اگر مدت زمان کش شدن تنظیم شده توسط هدرهای مرتبط، منقضی شده باشد (برای مثال با توجه به max-age هدر کش شدن منبع)، مرورگر هنوز هم درخواست کاملی را برای دریافت نسخه‌ی جدید منبع مورد نیاز، به سرور ارسال نمی‌کند. در اینجا ابتدا یک conditional request را به وب سرور ارسال میکند (یک درخواست شرطی). این درخواست شرطی تنها دارای هدرهای If-Modified-Since و یا If-None-Match است و هدف از آن سؤال پرسیدن از وب سرور است که آیا این منبع خاص، در سمت سرور اخیرا تغییر کرده‌است یا خیر؟ اگر پاسخ سرور خیر باشد، باز هم از همان کش محلی استفاده خواهد شد و مجددا درخواست کاملی برای دریافت نمونه‌ی جدیدتر منبع مورد نیاز، به سرور ارسال نمی‌گردد.
پاسخی که سرور جهت مشخص سازی عدم تغییر منابع خود ارسال میکند، با هدر HTTP/304 Not Modified مشخص میگردد (این پاسخ هیچ body خاصی نداشته و فقط یک سری هدر است). اما اگر منبع درخواستی اخیرا تغییر کرده باشد، پاسخ HTTP/200 OK را در هدر بازگشت داده شده، به مرورگر بازخواهد گرداند (یعنی محتوا را مجددا دریافت کن).
چه زمانی مرورگر درخواست‌های شرطی If-Modified-Since را به سرور ارسال میکند؟
اگر یکی از شرایط ذیل برقرار باشد، مرورگر حتی اگر تاریخ کش شدن منبع ویژه‌ای به 10 سال بعد تنظیم شده باشد، مجددا یک درخواست شرطی را برای بررسی اعتبار کش محلی خود به سرور ارسال میکند:
الف) کش شدن بر اساس هدر خاصی به نام vary صورت گرفته‌است (برای مثال بر اساس id یا نام یک فایل).
ب) اگر نحوه‌ی هدایت به صفحه‌ی جاری از طریق META REFRESH باشد.
ج) اگر از طریق کدهای جاوا اسکریپتی، دستور reload صفحه صادر شود.
د) اگر کاربر دکمه‌ی refresh را فشار دهد.
ه) اگر قسمتی از صفحه توسط پروتکل HTTP و قسمتی دیگر از آن توسط پروتکل HTTPS ارائه شود.
و ... اگر بر اساس هدر تاریخ مدت زمان کش شدن منبع، زمان منقضی شدن آن فرا رسیده باشد.
مدیریت درخواست‌های شرطی در ASP.NET MVC
تا اینجا به این نکته رسیدیم که قرار دادن ویژگی Output cache بر روی یک اکشن متد، الزاما به معنای کش شدن آن تا مدت زمان تعیین شده نخواهد بود و مرورگر ممکن است (در یکی از 6 حالت ذکر شده فوق) توسط ارسال هدر If-Modified-Since ، سعی در تعیین اعتبار کش محلی خود کند و اگر پاسخ 304 را از سرور دریافت نکند، حتما نسبت به دریافت مجدد و کامل آن منبع اقدام خواهد کرد.
سؤال: چگونه میتوان هدر If-Modified-Since را در ASP.NET MVC مدیریت کرد؟
پاسخ: اگر از فیلتر OutputCache استفاده میکنید، به صورت خودکار هدر Last-Modified را اضافه میکند؛ اما این مورد کافی نیست.
در ادامه یک کنترلر و اکشن متد GetImage آن‌را ملاحظه میکنید که تصویری را از مسیر app_data/images خوانده و بازگشت میدهد. همچنین این تصویر بازگشت داده شده را نیز با توجه به OutputCache آن به مدت یک ماه کش میکند.
using System.IO;
using System.Web.Mvc;
namespace MVC4Basic.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
return View();
}
const int AMonth = 30 * 86400;
[OutputCache(Duration = AMonth, VaryByParam = "name")]
public ActionResult GetImage(string name)
{
name = Path.GetFileName(name);
var path = Server.MapPath(string.Format("~/app_data/images/{0}", name));
var content = System.IO.File.ReadAllBytes(path);
return File(content, "image/png", name);
}
}
} <img src="@Url.Action("GetImage","Home", new { name = "test.png"})"/> بار اول که صفحه‌ی اول برنامه درخواست میشود، یک چنین هدرهایی رد و بدل خواهند شد (توسط ابزار‌های توکار مرورگر وب کروم تهیه شدهاست؛ همان دکمه‌ی F12 معروف):
Remote Address:127.0.0.1:5656 Request URL:http://localhost:10419/Home/GetImage?name=test.png Request Method:GET Status Code:200 OK Response Headers Cache-Control:public, max-age=2591916 Expires:Sat, 31 May 2014 12:45:55 GMT Last-Modified:Thu, 01 May 2014 12:45:55 GMT
در همین حال اگر صفحه را ریفرش کنیم (فشردن دکمه‌ی F5)، اینبار هدرهای حاصل چنین شکلی را پیدا می‌کنند:
Remote Address:127.0.0.1:5656 Request URL:http://localhost:10419/Home/GetImage?name=test.png Request Method:GET Status Code:304 Not Modified Request Headers If-Modified-Since:Thu, 01 May 2014 12:45:55 GMT
در ادامه بجای اینکه صفحه را ریفرش کنیم، یکبار دیگر در نوار آدرس آن، دکمه‌ی Enter را فشار خواهیم داد تا آدرس موجود در آن (ریشه سایت) مجددا در حالت معمولی دریافت شود.
Remote Address:127.0.0.1:5656 Request URL:http://localhost:10419/Home/GetImage?name=test.png Request Method:GET Status Code:200 OK (from cache)
مشکل! مرورگر را ببندید، تا کار دیباگ برنامه خاتمه یابد. مجددا برنامه را اجرا کنید. مشاهده خواهید کرد که ... اجرای برنامه در Break point قرار گرفته در سطر اول متد GetImage متوقف میشود. چرا؟! مگر قرار نبود تا یک ماه دیگر کش شود؟! هدر رد و بدل شده نیز Status Code:200 OK کامل است (که سبب دریافت کامل فایل میشود).
Remote Address:127.0.0.1:5656 Request URL:http://localhost:10419/Home/GetImage?name=test.png Request Method:GET Status Code:200 OK Request Headers If-Modified-Since:Thu, 01 May 2014 12:45:55 GMT
using System;
using System.IO;
using System.Net;
using System.Web.Mvc;
namespace MVC4Basic.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
return View();
}
const int AMonth = 30 * 86400;
[OutputCache(Duration = AMonth, VaryByParam = "name")]
public ActionResult GetImage(string name)
{
name = Path.GetFileName(name);
var path = Server.MapPath(string.Format("~/app_data/images/{0}", name));
var lastWriteTime = System.IO.File.GetLastWriteTime(path);
this.Response.Cache.SetLastModified(lastWriteTime.ToUniversalTime());
var header = this.Request.Headers["If-Modified-Since"];
if (!string.IsNullOrWhiteSpace(header))
{
DateTime isModifiedSince;
if (DateTime.TryParse(header, out isModifiedSince) && isModifiedSince > lastWriteTime)
{
return new HttpStatusCodeResult(HttpStatusCode.NotModified);
}
}
var content = System.IO.File.ReadAllBytes(path);
return File(content, "image/png", name);
}
}
} برای امتحان آن همانطور که عنوان شد فقط کافی است یکبار مرورگر خود را کاملا بسته و مجددا برنامه را اجرا کنید.
Remote Address:127.0.0.1:5656 Request URL:http://localhost:10419/Home/GetImage?name=test.png Request Method:GET Status Code:304 Not Modified Request Headers If-Modified-Since:Thu, 01 May 2014 13:43:32 GMT
موارد کاربرد
اکثر فید خوان‌های معروف نیز ابتدا هدر If-Modified-Since را ارسال می‌کنند و سپس (اگر چیزی تغییر کرده بود) محتوای فید شما را دریافت خواهند کرد. بنابراین برای کاهش بار برنامه و هچنین کاهش میزان انتقال دیتای سایت، مدیریت آن در حین ارائه محتوای پویای فیدها نیز بهتر است صورت گیرد. همچنین هر جایی که قرار است فایلی به صورت پویا به کاربران ارائه شود؛ مانند مثال فوق.
تبدیل این کدها به روش سازگار با ASP.NET MVC
ما در اینجا رسیدیم به یک سری کد تکراری if و else که باید در هر اکشن متدی که OutputCache دارد، تکرار شود. روش AOP وار آن در ASP.NET MVC، تبدیل این کدها به یک فیلتر با قابلیت استفاده‌ی مجدد است:
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public sealed class SetIfModifiedSinceAttribute : ActionFilterAttribute
{
public string Parameter { set; get; }
public string BasePath { set; get; }
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
var response = filterContext.RequestContext.HttpContext.Response;
var request = filterContext.RequestContext.HttpContext.Request;
var path = getPath(filterContext);
if (string.IsNullOrWhiteSpace(path))
{
response.StatusCode = (int)HttpStatusCode.NotFound;
filterContext.Result = new EmptyResult();
return;
}
var lastWriteTime = File.GetLastWriteTime(path);
response.Cache.SetLastModified(lastWriteTime.ToUniversalTime());
var header = request.Headers["If-Modified-Since"];
if (string.IsNullOrWhiteSpace(header)) return;
DateTime isModifiedSince;
if (DateTime.TryParse(header, out isModifiedSince) && isModifiedSince > lastWriteTime)
{
response.StatusCode = (int)HttpStatusCode.NotModified;
response.SuppressContent = true;
filterContext.Result = new EmptyResult();
}
}
string getPath(ActionExecutingContext filterContext)
{
if (!filterContext.ActionParameters.ContainsKey(Parameter)) return string.Empty;
var name = filterContext.ActionParameters[Parameter] as string;
if (string.IsNullOrWhiteSpace(name)) return string.Empty;
var path = Path.GetFileName(name);
path = filterContext.HttpContext.Server.MapPath(string.Format("{0}/{1}", BasePath, path));
return !File.Exists(path) ? string.Empty : path;
}
} و برای استفاده از آن خواهیم داشت:
[SetIfModifiedSince(Parameter = "name", BasePath = "~/app_data/images/")]
[OutputCache(Duration = AMonth, VaryByParam = "name")]
public ActionResult GetImage(string name)
{
name = Path.GetFileName(name);
var path = Server.MapPath(string.Format("~/app_data/images/{0}", name));
var content = System.IO.File.ReadAllBytes(path);
return File(content, "image/png", name);
} خلاصه‌ی بحث
چون فیلتر OutputCache در ASP.NET MVC، هدر If-Modified-Since را پردازش نمی‌کند (از این جهت که پردازش آن برای نمونه در مثال فوق وابسته به منطق خاصی است و عمومی نیست)، اگر با هر بار گشودن سایت خود مشاهده کردید، تصاویر پویایی که قرار بوده یک ماه کش شوند، دوباره از سرور درخواست می‌شوند (البته به ازای هرباری که مرورگر از نو اجرا میشود و نه در دفعات بعدی که صفحات سایت با همان وهله‌ی ابتدایی مرور خواهند شد)، نیاز است خودتان دسترسی کار پردازش هدر If-Modified-Since را انجام داده و سپس status code 304 را در صورت نیاز، ارسال کنید.
و در حالت عمومی، طراحی سیستم caching محتوای پویای شما بدون پردازش هدر If-Modified-Since ناقص است (تفاوتی نمی‌کند که از کدام فناوری سمت سرور استفاده میکنید).
برای مطالعه بیشتر
Understanding Conditional Requests and Refresh
Use If-Modified-Since header in ASP.NET
Make your browser cache the output of an HttpHandler
304 Your images from a database
Conditional GET
Website Performance with ASP.NET - Part4 - Use Cache Headers
ASP.NET MVC 304 Not Modified Filter for Syndication Content
در مبحث قبلی گفتیم که ویرایش تنظیمات لاگ‌ها از طریق IIS یا ویرایش مستقیم فایلهای کانفیگ میسر است. در این مقاله که قسمت پایانی مبحث لاگ هاست، در مورد ویرایش فایلهای کانفیگ صحبت میکنیم؛ همچنین استفاده از دستورات appcmd برای ویرایش و نهایتا کد نویسی در زبان سی شارپ و جاوااسکریپت.
تنظیمات لاگ سایت‌ها در فایل applicationhost در آدرس زیر قرار دارد:
C:\Windows\System32\inetsrv\config\applicationHost.config
خصوصیات دیگری را هم مشاهده خواهید کرد که شاید قبلا ندیده‌اید که البته بستگی به ورژن IIS شما دارد؛ مثلا خصوصیت‌های maxLogLineLength و flushByEntryCountW3Clog از IIS8.5 اضافه شده اند.
جدول خصوصیت ها
| خصوصیت | توضیح |
| customLogPluginClsid | یک پارامتر رشته‌ای اختیاری که در آن، آی دی کلاس یا کلاس‌هایی نوشته میشود که برای custom logging نوشته شده‌اند و این گزینه ترتیب اجرای آنها را تعیین میکند. |
| directory | اختیاری است. محل ذخیره‌ی لاگ فایل‌ها را مشخص میکند و در صورتیکه ذکر نشود، همان مسیر پیش فرض است. |
| enabled | اختیاری است. فعال بودن سیستم لاگ برای آن سایت را مشخص میکند. مقدار پیش فرض آن true است. |
| flushByEntryCountW3CLog | این مقدار مشخص میکند چند رخداد باید اتفاق بیفتد تا عمل ذخیره سازی لاگ صورت گیرد. اگر بعد از هر رخداد عمل ثبت لاگ انجام شود، سرعت ثبت لاگ‌ها بالا می‌رود؛ ولی باعث استفاده‌ی مداوم از منابع و همچنین درخواست ثبت اطلاعات را روی دیسک خواهد داد و تاوان آن با زیاد شدن عملیات روی دیسک، پرداخته خواهد شد. ولی در حالتیکه چند رخداد را نگهداری سپس دسته‌ای ثبت کند، باعث افزایش کارآیی و راندمان سرور خواهد شد. در صورتیکه سرور به مشکلات لحظه‌ای برخورد میکند مقدار آن را کاهش دهید. مقدار پیش فرض 0 است. یعنی اینکه ثبت، بعد از 64000 لاگ خواهد بود. |
| localTimeRollover | نحوه‌ی نامگذاری فایلهای لاگ را مشخص میکند که مقدار بولین گرفته و اختیاری است. به طور پیش فرض مقدار false دارد. |
| logExtFileFlags | این گزینه در حالتی به کارتان می‌آید که فرمت W3C را برای ثبت لاگ‌ها انتخاب کرده باشید و در اینجا مشخص میکنید که چه فیلدهایی باید در لاگ باشند و اگر بیش از یکی بود میتوان با ، (کاما) از هم جدایشان کرد. |
| logFormat | نوع فرمت ذخیره سازی لاگ‌ها |
| logSiteId | اختیاری است و مقدار پیش فرض آن true است. بدین معنا که کد یا شماره‌ی سایت هم در لاگ خواهد بود و این در حالتی است که گزارش در سطح سرور باشد. در غیر این صورت اگر هر سایت، جداگانه لاگی برای خود داشته باشد، ذکر نمی‌گردد. |
| logTargetW3C | اختیاری است و و مقدار file و *ETW را میگیرد که به طور پیش فرض روی File تنظیم است. در این حالت فایل لاگ‌ها در یک فایل متنی توسط http.sys ذخیره میشود. ولی موقعیکه از ETW استفاده میشود، http.sys با استفاده از iislogprovider داده‌ها را به سمت ETW ارسال میکند که منجر به اجرای سرویس Logsvc شده که از داده‌ها کوئری گرفته و آنها را مستقیما از پروسه‌های کارگر جمع آوری و به سمت فایل لاگ ارسال میکند. همچنین انتخاب این دو گزینه نیز ممکن است. |
| maxLogLineLength | حداکثر تعداد خطی که یک لاگ میتواند داشته باشد تا اینکه بتوانید در مصرف دیسک سخت صرفه جویی کنید و بیشتر کاربرد آن برای لاگ‌های کاستوم است. این عدد باید از نوع Uint باشد و اختیاری است و از 2 تا 65536 مقدار میپذیرد که مقدار پیش فرض آن 65536 میباشد. |
| period | همان مبحث زمان بندی در مورد ایجاد فایلهای لاگ است که در مقاله‌ی پیشین برسی کردیم و مقادیر Dialy,Hourly,monthlyو weekly را میپذیرد. همچنین maxsize هم هست؛ موقعی که لاگ به نهایت حجمی که برای آن تعیین کردیم میرسد. |
| truncateSize | اختیاری است و مقدار آن از نوع int64 است. حداکثر حجم یک فایل لاگ را مشخص میکند تا اگر period روی maxsize تنظیم شده بود، حداکثر حجم را میتوان از اینجا تعیین نمود. در مقاله پیشین در این باره صحبت کردیم؛ حداقل عدد برای آن 1,048,576 است و اگر کمتر از آن بنویسید، سیستم همین عدد 1,048,576 را در نظر خواهد گرفت. مقدار پیش فرض آن 20971520 می باشد. |
* ETW یا Event Tracing Windows، سیستم و یا نرم افزاری برای عیب یابی و نظارت برای کامپوننت‌های ویندوزی است و یکی از استفاده کننده‌هایش IIS است که از ویندوز 2000 به بعد اضافه شدهاست. برای قطع کردن این ماژول در IIS هم میتوانید قسمت هفتم را بررسی نمایید و دنیال ماژول TracingModule بگردید. این ماژول به صورت Real time به ثبت رخدادهای IIS می‌پردازد.
به غیر از خصوصات بالا، خصوصیت customFields نیز از IIS 8.5 (به بعد) در دسترس است. اگر قصد دارید به غیر از فیلدهای W3c فیلدهای اختصاصی دیگری نیز داشته باشید، میتوان از این گزینه استفاده کرد. این فیلدهای کاستوم می‌توانند اطلاعاتشان را از request header ، response header و server variables دریافت کنند. این ویژگی تنها در فرمت W3C و در سطح سایت قابل انجام است. موقعی که یک فایل لاگ شامل فیلدهای اختصاصی شود، به انتها نام فایل X_ اضافه میگردد تا نشان دهد شامل یک فیلد اختصاصی یا کاستوم است. نحوه تعریف آن در فایل applicationhost به شکل زیر است:
<system.applicationHost>
<sites>
<siteDefaults>
<logFile logFormat="W3C"
directory="%SystemDrive%\inetpub\logs\LogFiles"
enabled="true">
<customFields>
<clear/>
<add logFieldName="ContosoField" sourceName="ContosoSource"
sourceType="ServerVariable" />
</customFields>
</logFile>
</siteDefaults>
</sites>
</system.applicationHost> تغییر تنظمیات لاگ با Appcmd
appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.enabled:"True" /commit:apphost appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.logFormat:"W3C" /commit:apphost appcmd.exe set config -section:system.applicationHost/sites /siteDefaults.logFile.directory:"%SystemDrive%\inetpub\logs\LogFiles" /commit:apphost
تنظمیات تگ لاگ با برنامه نویسی و اسکریپت نویسی
using System;
using System.Text;
using Microsoft.Web.Administration;
internal static class Sample
{
private static void Main()
{
using (ServerManager serverManager = new ServerManager())
{
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection sitesSection = config.GetSection("system.applicationHost/sites");
ConfigurationElement siteDefaultsElement = sitesSection.GetChildElement("siteDefaults");
ConfigurationElement logFileElement = siteDefaultsElement.GetChildElement("logFile");
logFileElement["logFormat"] = @"W3C";
logFileElement["directory"] = @"%SystemDrive%\inetpub\logs\LogFiles";
logFileElement["enabled"] = true;
serverManager.CommitChanges();
}
}
} با استفاده از اسکریپت نویسی توسط جاوااسکریپت و وی بی اسکریپت هم نیز این امکان مهیاست:
var adminManager = new ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";
var sitesSection = adminManager.GetAdminSection("system.applicationHost/sites", "MACHINE/WEBROOT/APPHOST");
var siteDefaultsElement = sitesSection.ChildElements.Item("siteDefaults");
var logFileElement = siteDefaultsElement.ChildElements.Item("logFile");
logFileElement.Properties.Item("logFormat").Value = "W3C";
logFileElement.Properties.Item("directory").Value = "%SystemDrive%\\inetpub\\logs\\LogFiles";
logFileElement.Properties.Item("enabled").Value = true;
adminManager.CommitChanges(); FTP Logging
برای اطمینان از نصب Ftp logging موقع نصب، باید از مورد زیر مطمئن باشید:
IIS را باز کنید و در لیست درختی، سرور را انتخاب کنید. در قسمت FTP میتوانید گزینه‌ی Ftp logging را ببینید. تنظیمات این قسمت هم دقیقا همانند قسمت logging میباشد و همان موارد برای آن هم صدق میکند.
بررسی تگ آن در applicationhost
تگ این نوع لاگ در فایل applicationhost در زیر مجموعه‌ی تگ <site> به شکل زیر نوشته میشود:
<system.ftpServer>
<log centralLogFileMode="Central">
<centralLogFile enabled="true" />
</log>
</system.ftpServer> گزینه centralLogFileMode دو مقدار central و site را میپذیرد. اگر گزینه‌ی central انتخاب شود، یعنی همه‌ی لاگ‌ها را داخل یک فایل در سطح سرور ثبت کن ولی اگر گزینه‌ی site انتخاب شده باشد، لاگ هر سایت در یک فایل ثبت خواهد شد.
گزینه‌ی logInUTF8 یک خصوصیت اختیاری است که مقدار پیش فرض آن true میباشد. در این حالت باید تمامی رشته‌ها به انکدینگ UTF-8 تبدیل شوند.
همانطور که می‌بینید تگ log در بالا یک تگ فرزند هم به اسم centralLogFile دارد که همان خصوصیات جدول بالا در آن مهیاست.
دسترسی به تنظیمات این قسمت توسط دستور Appcmd:
appcmd.exe set config -section:system.ftpServer/log /centralLogFileMode:"Central" /commit:apphost appcmd.exe set config -section:system.ftpServer/log /centralLogFile.enabled:"True" /commit:apphost
دسترسی به تنظیمات این قسمت توسط دات نت:
using System;
using System.Text;
using Microsoft.Web.Administration;
internal static class Sample
{
private static void Main()
{
using (ServerManager serverManager = new ServerManager())
{
Configuration config = serverManager.GetApplicationHostConfiguration();
ConfigurationSection logSection = config.GetSection("system.ftpServer/log");
logSection["centralLogFileMode"] = @"Central";
ConfigurationElement centralLogFileElement = logSection.GetChildElement("centralLogFile");
centralLogFileElement["enabled"] = true;
serverManager.CommitChanges();
}
}
}
دسترسی به تنظیمات این قسمت توسط Javascript:
var adminManager = new ActiveXObject('Microsoft.ApplicationHost.WritableAdminManager');
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST";
var logSection = adminManager.GetAdminSection("system.ftpServer/log", "MACHINE/WEBROOT/APPHOST");
logSection.Properties.Item("centralLogFileMode").Value = "Central";
var centralLogFileElement = logSection.ChildElements.Item("centralLogFile");
centralLogFileElement.Properties.Item("enabled").Value = true;
adminManager.CommitChanges();
اشتراک‌ها
اندازه گیری دما، مختصات جغرافیایی، لرزه یا تکانه و تنظیم نمودن هشدار دهنده توسط NET Micro Framework
اگر شما یک دات نت developer هستید، میتوانید بدون داشتن دانش زبانهای سطح پایین مانند Assembly روی دستگاههای سازگار با این فریم ورک کد بنویسید و شرایط محیطی پیرامونتان را مانیتور نمایید. این پلت فرم رایگان و با سورس باز است و فرصت طلایی را در اختیار توسعه دهندگان جهت برنامه نویسی روی میکرو پروسسورها "با حداقل تنظیمات پیچیده" قرار میدهد.
شما میتوانید با syntax (دستورات) دات نتی روی بوردهایی با قیمت زیر 100$ براحتی در محیط دات نت برنامه بنویسید و به همان راحتی باگ گیری نمایید. بعنوان مثال برنامه GPS را روی بورد بنویسید و آن را به شی نصب کرده و از مختصات جغرافیایی در هر لحظه آگاه شوید. و یا دمای پیرامونتان را هر از X ثانیه توسط Thread اندازهگیری نمایید و چنانچه بالاتر و یا پایین‌تر از مقدار مورد انتظارتان بود هشدار دهنده را فعال نمایید.
با تشکر از مطلب مفیدتون.
چند تا سوال برام پیش اومده.
اول اینکه آیا به صورت یک DLL به بانک اضافه میشه؟
دوم اینکه اگه از بانک بک آپ بگیریم و جایی دیگه خواستیم اون رو ریستور کنیم چی میشه؟
آپلود بانک روی هاست (بک آپ یا اتچ) ؟
C# Regex class provides pattern matching funcions in form of regular expressions. The source code examples in this article show how to use Regular Expressions to validate different inputs. The code provides methods to validate Alphabet, AlphaNumeric, Integer, Postive Integers, Floating point numbers and so on
Text Processing
Using Regular Expressions in .NET
Character Sets
Quantifiers
Anchors
Alternation
Searching Summary
Regex Tester Program II
Regex Objects
Groups
Look-Arounds
Replacing Text with Regex
Cleaning Data with Regular Expressions
Unicode
Optimizing Your Regex
Regex Errors
Other Regex Options
Regex Summary
Resources
