StringBuilder
بهترین روش برای تولید و دستکاری یک رشته (string) طولانی و یا دستکاری متناوب و تکراری یک رشته استفاده از کلاس StringBuilder است. این کلاس در فضای نام System.Text قرار داره. شی String در داتنتفریمورک تغییرناپذیره (immutable)، بدین معنی که پس از ایجاد نمیتوان محتوای اونو تغییر داد. برای مثال اگر شما بخواین محتوای یک رشته رو با اتصال به رشتهای دیگه تغییر بدین، اجازه اینکار را به شما داده نمیشه. درعوض بهصورت خودکار رشتهای جدید در حافظه ایجاد میشه و محتوای دو رشته موجود پس از اتصال به هم درون اون قرار میگیره. این کار درصورتیکه تعداد عملیات مشابه زیاد باشه میتونه تاثیر منفی بر کارایی و حافظه خالی در دسترس برنامه بگذاره.
کلاس StringBuilder با استفاده از آرایهای از کاراکترها، راهحل مناسب و بهینهای رو برای این مشکل فراهم کرده. این کلاس در زمان اجرا به شما اجازه میده تا بدون ایجاد نمونههای جدید از کلاس String، محتوای یک رشته رو تغییر بدین. شما میتونید نمونهای از این کلاس رو بهصورت خالی و یا با یک رشته اولیه ایجاد کنید، سپس با استفاده از متدهای متنوع موجود، محتوای رشته رو با استفاده از انواع داده مختلف و بهصورت دلخواه دستکاری کنید. همچنین با استفاده از متد معروف ()ToString این کلاس میتونید در هر لحظه دلخواه رشته تولیدی رو بدست بیارین. دو پراپرتی مهم کلاس StringBuilder رفتارش رو درهنگام افزودن دادههای جدید کنترل میکنن:
Capacity , Length
پراپرتی Capacity اندازه بافر کلاس StringBuilder را تعیین میکنه و Length طول رشته جاری موجود در این بافر رو نمایش میده. اگر پس از افزودن داده جدید، طول رشته از اندازه بافر موجود بیشتر بشه، StringBuilder باید یه بافر جدید با اندازهای مناسب ایجاد کنه تا رشته جدید رو بتونه تو خودش نگه داره. اندازه این بافر جدید بهصورت پیشفرض دو برابر اندازه بافر قبلی درنظر گرفته میشه. بعد تمام رشته قبلی رو تو این بافر جدید کپی میکنه.
از برنامه ساده زیر میتونین برای بررسی این مسئله استفاده کنین:
using System.IO; using System.Text; class Program { static void Main() { using (var writer = new StreamWriter("data.txt")) { var builder = new StringBuilder(); for (var i = 0; i <= 256; i++) { writer.Write(builder.Capacity); writer.Write(","); writer.Write(builder.Length); writer.WriteLine(); builder.Append('1'); // <-- Add one character } } } }
دقت کنین که برای افزودن یک کاراکتر استفاده از دستور Append با نوع داده char (همونطور که در بالا استفاده شده) بازدهی بهتری نسبت به استفاده از نوع داده string (با یک کاراکتر) داره. خروجی کد فوق به صورت زیره:
16, 0 16, 1 16, 2 ... 16,14 16,15 16,16 32,17 ...
استفاده نامناسب و بیدقت از این کلاس میتونه منجر به بازسازیهای متناوب این بافر شده که درنهایت فواید کلاس StringBuilder رو تحت تاثیر قرار میده. درهنگام کار با کلاس StringBuilder اگر از طول رشته موردنظر و یا حد بالایی برای Capacity آن آگاهی حتی نسبی دارین، میتونید با مقداردهی مناسب این پراپرتی از این مشکل پرهیز کنید.
نکته: مقدار پیشفرض پراپرتی Capacity برابر 16 است.
هنگام مقداردهی پراپرتیهای Capacity یا Length به موارد زیر توجه داشته باشید:
- مقداردهی Capacity به میزانی کمتر از طول رشته جاری (پراپرتی Length)، منجر به خطای زیر میشه:
System.ArgumentOutOfRangeException
خطای مشابهی هنگام مقداردهی پراپرتی Capacityبه بیش از مقدار پراپرتی MaxCapacity رخ میدهه.البته این مورد تنها درصورتیکه بخواین اونو به بیش از حدود 2 گیگابایت (Int32.MaxValue) مقداردهی کنید پیش میاد!
- اگر پراپرتی Length را به مقداری کمتر از طول رشته جاری تنظیم کنید، رشته به اندازه طول تنظیمی کوتاه (truncate) میشه.
- اگر مقدار پراپرتی Length را به میزانی بیشتر از طول رشته جاری تنظیم کنید، فضای خالی موجود در بافر با space پر میشه.
- تنظیم مقدار Length بیشتر از Capacity، منجر به مقداردهی خودکار پراپرتی Capacity به مقدار جدید تنظیم شده برای Length میشه.
در ادامه به یک مثال برای مقایسه کارایی تولید یک رشته طولانی با استفاده از این کلاس میپردازیم. تو این مثال از دو روش برای تولید رشتههای طولانی استفاده میشه. روش اول که همون روش اتصال رشتهها (Concat) به هم هستش و روش دوم هم که استفاده از کلاس StringBuilder است. در قطعه کد زیر کلاس مربوط به عملیات تست رو مشاهده میکنین:
namespace StringBuilderTest { internal class SbTest1 { internal Action<string> WriteLog; internal int Iterations { get; set; } internal string TestString { get; set; } internal SbTest1(int iterations, string testString, Action<string> writeLog) { Iterations = iterations; TestString = testString; WriteLog = writeLog; } internal void StartTest() { var watch = new Stopwatch(); //StringBuilder watch.Start(); var sbTestResult = SbTest(); watch.Stop(); WriteLog(string.Format("StringBuilder time: {0}", watch.ElapsedMilliseconds)); //Concat watch.Start(); var concatTestResult = ConcatTest(); watch.Stop(); WriteLog(string.Format("ConcatTest time: {0}", watch.ElapsedMilliseconds)); WriteLog(string.Format("Results are{0} the same", sbTestResult == concatTestResult ? string.Empty : " NOT")); } private string SbTest() { var sb = new StringBuilder(TestString); for (var x = 0; x < Iterations; x++) { sb.Append(TestString); } return sb.ToString(); } private string ConcatTest() { string concat = TestString; for (var x = 0; x < Iterations; x++) { concat += TestString; } return concat; } } }
دو روش بحثشده در کلاس مورد استفاده قرار گرفته و مدت زمان اجرای هر کدوم از عملیاتها به خروجی فرستاده میشه. برای استفاده از این کلاس هم میشه از کد زیر در یک برنامه کنسول استفاده کرد:
do { Console.Write("Iteration: "); var iterations = Convert.ToInt32(Console.ReadLine()); Console.Write("Test String: "); var testString = Console.ReadLine(); var test1 = new SbTest1(iterations, testString, Console.WriteLine); test1.StartTest(); Console.WriteLine("----------------------------------------------------------------"); } while (Console.ReadKey(true).Key == ConsoleKey.C); // C = continue
برای نمونه خروجی زیر در لپتاپ من (Corei7 2630QM) بدست اومد:
تنظیم خاصیت Capacity به یک مقدار مناسب میتونه تو کارایی تاثیرات زیادی بگذاره. مثلا در مورد مثال فوق میشه یه متد دیگه برای آزمایش تاثیر این مقداردهی به صورت زیر به کلاس برناممون اضافه کنیم:
private string SbCapacityTest() { var sb = new StringBuilder(TestString) { Capacity = TestString.Length * Iterations }; for (var x = 0; x < Iterations; x++) { sb.Append(TestString); } return sb.ToString(); }
تو این متد قبل از ورود به حلقه مقدار خاصیت Capacity به میزان موردنظر تنظیم شده و نتیجه بدست اومده:
مشاهده میشه که روش concat خیلی کنده (دقت کنین که طول رشته اولیه هم بیشتر شده) و برای ادامه کار مقایسه اون رو کامنت کردم و نتایج زیر بدست اومد:
میبینین که استفاده مناسب از مقداردهی به خاصیت Capacity میتونه تا حدود 300 درصد سرعت برنامه ما رو افزایش بده. البته همیشه اینطوری نخواهد بود. ما در این مثال مقدار دقیق طول رشته نهایی رو میدونستیم که باعث میشه عملیات افزایش بافر کلاس StringBuilder هیچوقت اتفاق نیفته. این امر در واقعیت کمتر پیش میاد.
مقاله موجود در سایت dotnetperls شکل زیر رو به عنوان نتیجه تست بازدهی ارائه میده:
- در مواقعی که عملیاتی همچون مثال بالا طولانی و حجیم ندارین بهتره که از این کلاس استفاده نکنین چون عملیاتهای داخلی این کلاس در عملیات کوچک و سبک (مثل ابتدای نمودار فوق) موجب کندی عملیات میشه. همچنین استفاده از اون نیاز به کدنویسی بیشتری داره.
- این کلاس فشار کمتری به حافظه سیستم وارد میکنه. درمقابل استفاده از روش concat موجب اشغال بیش از حد حافظه میشه که خودش باعث اجرای بیشتر و متناوبتر GC میشه که در نهایت کارایی سیستم رو کاهش میده.
- استفاده از این کلاس برای عملیات Replace (و یا عملیات مشابه) در حلقهها جهت کار با رشتههای طولانی و یا تعداد زیادی رشته میتونه بسیار سریعتر و بهتر عمل کنه چون این کلاس برخلاف کلاس string اشیای جدید تولید نمیکنه.
- یه اشتباه بزرگ در استفاده از این کلاس استفاده از "+" برای اتصال رشتههای درون StringBuilder هست. هرگز از این کارها نکنین. (فکر کنم واضحه که چرا)
اکثر قلمهای فارسی، فاقد تعاریف مرتبط با حروف انگلیسی هستند. البته عموم کاربران متوجه این امر نمیشوند چون ویندوز دو مفهوم Font Fallback و Font Linking را جهت پوشش glyph های تعریف نشده، در پشت صحنه اعمال خواهد کرد. جزئیات بیشتر در اینجا: (^ و ^)
به صورت خلاصه کار Font Fallback در ویندوز جایگزینی خودکار قلم مورد استفاده است؛ تحت شرایط زیر:
- فونت تعریف شده در برنامه، در سیستم کاربر وجود نداشته باشد.
- تعاریف Glyphهای بکارگرفته شده در متن جاری، در قلم انتخابی وجود نداشته باشند.
در WPF این مساله کاملا قابل کنترل است. قلمی که به صورت خودکار به عنوان جایگزین مطرح میشود در قلمی به نام "Global User Interface" تعریف شده است. تعاریف این قلم ترکیبی هم در فایلی به نام GlobalUserInterface.CompositeFont در پوشه فونتهای سیستم موجود است (برای مثال، مسیر c:\windows\fonts حاوی این فایل متنی است).
اگر این فایل XML را با یک ادیتور متنی باز کنید، مشاهده خواهید کرد که بازههای مختلف کاراکترهای یونیکد، به فونتهای پیش فرضی نگاشت شدهاند. بنابراین اگر این سؤال وجود دارد که در متن مخلوط فارسی و انگلیسی من، فونت پیش فرض حروف انگلیسی از کجا تامین و مشخص میشود، پاسخ را در این فایل میتوانید مشاهده کنید.
روش دیگری هم برای تعیین Fallback font در WPF وجود دارد. یک مثال:
<Window x:Class="WpfFontTest.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
<TextBlock
Text="نمایش مخلوطی از متن فارسی و متن English با هم"
Margin="7"
FontFamily="Fonts/BNazanin.ttf#B Nazanin, Comic Sans Ms"
FontSize="25"
FlowDirection="RightToLeft"
VerticalAlignment="Top" HorizontalAlignment="Center" />
</Grid>
</Window>
در این مثال فونت B Nazanin در برنامه قرار داده شده است (embedded font). همچنین در کنار آن پس از علامت کاما، Fallback font مشخص است. به این معنا که تاجایی که میسر است لطفا از فونت B Nazanin برای نمایش متن مورد نظر استفاده شود؛ اگر نشد از قلم Comic Sans Ms استفاده گردد. قلم B Nazanin حاوی تعاریف حروف انگلیسی نیست. بنابراین WPF جهت نمایش آنها از فونت دوم معرفی شده کمک میگیرد. توضیحات بیشتر در اینجا: (^)
پیاده سازی DbContext مورد نیاز
برای ساخت DbContext میتوان به صورت زیر عمل نمود:
namespace FsWeb.Repositories open System.Data.Entity open FsWeb.Models type FsMvcAppEntities() = inherit DbContext("FsMvcAppExample") do Database.SetInitializer(new CreateDatabaseIfNotExists<FsMvcAppEntities>()) [<DefaultValue()>] val mutable books: IDbSet<Guitar> member x.Books with get() = x.books and set v = x.books <- v
اگر syntax زبان #F برایتان نامفهوم است میتوانید از این دوره کمک بگیرید.
پیاده سازی کلاس BookRepository
ابتدا به کدهای زیر دقت کنید:
namespace FsWeb.Repositories type BooksRepository() = member x.GetAll () = use context = new FsMvcAppEntities() query { for g in context.Books do select g } |> Seq.toList
در بخش بعدی بک کوئری از DbSet مورد نظر گرفته میشود. این روش Query گرفتن در F# 3.0 مطرح شده است. در نتیجه در نسخههای قبلی آن (F# 2.0) اجرای این کوئری باعث خطا میشود. اگر قصد دارید با استفاده از F# 2.0 کوئریهای خود را ایجاد نماید باید به طریق زیر عمل نمایید:
ابتدا از طریق nuget اقدام به نصب package ذیل نمایید:
FSPowerPack.Linq.Community
query <@ seq { for g in context.Books -> g } @> |> Seq.toList
[<HandleError>] type BooksController(repository : BooksRepository) = inherit Controller() new() = new BooksController(BooksRepository()) member this.Index () = repository.GetAll() |> this.View
نکته : تنظیمات مروط به ConnectionString را فراموش نکنید:
<add name="FsMvcAppExample" connectionString="YOUR CONNECTION STRING" providerName="System.Data.SqlClient" />
استفاده از Log4Net جهت ثبت خروجیهای SQL حاصل از NHibernate
هنگام استفاده از NHibernate، پس از افزودن ارجاعات لازم به اسمبلیهای مورد نیاز آن به برنامه، یکی از اسمبلیهایی که به پوشه build برنامه به صورت خودکار کپی میشود، فایل log4net.dll است (حتی اگر ارجاعی را به آن اضافه نکرده باشیم) که جهت ثبت وقایع مرتبط با NHibernate مورد استفاده قرار میگیرد. خوب اگر مجبوریم که این وابستگی کتابخانه NHibernate را نیز در پروژههای خود داشته باشیم، چرا از آن استفاده نکنیم؟!
شرح مفصل استفاده از این کتابخانه سورس باز را در سایت اصلی آن میتوان مشاهده کرد:
برای اینکه از این کتابخانه در برنامه خود جهت ثبت عبارات SQL تولیدی توسط NHibernate استفاده کنیم، باید مراحل زیر طی شوند:
الف) ارجاعی را به اسمبلی log4net.dll اضافه نمائید (کنار اسمبلی NHibernate در پوشه build برنامه باید موجود باشد)
ب) فایل app.config برنامه را (برنامه ویندوزی) به صورت زیر ویرایش کرده و چند سطر مربوطه را اضافه نمائید (در مورد برنامههای وب هم به همین شکل است. configSections فایل web.config تنظیم شده و سپس تنظیمات log4net را قبل از بسته شدن تگ configuration اضافه نمائید ) :
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
<connectionStrings>
<!--NHSessionManager-->
<add name="DbConnectionString"
connectionString="Data Source=(local);Initial Catalog=HelloNHibernate;Integrated Security = true"/>
</connectionStrings>
<log4net>
<appender name="rollingFile"
type="log4net.Appender.RollingFileAppender,log4net" >
<param name="File" value="NHibernate_Log.txt" />
<param name="AppendToFile" value="true" />
<param name="DatePattern" value="yyyy.MM.dd" />
<rollingStyle value="Size" />
<maxSizeRollBackups value="10" />
<maximumFileSize value="500KB" />
<staticLogFileName value="true" />
<layout type="log4net.Layout.PatternLayout,log4net">
<conversionPattern value="%d %p %m%n" />
</layout>
</appender>
<logger name="NHibernate.SQL">
<level value="ALL" />
<appender-ref ref="rollingFile" />
</logger>
</log4net>
</configuration>
log4net.Config.XmlConfigurator.Configure();
یا در یک برنامه از نوع WinForms تنها کافی است سطر زیر را به فایل AssemblyInfo.cs برنامه اضافه کرد:
// Configure log4net using the .config file
[assembly: log4net.Config.XmlConfigurator(Watch = true)]
د) هنگام استفاده از کتابخانه Fluent NHibernate حتما باید متد ShowSql در جایی که دیتابیس برنامه را تنظیم میکنیم (Fluently.Configure().Database) ذکر گردد (که نمونه آنرا در مثالهای قسمتهای قبل ملاحظه کردهاید).
توضیحاتی در مورد تنظیمات فوق:
configSections حتما باید در ابتدای فایل app.config ذکر شود و گرنه برنامه کار نخواهد کرد.
سپس کانکشن استرینگ مورد استفاده در قسمت کانفیگ برنامه ذکر شده است.
در ادامه تنظیمات استاندارد مربوط به log4net را مشاهده میکنید.
در تنظیمات این کتابخانه، appender مشخص کننده محل ثبت وقایع است. زمانیکه که از RollingFileAppender استفاده کنیم، اطلاعات را در یک سری فایل ذخیره خواهد کرد (امکان ثبت وقایع در EventLog ویندوز، ارسال از طریق ایمیل و غیره نیز میسر است که جهت توضیحات بیشتر میتوان به مستندات آن رجوع نمود).
سپس نام فایلی که اطلاعات وقایع در آن ثبت خواهند شد ذکر شده است (برای مثال NHibernate_Log.txt)، در ادامه مشخص گردیده که اطلاعات باید هر بار به این فایل Append و اضافه شوند. سطرهای بعدی مشخص میکنند که هر زمانیکه این لاگ فایل به 10 مگابایت رسید، یک فایل جدید تولید کن و هر بار 10 فایل آخر را نگه دار و مابقی فایلهای قدیمی را حذف کن.
در قسمت PatternLayout مشخصات میکنیم که خروجی ثبت شده با چه فرمتی باشد. برای مثال یک سطر خروجی مطابق با تنظیمات فوق به شکل زیر خواهد بود:
2009-10-18 20:03:54,187 DEBUG INSERT INTO [Student] (Name) VALUES (@p0); select SCOPE_IDENTITY();@p0 = 'Vahid'
توسط appender-ref آن appender ایی را که در ابتدای کار تعریف و تنظیم کردیم، مشخص خواهیم کرد.
اگر هم با برنامه نویسی بخواهیم اطلاعاتی را به این لاگ فایل اضافه کنیم تنها کافی است بنویسیم:
log4net.LogManager.GetLogger("NHibernate.SQL").Info("test1");
اطلاعات بیشتر
ادامه دارد ...
کتابخانه iTextSharp دارای کلاسی است به نام HTMLWorker که کار تبدیل عناصر HTML را به عناصر متناظر خودش، انجام میدهد. این کلاس در حال حاضر منسوخ شده درنظر گرفته میشود (اینطور توسط نویسندگان آن اعلام شده) و دیگر توسعه نخواهد یافت. بنابراین اگر از HTMLWorker استفاده میکنید با یک کلاس قدیمی که دارای HTML Parser ایی بسیار بدوی است طرف هستید و در کل برای تبدیل محتوای HTML ایی با ساختار بسیار ساده بد نیست؛ اما انتظار زیادی از آن نداشته باشید.
جایگزین کلاس HTMLWorker در این کتابخانه در حال حاضر کتابخانه itextsharp.xmlworker است، که به صورت یک افزونه در کنار کتابخانه اصلی در حال توسعه میباشد. مشکل اصلی این کتابخانه، عدم پشتیبانی از UTF8 و راست به چپ است. بنابراین حداقل به درد کار ما نمیخورد.
راه حل بسیار بهتری برای موضوع اصلی بحث ما وجود دارد و آن هم استفاده از موتور WebKit (همان موتوری که برای مثال در Apple Safari استفاده میشود) برای HTML parsing و سپس تبدیل نتیجه نهایی به PDF است. پروژهای که این مقصود را میسر کرده، wkhtmltopdf نام دارد.
توسط آن به کمک موتور WebKit، کار HTML Parsing انجام شده و سپس برای تبدیل عناصر نهایی به PDF از امکانات کتابخانهای به نام QT استفاده میشود. کیفیت نهایی آن کپی مطابق اصل HTML قابل مشاهده در یک مرورگر است و با یونیکد و زبان فارسی هم مشکلی ندارد.
برای استفاده از این کتابخانهی native در دات نت، شخصی پروژهای را ایجاد کرده است به نام WkHtmlToXSharp که محصور کنندهی wkhtmltopdf میباشد. در ادامه به نحوه استفاده از آن خواهیم پرداخت:
الف) دریافت پروژه WkHtmlToXSharp
پروژه WkHtmlToXSharp را از آدرس زیر میتوانید دریافت کنید.
این پروژه به همراه فایلهای کامپایل شده نهایی wkhtmltopdf نیز میباشد و حجمی حدود 40 مگ دارد. به علاوه فعلا نسخه 32 بیتی آن در دسترس است. بنابراین باید دقت داشت که نباید تنظیمات پروژه دات نت خود را بر روی Any CPU قرار دهیم، زیرا در این حالت برنامه شما در یک سیستم 64 بیتی بلافاصله کرش خواهد کرد. تنظیمات target platform پروژه دات نتی ما حتما باید بر روی X86 تنظیم شود.
ب) پس از دریافت این پروژه و افزودن ارجاعی به اسمبلی WkHtmlToXSharp.dll، استفاده از آن به نحو زیر میباشد:
using System.IO; using WkHtmlToXSharp; using System; namespace Test2 { public class WkHtmlToXSharpTest { public static void ConvertHtmlStringToPdfTest() { using (var wk = new MultiplexingConverter()) { wk.Begin += (s, e) => Console.WriteLine("Conversion begin, phase count: {0}", e.Value); wk.Error += (s, e) => Console.WriteLine(e.Value); wk.Warning += (s, e) => Console.WriteLine(e.Value); wk.PhaseChanged += (s, e) => Console.WriteLine("PhaseChanged: {0} - {1}", e.Value, e.Value2); wk.ProgressChanged += (s, e) => Console.WriteLine("ProgressChanged: {0} - {1}", e.Value, e.Value2); wk.Finished += (s, e) => Console.WriteLine("Finished: {0}", e.Value ? "success" : "failed!"); wk.GlobalSettings.Margin.Top = "0cm"; wk.GlobalSettings.Margin.Bottom = "0cm"; wk.GlobalSettings.Margin.Left = "0cm"; wk.GlobalSettings.Margin.Right = "0cm"; wk.ObjectSettings.Web.EnablePlugins = false; wk.ObjectSettings.Web.EnableJavascript = false; wk.ObjectSettings.Load.Proxy = "none"; var htmlString = File.ReadAllText(@"c:\page.xhtml"); var tmp = wk.Convert(htmlString); File.WriteAllBytes(@"tst.pdf", tmp); } } } }
کار با وهله سازی از کلاس MultiplexingConverter شروع میشود. اگر علاقمند باشید که درصد پیشرفت کار به همراه خطاهای احتمالی پردازشی را ملاحظه کنید میتوان از رخدادگردانهایی مانند ProgressChanged و Error استفاده نمائید که نمونهای از آن در کد فوق بکارگرفته شده است.
تبدیل HTML به PDF آنچنان تنظیمات خاصی ندارد زیرا فرض بر این است که قرار است از همان تنظیمات اصلی HTML مورد نظر استفاده گردد. اما اگر نیاز به تنظیمات بیشتری وجود داشت، برای مثال به کمک GlobalSettings آن میتوان حاشیههای صفحات فایل نهایی تولیدی را تنظیم کرد.
موتور WebKit با توجه به اینکه موتور یک مرورگر است، امکان پردازش جاوا اسکریپت را هم دارد. بنابراین اگر قصد استفاده از آنرا نداشتید میتوان خاصیت ObjectSettings.Web.EnableJavascript را به false مقدار دهی کرد.
کار اصلی، در متد Convert انجام میشود. در اینجا میتوان یک رشته را که حاوی فایل HTML مورد نظر است به آن ارسال کرد و نتیجه نهایی، آرایهای از بایتها، حاوی فایل باینری PDF تولیدی است.
روش دیگر استفاده از این کتابخانه، مقدار دهی wk.ObjectSettings.Page میباشد. در اینجا میتوان Url یک صفحه اینترنتی را مشخص ساخت. در این حالت دیگر نیازی نیست تا به متد Convert پارامتری را ارسال کرد. میتوان از overload بدون پارامتر آن استفاده نمود.
یک نکته:
اگر میخواهید زبان فارسی را توسط این کتابخانه به درستی پردازش کنید، نیاز است حتما یک سطر زیر را به header فایل html خود اضافه نمائید:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
بهبود SEO برنامههای Angular
معرفی فایل جدید ViewImports
پروژهی خالی ASP.NET Core 1.0 فاقد پوشهی Views به همراه فایلهای آغازین آن است. بنابراین ابتدا در ریشهی پروژه، پوشهی جدید Views را ایجاد کنید.
فایلهای آغازین این پوشه هم در مقایسهی با نگارشهای قبلی ASP.NET MVC اندکی تغییر کردهاند. برای مثال در نگارش قبلی، فایل web.config ایی در ریشهی پوشهی Views قرار داشت و چندین مقصود را فراهم میکرد:
الف) در آن تنظیم شده بود که هر نوع درخواستی به فایلهای موجود در پوشهی Views، برگشت خورده و قابل پردازش نباشند. این مورد هم از لحاظ مسایل امنیتی اضافه شده بود و هم اینکه در ASP.NET MVC، برخلاف وب فرمها، شروع پردازش یک درخواست، از فایلهای View شروع نمیشود. به همین جهت است که درخواست مستقیم آنها بیمعنا است.
در ASP.NET Core، فایل web.config از این پوشه حذف شدهاست؛ چون دیگر نیازی به آن نیست. اگر مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 4 - فعال سازی پردازش فایلهای استاتیک» را به خاطر داشته باشید، هر پوشهای که توسط میان افزار Static Files عمومی نشود، توسط کاربران برنامه قابل دسترسی نخواهد بود و چون پوشهی Views هم به صورت پیش فرض توسط این میان افزار عمومی نمیشود، نیازی به فایل web.config، جهت قطع دسترسی به فایلهای موجود در آن وجود ندارد.
ب) کاربرد دیگر این فایل web.config، تعریف فضاهای نام پیش فرضی بود که در فایلهای View مورد استفاده قرار میگرفتند. برای مثال چون فضای نام HTML Helperهای استاندارد ASP.NET MVC در این فایل web.config قید شده بود، دیگر نیازی به تکرار آن در تمام فایلهای View برنامه وجود نداشت. در ASP.NET Core، برای جایگزین کردن این قابلیت، فایل جدیدی را به نام ViewImports.cshtml_ معرفی کردهاند، تا دیگر نیازی به ارث بری از فایل web.config وجود نداشته باشد.
برای مثال اگر میخواهید بالای Viewهای خود، مدام ذکر using مربوط به فضای نام مدلها برنامه را انجام ندهید، این سطر تکراری را به فایل جدید view imports منتقل کنید:
@using MyProject.Models
و این فضاهای نام به صورت پیش فرض برای تمام viewها مهیا هستند و نیازی به تعریف مجدد، ندارند:
• System
• System.Linq
• System.Collections.Generic
• Microsoft.AspNetCore.Mvc
• Microsoft.AspNetCore.Mvc.Rendering
افزودن یک View جدید
در نگارشهای پیشین ASP.NET MVC، اگر بر روی نام یک اکشن متد کلیک راست میکردیم، در منوی ظاهر شده، گزینهی Add view وجود داشت. چنین گزینهای در نگارش RTM اول ASP.NET Core وجود ندارد و مراحل ایجاد یک View جدید را باید دستی طی کنید. برای مثال اگر نام کلاس کنترلر شما PersonController است، پوشهی Person را به عنوان زیر پوشهی Views ایجاد کرده و سپس بر روی این پوشه کلیک راست کنید، گزینهی add new item را انتخاب و سپس واژهی view را جستجو کنید:
البته یک دلیل این مساله میتواند امکان سفارشی سازی محل قرارگیری این پوشهها در ASP.NET Core نیز باشد که در ادامه آنرا بررسی خواهیم کرد (و ابزارهای از پیش تعریف شده عموما با مکانهای از پیش تعریف شده کار میکنند).
امکان پوشه بندی بهتر فایلهای یک پروژهی ASP.NET Core نسبت به مفهوم Areas در نگارشهای پیشین ASP.NET MVC
حالت پیش فرض پوشه بندی فایلهای اصلی برنامههای ASP.NET MVC، مبتنی بر فناوریها است؛ برای مثال پوشههای views و Controllers و امثال آن تعریف شدهاند.
Project - Controllers - Models - Services - ViewModels - Views
هرکسی که مدتی با ASP.NET MVC کار کرده باشد حتما به این مشکل برخوردهاست. درحال پیاده سازی قابلیتی هستید و برای اینکار نیاز خواهید داشت مدام بین پوشههای مختلف برنامه سوئیچ کنید؛ از پوشهی کنترلرها به پوشهی ویووها، به پوشهی اسکریپتها، پوشهی اشتراکی ویووها و غیره. پس از رشد برنامه به جایی خواهید رسید که دیگر نمیتوانید تشخیص دهید این فایلی که اضافه شدهاست ارتباطش با سایر قسمتها چیست؟
ایدهی «پوشه بندی بر اساس ویژگیها»، بر مبنای قرار دادن تمام نیازهای یک ویژگی، درون یک پوشهی خاص آن است:
همانطور که مشاهده میکنید، در این حالت تمام اجزای یک ویژگی، داخل یک پوشه قرار گرفتهاند؛ از کنترلر مرتبط با Viewهای آن تا فایلهای css و js خاص آن.
برای پیاده سازی آن:
1) نام پوشهی Views را به Features تغییر دهید.
2) پوشهای را به نام StartupCustomizations به برنامه اضافه کرده و سپس کلاس ذیل را به آن اضافه کنید:
using System.Collections.Generic; using Microsoft.AspNetCore.Mvc.Razor; namespace Core1RtmEmptyTest.StartupCustomizations { public class FeatureLocationExpander : IViewLocationExpander { public void PopulateValues(ViewLocationExpanderContext context) { context.Values["customviewlocation"] = nameof(FeatureLocationExpander); } public IEnumerable<string> ExpandViewLocations( ViewLocationExpanderContext context, IEnumerable<string> viewLocations) { return new[] { "/Features/{1}/{0}.cshtml", "/Features/Shared/{0}.cshtml" }; } } }
RazorViewEngine برنامه، بر اساس وهلهی پیش فرضی از اینترفیس IViewLocationExpander، محل یافتن Viewها را دریافت میکند. با استفاده از پیاه سازی فوق، این پیش فرضها را به پوشهی features هدایت کردهایم.
3) در ادامه به کلاس آغازین برنامه مراجعه کرده و پس از فعال سازی ASP.NET MVC، این قابلیت را فعال سازی میکنیم:
public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.Configure<RazorViewEngineOptions>(options => { options.ViewLocationExpanders.Add(new FeatureLocationExpander()); });
5) اکنون باید پوشهی Controllers خالی شده باشد. این پوشه را کلا حذف کنید. از این جهت که کنترلرها بر اساس پیش فرضهای ASP.NET MVC (کلاس ختم شدهی به کلمهی Controller واقع در اسمبلی که از وابستگیهای ASP.NET MVC استفاده میکند) در هر مکانی که تعریف شده باشند، یافت خواهند شد و پوشهی واقع شدن آنها مهم نیست.
6) در آخر به فایل project.json مراجعه کرده و قسمت publish آنرا جهت درج نام پوشهی Features اصلاح کنید (تا در حین توزیع نهایی استفاده شود):
"publishOptions": { "include": [ "wwwroot", "Features", "appsettings.json", "web.config" ] },
در اینجا نیز یک نمونهی دیگر استفادهی از این روش بسیار معروف را مشاهده میکنید.
امکان ارائهی برنامه بدون ارائهی فایلهای View آن
ASP.NET Core به همراه یک EmbeddedFileProvider نیز هست. حالت پیش فرض آن PhysicalFileProvider است که بر اساس تنظیمات IViewLocationExpander توکار (و یا نمونهی سفارشی فوق در مبحث پوشهی ویژگیها) کار میکند.
برای راه اندازی آن ابتدا نیاز است بستهی نیوگت ذیل را به فایل project.json اضافه کرد:
{ "dependencies": { //same as before "Microsoft.Extensions.FileProviders.Embedded": "1.0.0" },
services.AddMvc(); services.Configure<RazorViewEngineOptions>(options => { options.ViewLocationExpanders.Add(new FeatureLocationExpander()); var thisAssembly = typeof(Startup).GetTypeInfo().Assembly; options.FileProviders.Clear(); options.FileProviders.Add(new EmbeddedFileProvider(thisAssembly, baseNamespace: "Core1RtmEmptyTest")); });
"buildOptions": { "emitEntryPoint": true, "preserveCompilationContext": true, "embed": "Features/**/*.cshtml" },
1) اگر نام پوشهی Views را به Features تغییر دادهاید، نیاز به ثبت ViewLocationExpanders آنرا دارید (وگرنه، خیر).
2) در اینجا جهت مثال و بررسی اینکه واقعا این فایلها از اسمبلی برنامه خوانده میشوند، متد options.FileProviders.Clear فراخوانی شدهاست. این متد PhysicalFileProvider پیش فرض را حذف میکند. کار PhysicalFileProvider خواندن فایلهای ویووها از فایل سیستم به صورت متداول است.
3) کار قسمت embed در تنظیمات build، افزودن فایلهای cshtml به قسمت منابع اسمبلی است (به همین جهت دیگر نیازی به توزیع آنها نخواهد بود). اگر صرفا **/Features را ذکر کنید، تمام فایلهای موجود را پیوست میکند. همچنین اگر نام پوشهی Views را تغییر ندادهاید، این مقدار همان Views/**/*.cshtml خواهد بود و یا **/Views
4) در EmbeddedFileProvider میتوان هر نوع اسمبلی را ذکر کرد. یعنی میتوان برنامه را به صورت چندین و چند ماژول تهیه و سپس سرهم و یکپارچه کرد (options.FileProviders یک لیست قابل تکمیل است). در اینجا ذکر baseNamespace نیز مهم است. در غیر اینصورت منبع مورد نظر از اسمبلی یاد شده، قابل استخراج نخواهد بود (چون نام اسمبلی، قسمت اول نام هر منبعی است).
فعال سازی کامپایل خودکار فایلهای View در ASP.NET Core 1.0
این قابلیت به زودی جهت یافتن مشکلات موجود در فایلهای razor پیش از اجرای آنها، اضافه خواهد شد. اطلاعات بیشتر
مقدمه
در اکثر موارد در یک Landscape عملیاتی، چنانچه به تجمیع و انتقال دادهها از بانکهای اطلاعاتی مختلف نیاز باشد، از SSIS Package اختصار (SQL Server Integration Service) استفاده میشود و معمولاً با تعریف یک Job در سطح SQL Server به اجرای Package در زمانهای مشخص میپردازند. چنانچه در موقعیتی لازم باشد که از طریق برنامه کاربردی توسعه یافته، به اجرای Package مبادرت ورزیده شود و البته نخواهیم Job تعریف شده را از طریق کد برنامه، اجرا کنیم و در واقع این امکان را داشته باشیم که همانند یک رویه ذخیره شده تعریف شده در سطح بانک اطلاعاتی به اجرای عمل فوق بپردازیم، یک راه حل میتواند تعریف یک CLR Stored Procedures باشد. در این مقاله به بررسی این موضوع پرداخته میشود، در ابتدا لازم است به بیان تئوری موضوع پرداخته شود (قسمتهای 1 الی 5) در ادامه به ذکر پیاده سازی روش پیشنهادی پرداخته میشود.
1- اجرای Integration Service Package
جهت اجرای یک Package از ابزارهای زیر میتوان استفاده کرد:• command-line ابزار خط فرمان dtexec.exeتوجه: همچنین یک Package را در زمان طراحی در Business Intelligence Development Studio) BIDS) میتوان اجرا نمود.
• ابزار اجرائی پکیج dtexecui.exe
• استفاده از SQL Server Agent job
2- استفاده از dtexec جهت اجرای Package
با استفاده از ابزار dtexec میتوان Packageهای ذخیره شده در فایل سیستم، یک SQL Instance و یا Packageهای ذخیره شده در Integration Service را اجرا نمود.توجه: در سیستم عاملهای 64 بیتی، ابزار dtexec موجود در Integration Service با نسخه 64 بیتی نصب میشود. چنانچه بایست Packageهای معینی را در حالت 32 بیتی اجرا کنید، لازم است ابزار dtexec نسخه 32 بیتی نصب شود. ابزار dtexec دستیابی به تمامی ویژگیهای پیکربندی و اجرای Package از قبیل اتصالات، مشخصات(Properties)، متغیرها، logging و شاخصهای پردازشی را فراهم میکند.
توجه: زمانی که از نسخهی ابزار dtexec که با SQL Server 2008 ارائه شده استفاده میکنید برای اجرای یک SSIS Package نسخه 2005، Integration Service به صورت موقت Package را به نسخه 2008 ارتقا میدهد، اما نمیتوان از ابزار dtexec برای ذخیره این تغییرات استفاده کرد.
2-1- ملاحظات نصب dtexec روی سیستمهای 64 بیتی
به صورت پیش فرض، یک سیستم عامل 64 بیتی که هر دو نسخه 64 بیتی و 32 بیتی ابزار خط فرمان Integration Service را دارد، نسخه 32 بیتی نصب شده را در خط فرمان اجرا خواهد کرد. نسخه 32 بیتی بدین دلیل اجرا میشود که در متغیر محیطی (Path (Path environment variable مسیر directory نسخه 32 بیتی قرار گرفته است.به طور معمول:2-2- تفسیر کدهای خروجی
هنگامی که یک Package اجرا میشود، dtexec یک کد خروجی (Return Code) بر میگرداند:مقدار | توصیف |
0 | Package با موفقیت اجرا شده است. |
1 | Package با خطا مواجه شده است. |
3 | Package در حال اجرا توسط کاربر لغو شده است. |
4 | Package پیدا نشده است. |
5 | Package بارگذاری نشده است. |
6 | ابزار با یک خطای نحوی یا خطای معنایی در خط فرمان برخورد کرده است. |
2-3- قوانین نحوی dtexec
تمامی گزینهها (Options) باید با یک علامت Slash (/) و یا Minus (-) شروع شوند.یک آرگومان باید در یک quotation mark محصور شود چنانچه شامل یک فاصله خالی باشد.
گزینهها و آرگومانها بجز رمزعبور حساس به حروف کوچک و بزرگ نیستند.
2-3-1- Syntax
dtexec /option [value] [/option [value]]…
2-3-2- Parameters
نکته: در Integration Service، ابزار خط فرمان dtsrun که برایData Transformation Service) DTS)های نسخه SQL Server 2000 استفاده میشد، با ابزار خط فرمان dtexec جایگزین شده است.• تعدادی از گزینههای خط فرمان dtsrun به طور مستقیم در dtexec معادل دارند برای مثال نام Server و نام Package.
• تعدادی از گزینههای dtsrun به طور مستقیم در dtexec معادل ندارند.
• تعدادی گزینههای خط فرمان جدید dtsexec وجود دارد که در ویژگیهای جدید Integration Service پشتیبانی میشود.
2-3-3- مثال
1) به منظور اجرای یک SSIS Package که در SQL Server ذخیره شده است، با استفاده از Windows Authentication :dtexec /sq <Package Name> /ser <Server Name>
2) به منظور اجرای یک SSIS Package که در پوشه File System در SSIS Package Store ذخیره شده است :
dtexec /dts “\File System\<Package File Name>”
3) به منظور اجرای یک SSIS Package که در سیستم فایل ذخیره شده است و مشخص کردن گزینه logging:
dtexec /f “c:\<Package File Name>” /l “DTS.LogProviderTextFile; <Log File Name>”
4) به منظور اجرای یک SSIS Package که در SQL Server ذخیره شده با استفاده از SQL Server Authentication برای نمونه(user:ssis;pwd:ssis@ssis)و رمز (Package(123:
dtexec /server “<Server Name>” /sql “<Package Name>” / user “ssis” /Password “ssis@ssis” /De “123”
3- تنظیمات سطح حفاظتی یک Package
به منظور حفاظت از دادهها در Packageهای Integration Service میتوانید یک سطح حفاظتی (protection level) را تنظیم کنید که به حفاظت از دادههای صرفاً حساس یا تمامی دادههای یک Package کمک نماید. به علاوه میتوانید این دادهها را با یک Password یا یک User Key رمزگذاری نمائید یا به رمزگذاری دادهها در بانک اطلاعاتی اعتماد کنید. همچنین سطح حفاظتی که برای یک Package استفاده میکنید، الزاماً ایستا (static) نیست و در طول چرخه حیات یک Package میتواند تغییر کند. اغلب سطح حفاظتی در طول توسعه یا به محض (deploy) استقرار Package تنظیم میشود.توجه: علاوه بر سطوح حفاظتی که توصیف شد، Packageها در بانک اطلاعاتی msdb ذخیره میشوند که همچنین میتوانند توسط نقشهای ثابت در سطح بانک اطلاعاتی (fixed database-level roles) حفاظت شوند. Integration Service شامل 3 نقش ثابت بانک اطلاعاتی برای نسبت دادن مجوزها به Package است که عبارتند از db_ssisadmin ،db_ssisltduser و db_ssisoperator
3-1- درک سطوح حفاظتی
در یک Package اطلاعات زیر به عنوان حساس تعریف میشوند:• بخش password در یک connection string. گرچه، اگر گزینه ای را که همه چیز را رمزگذاری کند، انتخاب کنید تمامی connection string حساس در نظر گرفته میشود.
• گرههای task-generated XML که برچسب (tagged) هایی حساس هستند.
• هر متغییری که به عنوان حساس نشان گذاری شود.
3-1-1- Do not save sensitive
هنگامی که Package ذخیره میشود از ذخیره مقادیر ویژگیهای حساس در Package جلوگیری میکند. این سطح حفاظتی رمزگذاری نمیکند اما در عوض از ذخیره شدن ویژگی هایی که حساس نشان گذاری شده اند به همراه Package جلوگیری میکند.3-1-2- Encrypt all with password
به منظور رمزگذاری تمامی Package از یک Password استفاده میشود. Package توسط Password ای رمزگذاری میشود که کاربر هنگامی که Package را ایجاد یا Export میکند، ارائه میدهد. به منظور باز کردن Package در SSIS Designer یا اجرای Package توسط ابزار خط فرمان dtexec کاربر بایست رمز Package را ارائه نماید. بدون رمز کاربر قادر به دستیابی و اجرای Package نیست.3-1-3- Encrypt all with user key
به منظور رمزگذاری تمامی Package از یک کلید که مبتنی بر Profile کاربر جاری میباشد، استفاده میشود. تنها کاربری که Package را ایجاد یا Export میکند، میتواند Package را در SSIS Designer باز کند و یا Package را توسط ابزار خط فرمان dtexec اجرا کند.3-1-4- Encrypt sensitive with password
به منظور رمزگذاری تنها مقادیر ویژگیهای حساس در Package از یک Password استفاده میشود. برای رمزگذاری از DPAPI استفاده میشود. دادههای حساس به عنوان بخشی از Package ذخیره میشوند اما آن دادهها با استفاده از Password رمزگذاری میشوند. به منظور باز نمودن Package در SSIS Designer کاربر باید رمز Package را ارائه دهد. اگر رمز ارائه نشود، Package بدون دادههای حساس باز میشود و کاربر باید مقادیر جدیدی برای دادههای حساس فراهم کند. اگر کاربر سعی نماید Package را بدون ارائه رمز اجرا کند، اجرای Package با خطا مواجه میشود.3-1-5- Encrypt sensitive with user key
به منظور رمزگذاری تنها مقادیر ویژگیهای حساس در Package از یک کلید که مبتنی بر Profile کاربر جاری میباشد، استفاده میشود. تنها کاربری که از همان Profile استفاده میکند، Package را میتواند بارگذاری (load) کند. اگر کاربر متفاوتی Package را باز نماید، اطلاعات حساس با مقادیر پوچی جایگزین میشود و کاربر باید مقادیر جدیدی برای دادههای حساس فراهم کند. اگر کاربر سعی نماید Package را بدون ارائه رمز اجرا کند، اجرای Package با خطا مواجه میشود. برای رمزگذاری از DPAPI استفاده میشود.3-1-6- (Rely on server storage for encryption (ServerStorage
با استفاده از نقشهای بانک اطلاعاتی، SQL Server تمامی Package را حفاظت میکند. این گزینه تنها زمانی پشتیبانی میشود که Package در بانک اطلاعاتی msdb ذخیره شده است.4- استفاده از نقشهای Integration Service
برای کنترل کردن دستیابی به Package، SSIS شامل 3 نقش ثابت در سطح بانک اطلاعاتی است. نقشها میتوانند تنها روی Package هایی که در بانک اطلاعاتی msdb ذخیره شده اند، بکار روند. با استفاده از SSMS میتوانید نقشها را به Packageها نسبت دهید، این انتساب نقشها در بانک اطلاعاتی msdb ذخیره میشود.Write action | Read action | Role |
Import packages Delete own packages Delete all packages Change own package roles Change all package roles * به نکته رجوع شود | Enumerate own packages Enumerate all packages View own packages View all packages Execute own packages Execute all packages Export own packages Export all packages Execute all packages in SQL Server Agent | db_ssisadmin or sysadmin |
Import packages Delete own packages Change own package roles | Enumerate own packages Enumerate all packages View own packages Execute own packages Export own packages | db_ssisltduser |
None | Enumerate all packages View all packages Execute all packages Export all packages Execute all packages in SQL Server Agent | db_ssisoperator |
Stop all currently running packages | View execution details of all running packages | Windows administrators |
همچنین جدول sysssispackages در بانک اطلاعاتی msdb شامل Package هایی است که در SQL Server ذخیره میشوند. این جدول شامل ستون هایی که اطلاعاتی درباره نقش هایی که به Packageها نسبت داده شده است، میباشد.
به صورت پیش فرض، مجوزهای نقشهای ثابت بانک اطلاعاتی db_ssisadmin و db_ssisoperator و شناسه منحصر به فرد کاربری (unique security identifier) که Package را ایجاد کرده برای خواندن Package بکار میرود، و مجوزهای نقش db_ssisadmin و شناسه منحصر به فرد کاربری که Package را ایجاد کرده برای نوشتن Package به کار میرود. یک User باید عضو نقش db_ssisadmin و db_ssisltduser یا db_ssisoperator برای داشتن دسترسی خواندن Package باشد. یک User باید عضو نقش db_ssisadmin برای داشتن دسترسی نوشتن Package باشد.
5- اتصال به صورت Remote به Integration Service
زمانی که یک کاربر بدون داشتن دسترسی کافی تلاش کند به یک Integration Service به صورت Remote متصل شود، با پیغام خطای "Access is denied" مواجه میشود. برای اجتناب از این پیغام خطا میتوان تضمین کرد که کاربر مجوز مورد نیاز DCOM را دارد.به منظور پیکربندی کردن دسترسی کاربر به صورت Remote به سرویس Integration مراحل زیر را دنبال کنید:
- Component Service را باز نمایید ( در Run عبارت dcomcnfg را تایپ کنید).مجوز دسترسی Lunch به منظور شروع و خاتمه سرویس، اعطا یا رد میشود و مجوز دسترسیActivation به منظور متصل شدن به سرویس، اعطا (grant) یا رد (deny) میشود.
- گره Component Service را باز کنید، گره Computer و سپس My Computer را باز نمایید و روی DCOM Config کلیک نمایید.
- گره DCOM Config را باز کنید و از لیست برنامه هایی که میتوانند پیکربندی شوند MsDtsServer را انتخاب کنید.
- روی Properties برنامه MsDtsServer رفته و قسمت Security را انتخاب کنید.
- در قسمت Lunch and Activation Permissions، مورد Customize را انتخاب و سپس روی Edit کلیک نمایید تا پنجره Lunch Permission باز شود.
- در پنجره Lunch Permission، کاربران را اضافه و یا حذف کنید و مجوزهای مناسب را به کاربران یا گروههای مناسب نسبت دهید. مجوزهای موجود عبارتند از Local Lunch، Remote Lunch، Local Activation و Remote Activation .
- در قسمت Access Permission مراحل فوق را به منظور نسبت دادن مجوزهای مناسب به کاربران یا گروههای مناسب انجام دهید.
- سرویس Integration را Restart کنید.
6- پیاده سازی
در ابتدا به ایجاد یک CLR Stored Procedures پرداخته میشود نام اسمبلی ساخته شده به این نام RunningPackage.dll میباشد و حاوی کد زیر است:Partial Public Class StoredProcedures '------------------------------------------------ 'exec dbo.Spc_NtDtexec 'Package','ssis','ssis@ssis','1234512345' '------------------------------------------------ <Microsoft.SqlServer.Server.SqlProcedure()> _ Public Shared Sub Spc_NtDtexec(ByVal PackageName As String, _ ByVal UserName As String, _ ByVal Password As String, _ ByVal Decrypt As String) Dim p As New System.Diagnostics.Process() p.StartInfo.FileName = "C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe" p.StartInfo.RedirectStandardOutput = True p.StartInfo.Arguments = "/sql " & PackageName & " /User " & UserName & " /Password " & Password & " /De " & Decrypt p.StartInfo.UseShellExecute = False p.Start() p.WaitForExit() Dim output As String output = p.StandardOutput.ReadToEnd() Microsoft.SqlServer.Server.SqlContext.Pipe.Send(output) End Sub End Class
در قدم بعدی نیاز به Register کردن dll ساخته شده در سطح بانک اطلاعاتی SQL Server است، این گامها پس از اتصال به SQL Server Management Studio به شرح زیر است:
1- فعال کردن CLR در سرویس SQL Server
SP_CONFIGURE 'clr enabled',1 GO RECONFIGURE
2- فعال کردن ویژگی TRUSTWORTHY در بانک اطلاعاتی مورد نظر
ALTER DATABASE <Database Name> SET TRUSTWORTHY ON GO RECONFIGURE
3- ایجاد Assembly و Stored Procedure در بانک اطلاعاتی مورد نظر
Assembly ساخته شده با نام RunningPacakge.dll در ریشه :C کپی شود. بعد از ثبت نمودن این Assembly لزومی به وجود آن نمیباشد.
USE <Database Name> GO CREATE ASSEMBLY [RunningPackage] AUTHORIZATION [dbo] FROM 'C:\RunningPackage.dll' WITH PERMISSION_SET = UNSAFE Go CREATE PROCEDURE [dbo].[Spc_NtDtexec] @PackageName [nvarchar](50), @UserName [nvarchar](50), @Password [nvarchar](50), @Decrypt [nvarchar](50) WITH EXECUTE AS CALLER AS EXTERNAL NAME [RunningPackage].[RunningPackage.StoredProcedures].[Spc_NtDtexec] GO
در برنامه کاربردی تان کافی است متدی به شکل زیر ایجاد و با توجه به نیازتان در برنامه به فراخوانی آن و اجرای Package بپردازید.
Private Sub ExecutePackage() Dim oSqlConnection As SqlClient.SqlConnection Dim oSqlCommand As SqlClient.SqlCommand Dim strCnt As String = String.Empty strCnt = "Data Source=" & txtServer.Text & ";User ID=" & txtUsername.Text & ";Password=" & txtPassword.Text & ";Initial Catalog=" & cmbDatabaseName.SelectedValue.ToString() & ";" Try oSqlConnection = New SqlClient.SqlConnection(strCnt) oSqlCommand = New SqlClient.SqlCommand With oSqlCommand .Connection = oSqlConnection .CommandType = System.Data.CommandType.StoredProcedure .CommandText = "dbo.Spc_NtDtexec" .Parameters.Clear() .Parameters.Add("@PackageName", System.Data.SqlDbType.VarChar, 50) .Parameters.Add("@UserName", System.Data.SqlDbType.VarChar, 50) .Parameters.Add("@Password", System.Data.SqlDbType.VarChar, 50) .Parameters.Add("@Decrypt", System.Data.SqlDbType.VarChar, 50) .Parameters("@PackageName").Value = txtPackageName.Text.Trim() .Parameters("@UserName").Value = txtUsername.Text.Trim() .Parameters("@Password").Value = txtPassword.Text.Trim() .Parameters("@Decrypt").Value = txtDecrypt.Text.Trim() End With If (oSqlCommand.Connection.State <> System.Data.ConnectionState.Open) Then oSqlCommand.Connection.Open() oSqlCommand.ExecuteNonQuery() System.Windows.Forms.MessageBox.Show("Success") End If If (oSqlCommand.Connection.State = System.Data.ConnectionState.Open) Then oSqlCommand.Connection.Close() End If Catch ex As Exception MessageBox.Show(ex.Message, "Error") End Try End Sub 'ExecutePackage