- IdentityServer نگارش 4، آخرین نگارش سورس باز و رایگان آن است و تا زمان پشتیبانی NET Core 3.1. که سال 2022 است، پشتیبانی خواهد شد.
- نگارش بعدی آن که Duende IdentityServer نام
دارد، سورس باز است، اما رایگان نیست؛ چیزی شبیه به مجوز iTextSharp. برای
کارهای تجاری باید مجوز آن خریده شود و برای کارهای کاملا سورس باز،
رایگان است.
مطلبی که در ذیل آورده شده صرفا یک برداشت شخصی است بر اساس نقل قولها و بررسی وضعیت اعضای تیمهای مرتبط با فناوریهای مختلف بکار گرفته شده در دات نت فریم ورک و ... نه رسمی!
ADO.NET ، DataSet ، DataTable و امثال آن: مرده! (مرده به معنای اینکه دیگر توسعهی جدی نخواهد یافت)
ADO.NET اولین فناوری دسترسی به دادهها در دات نت فریم ورک بود/است. مدل طراحی آن هم بر اساس امکانات زبانهای آن زمان (زمان شروع به کار دات نت) بود (و تا دات نت 4 هم تغییر عمدهای نکرده). برای مثال در زمان ارائه اولین نگارش آن خبری از Generics نبود (در دات نت 2 اضافه شد)؛ یا LINQ وجود نداشت (در دات نت سه و سه و نیم اضافه و تکمیل شد). به همین جهت طراحی آن در حال حاضر (با وجود دات نت 4) بوی ماندگی میدهد (مانند استفاده از دیتاست و دیتاتیبل) و با ORM های مایکروسافت جهت استفاده از امکانات Generics و LINQ جایگزین شده است.
البته این مورد تنها مورد مردهای است که "باید" یاد گرفت؛ مهم نیست که ORMs ارائه شدهاند. مهم این است که زیر ساخت تمام ORM های نوشته شده برای دات نت همین ADO.NET خام است.
LINQ to SQL : مرده!
مایکروسافت با این فناوری ORM های خودش را شروع کرد اما بعد از مدتی دید که بهتر است یک نسخهی عمومیتر با پشتیبانی از بانکهای اطلاعاتی دیگر مانند اوراکل، MySQL و غیره را نیز ارائه دهد. همینجا بود که آنرا خیلی ساده با Entity framework جایگزین کرد و در roadmap ارائه شده صراحتا EF به عنوان راه حل توصیه شده دسترسی به دادههای مایکروسافت اعلام شده است (+). حالا این وسط دیگر مهم نیست شما پروژه نوشته بودید یا هر چی. دیگر منتظر تغییرات خاصی در LINQ to SQL نباشید. فقط یک سری رفع باگ و نگهداری پروژه را شاهد خواهید بود. البته در همان زمان خیلی زود تکذیب کردند که LINQ to SQL مرده اما برای نمونه آقای Damien که عضو اصلی تیم LINQ to SQL بودند، اکنون در تیم XBOX مشغول به کار هستند! (+) تو خود شرح مفصل بخوان از این مجمل!
ضمنا این رو هم در نظر داشته باشید که LINQ != LINQ to SQL ؛ به عبارتی LINQ به خودی خود فقط یک language feature است.
Windows Forms یا به اختصار WinForms : مرده!
به نظر مظلومتر از این یکی در دات نت یافت نمیشود! همین چند وقت پیش یکی از اعضای مایکروسافت این نظر سنجی رو برگزار کرده بود که "ما چکار کنیم که شما راحتتر از WinForms به WPF مهاجرت کنید؟!" (+)
در قاموس WPF ، ویندوز فرمز یعنی Canvas panel ؛ به عبارتی صلبترین حالت طراحی رابط کاربری و این انتقال و مهاجرت هرچند برای کسانی که عمری را روی آن گذاشتهاند، دردناک خواهد بود اما با وجود تواناییهای WPF چیزی را از دست نخواهند داد. سیستم Layout (طرح بندی) در WinForms و همچنین دلفی، بر اساس قراردهی اشیاء در مختصات مطلقی در صفحه است. مثلا این دکمهی خاص در آن نقطهی معلوم قرار میگیرد و همین. این روش طرح بندی یکی از چندین روش طرح بندی در WPF است که اصطلاحا Canvas نام دارد. توصیه اکید و مطلق در WPF آن است که از Canvas فقط برای طراحی اشیاء گرافیکی پیچیده استفاده کنید و نه طراحی رابط کاربر. چرا؟ چون برای مثال در Silverlight که برادر کوچکتر WPF محسوب میشود، رابط کاربری آن باید بتواند همانند HTML انعطاف پذیر باشد و با اندازههای مختلف مرورگر یا اندازهی قلمهای بزرگتر هماهنگ شده و مقاومت کند، بدون اینکه از ریخت بیفتد و این مورد را سایر سیستمهای طرح بندی رابط کاربر (منهای Canvas یا همان سیستم طرح بندی WinForms) ارائه میدهند. مورد دیگری که در WPF و Silverlight بسیار حائز اهمیت است ، Content Controls میباشد. چقدر خوب میشد بتوان داخل یک کنترل، کلا یک سیستم طرح بندی را تعریف کرد و اشیاء دلخواهی را داخل آن قرار داد. مثلا ToolTip پیش فرض وجود دارد. بسیار هم خوب. بنده علاقه دارم، متن عنوان آن ضخیم باشد. کنار آن یک تصویر کوچک و در سمت چپ آن متن قرار گیرد. برای انجام اینکار در WPF لازم نیست تا شما منتظر نگارش بعدی دات نت باشید که دست اندرکاران مربوطه با افتخار در یک سند 50 صفحهای توضیح دهند که چگونه میتوان اینکار را انجام داد. یک سیستم طرح بندی را اضافه کنید. موارد ذکر شده را در آن تعریف کنید. بدون استفاده از هیچ نوع کامپوننتی یا بدون منتظر ماندن تا نگارش بعدی این محصولات، به مقصود خود رسیدهاید.
ASP.NET Web forms : داره نفسهای آخرش رو میکشه!
از زمانیکه ASP.NET MVC آمد نسخهی Web forms تقریبا فراموش شد. به وبلاگ اسکات گاتری یا Haacked و سایر اعضای اصلی دات نت که مراجعه کنید در سه سال اخیر در حد تعداد انگشتان یک دست هم در مورد Web forms مطلب ننوشتهاند. تمام تمرکز و نوآوریها بر روی MVC متمرکز شده و حتی در نسخهی 4 دات نت هم فقط یک سری صافکاری مختصر را در Web forms شاهد بودیم مثلا نام کنترلها را خودتان هم در زمان رندر نهایی میتوانید تعیین کنید! یا لطفا کردند و قسمتی از url routing موجود در ASP.NET MVC را به ASP.NET web forms 4 هم قرض دادند (این مورد شاید مهمترین تغییر قابل ذکر در ASP.Net web forms 4 است).
البته این رو هم اضافه کنم که ASP.NET MVC واقعا قابل احترام است؛ هدف از آن جدا سازی لایههای برنامه با الگوهای استاندارد صنعتی (و نه هر روش برنامه نویسی چند لایه من درآوردی)، ترویج کد نویسی بهتر، ترویج Unit testing ، رفع یک سری مشکلات ASP.NET Web forms (مثلا از ViewState های حجیم دیگر خبری نیست) و امثال آن است.
برای نمونه توجه شما را به مطلبی که آقای Dino Sposito در مورد ASP.NET Webforms نوشته جلب میکنم: (+)
به صورت خلاصه ایشان عنوان کرده زمان طراحی ASP.NET Webforms در 10 سال قبل، هدف ما انتقال سادهتر برنامه نویسهای VB به محیط وب بود. به همین جهت دست به اختراع postback ، viewState ، کنترلهای سمت سرور و غیره زدیم. (بنابراین تاکید تمام اینها این است که webforms فناوری دهه قبل "بود" و الان بنابر نیازهای جدید دست به طراحی مجدد زدهایم)
در مورد "پایان پروژه ASP.NET Ajax Control Toolkit" هم قبلا مطلب نوشته بودم و این یکی واقعا official است!
و در پایان باید متذکر شد که فلان فناوری مرده یا داره نفسهای آخرش رو میکشه اصلا مهم نیست. هنوز هم هستند سازمانهایی که برنامههای نوشته شده با ASP کلاسیک (نگارش قبل از ASP.NET Web forms) خود را دارند و خیلی هم از آن راضی هستند!
این موارد رو از این جهت نوشتم که اگر میخواهید تازه به این جمع وارد شوید دقیقا بدانید باید روی چه مواردی بیشتر وقت بگذارید و یادگیری کدامیک صرفا اتلاف وقت خواهند بود (مثلا EF بر LINQ to SQL ارجح است و اگر امروز میخواهید شروع کنید با EF شروع کنید، یا دیگر کم کم با وجود WPF ، بازار کاری برای WinForms نخواهد بود).
در مقاله چک لیست امنیتی web.config متوجه شدیم که تنظیم یک سری مقادیر، باعث افزایش ضریب ایمنی وب سایت میشود. در این نوشتار قصد داریم به بررسی این چک لیست امنیتی بپردازیم.
اولین مورد لیست در رابطه با وضعیت session هاست؛ هر چند که توصیه میشود تا جای ممکن استفاده از sessionها کنار گذاشته شود یا اینکه محدود شود .
SessionState
تگ sessionstate حاوی خصوصیتی به نام cookieless میباشد که در نسخهی یک دات نت به صورت دو ارزشی پیاده سازی شده بود و با دادن مقدار false باعث میشد که سشنها از طریق کوکیها شناسایی شوند و در صورت true شدن، استفاده کوکی مسدود و از طریق url کنترل میشد. در نسخه دو دات نت، گزینههای این خصوصیت گستردهتر شد و مقادیر مختلفی اضافه شدند؛ مانند: شناسایی خودکار (در صورت عدم پشتیبانی مرورگر از کوکی) ، استفاده از کوکی و استفاده از URL.
استفاده در حالت url باعث میشود تا عبارات نامفومی که ما به آن sessionId میگوییم در بخشی از url به شکل زیر گنجانده شود:
https://www.dntips.ir/(xxxxxx)/page.aspx
استفاده از این حالت باعث مشکلات متعددی است؛ چه از لحاظ امنیتی و سایر موارد.
1- به دلیل تنوع لینکی که توسط این sessionIDها به ازای هر کاربر ایجاد میشوند، در نظر موتورهای جست و جو لینکهایی متفاوت محسوب شده و باعث کاهش جایگاه میگردد.
2- در صورتیکه آدرس دهیهای شما بدون ذکر sessionID باشند، سرور کاربر مورد نظر را شناسایی نکرده و برای او session جدید صادر خواهد کرد. برای افزودن sessionID به لینکها و اصلاح آنها میتوان از متد زیر استفاده کرد:
Response.ApplyAppPathModifier
3- در صورت embed کردن sessionID در آدرس فایلهای استاتیک، عملیات کش کردن نیز با مشکل مواجه خواهد شد.
4- در صورتی که session معتبر باشد و لینکی از آن ارسال شود، کاربری دیگر، همان کاربر مبداء در نظر گرفته خواهد شد. نمونه این مسئله برای من اتفاق افتاده بود که در آن یکی از دوستان، لینکی از یکی از سازمانهای دولتی را برای من ارسال کرده بود که حاوی sessionId بود تا قادر باشم وجه مورد نظر را به صورت آنلاین پرداخت کنم. بعد از اینکه من لاگین کردم، session او با کد کاربری من پر شد و در همان حین دوست من با یک refresh به جای اطلاعات خودش ، اطلاعات پرداختیهای من را مشاهده میکرد.
در صورتی که از session استفاده نمیکنید، بهترین حالت غیرفعال کردن این گزینه میباشد.
HttpOnly Cookie
httpOnly برای کوکیها، در واقع یک فلگ است که از سوی مایکروسافت معرفی شده و در حال حاضر اکثر مرورگرها از این گزینه پشتیبانی میکنند. این فلگ باعث میشود که کوکی در مرورگر دیگر از طریق اسکریپتهای سمت کلاینت در دسترس نبوده و تنها از طریق ارتباط با سرور در دسترس قرار گیرد. نحوه افزودن این فلگ را در دستور زیر مشاهده میکنید:
Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]
با افزودن این فلگ، دامنه حملات سمت کلاینت به خصوص XSS کاهش پیدا کرده و امکان جابجایی کوکی بین مرورگرها از بین خواهد رفت. طبق گفتهی مایکل هوارد، یکی از مدیران امنیتی خانواده ویندوز، بیشتر این نوع حملات، صرف کوکیهای سشن میباشد. در صورتیکه کوکی به فلگ httponly مزین شده باشد، حمله کننده قادر نخواهد بود از طریق کلاینت، دیتای داخل کوکی را بخواند و بجای آن، یک رشتهی خالی را تحویل گرفته و به سمت حمله کننده ارسال خواهد کرد.
در دات نت دو، این امکان برای forms Authentication و همچنین session Id به طور خودکار لحاظ میگردد و این امکان از طریق وب کانفیگ در دسترس است:
<httpCookies httpOnlyCookies="true" …>
همچنین به شکل زیر از طریق کدنویسی امکان اعمال این فلگ بر روی کوکیها امکان پذیر میباشد:
HttpCookie myCookie = new HttpCookie("myCookie"); myCookie.HttpOnly = true; Response.AppendCookie(myCookie);
در نگارشهای ماقبل دات نت دو باید این مورد را دستی به کوکی اضافه کرد که آقای هانسلمن در وبلاگش این مورد را به طور کامل ذکر کرده است.
Custom Errors Mode
این مورد برای مشخص شدن وضعیت نمایش خطاها ایجاد شده است. در صورت خاموش کردن (Off) این گزینه، چه بر روی لوکال و چه بر روی سرور میزبان، خطاهای صفحه زرد رنگ به کاربران نمایش داده خواهد شد و از آنجا که این صفحه اطلاعات حیاتی و مهمی برای نمایش دارند، بهتر است که این صفحه از دید کابران نهایی مخفی شده و با ست کردن این گزینه روی On، صفحات خاصی که برای خطا مشخص کردهایم نمایش پیدا میکنند و در صورتی که remoteOnly باشد، باعث میشود صفحه زرد رنگ تنها در حالت لوکال به نمایش در بیاید؛ ولی بر روی سرور تنها صفحات نهایی خطا نمایش داده میشوند که برای پروژههای در حالت توسعه بسیار مفید میباشد.
در نسخه IIS7 تگ دیگری به نام httperrors هم نیز اضافه شده است؛ ولی برای استفاده در نسخههای پیشین و همچنین IIS express موجود در ویژوال استودیو از همان Custom error استفاده نمایید.
Trace
trace کردن در دات نت یکی از قابلیتهای مهم در سیستم دیباگینگ به شمار میرود که در دو حالت (در سطح اپلیکیشن) و همچنین (در سطح صفحه) اجرا میشود. این اطلاعات شامل اطلاعات مهمی چون درخواستها و پارامترها، توکن سشنها و... میباشد که در انتهای صفحه یا در پنجره مخصوص به خود به کاربر نمایش میدهد. بدیهی است که برای انتشار نهایی برنامه، این گزینه باید غیرفعال باشد تا این اطلاعات دیده نشوند.
compilation debug
با true شدن این گزینه در محیط اجرایی، مشکلات زیادی برای سیستم ASP.Net رخ میدهد که در زیر آنها را بررسی میکنیم:
1- باعث افزایش حجم شاخه temp خواهد شد.
2- timeout شدن صفحات با مشکل مواجه خواهند شد و ممکن است این timeout شدن اصلا رخ ندهد.
3- Batch Compilation که در همین تگ قابلیت true و false شدن را دارد، به کل نادیده گرفته شده و طوری با آن رفتار خواهد شد همانند حالتیکه مقدارش به false تنظیم شدهاست. این گزینه این امکان را به ما میدهد در صورتیکه درخواست صفحهای در یک پوشهی خاص داده شد، بقیه صفحات در آن محل نیز پردازش شوند تا در صورت درخواست صفحات همسایه، سرعت بالاتری در لود آن داشته باشیم. البته ناگفته نماند در صورتیکه در همان لحظه زمانی، سرور بار سنگینی را داشته باشد، این فرایند کنسل خواهد شد.
4- همه کتابخانههای جاوااسکرپیتی و فایلهای استاتیکی که از طریق فایل axd قابل دسترس هستند، قابلیت کش شدن را از دست داده و سرعت کندی خواهند داشت. همچنین در صورتیکه این گزینه با false مقداردهی شود، امکان فشرده سازی نیز اضافه خواهد شد.
5- واضح است که با فعال سازی این گزینه، امکان دیباگینگ فعال شده و همه موارد را برای دیباگر مهیا میکند تا بتواند تا حد ممکن، همه مباحث مانیتور شوند و این مورد بر کارآیی نهایی تاثیرگذار خواهد بود.
وبلاگها و سایتهای ایرانی
Visual Studio
ASP. Net
طراحی وب
اسکیوال سرور
به روز رسانیها
سیشارپ
عمومی دات نت
PHP
متفرقه
- فایلهای استاندارد آن روی Any CPU کامپایل شدهاند. ادامه در اینجا
+ وابستگی WindowsBase هم یک فایل استاندارد مجموعه دات نت است و نه خارج از آن و در WPF از آن استفاده میشود. بنابراین مشکلی ندارد (چون حتی اگر یک dll بومی ویندوز هم باشد، با توجه به اینکه عملا دو نگارش X86 و X64 دات نت وجود دارند، بسته به سیستم مورد استفاده، یکی از آنها به صورت خودکار در ابتدای کار نصب دات نت فریم ورک، نصب خواهد شد).
+ وابستگی WindowsBase هم یک فایل استاندارد مجموعه دات نت است و نه خارج از آن و در WPF از آن استفاده میشود. بنابراین مشکلی ندارد (چون حتی اگر یک dll بومی ویندوز هم باشد، با توجه به اینکه عملا دو نگارش X86 و X64 دات نت وجود دارند، بسته به سیستم مورد استفاده، یکی از آنها به صورت خودکار در ابتدای کار نصب دات نت فریم ورک، نصب خواهد شد).
در این مطلب یک ترفند ساده و سریع برای دوستانی که میخواهند از ویژوال استودیو 2010 برای ساختن برنامهی Setup پروژههای خود استفاده کنند، آورده میشود.
اگر برای ساخت برنامههای نصب خود بخواهید از ویژوال استودیو 2010 استفاده کنید و ورژن دات نت برنامه شما بالاتر از 4 باشد، متوجه خواهید شد که در قسمت prerequisites، ورژن دات نت مورد نظر شما وجود ندارد.
برای اضافه کردن net 4.5. و بالاتر به برنامهی نصب خود باید یک Bootstrapper ایجاد کرده و به Bootstrapper Package های موجود در ویندوز اضافه نمایید.
در اینجا نحوه ایجاد و استفاده از Bootstrapper توضیح داده شده است. اما برای اینکه نخواهید درگیر ساخت XML manifests برای Net 4.5. شوید، یک راه حل سادهتر وجود دارد و آ ن استفاده از Bootstrapper های ساخته شده هنگام نصب ورژنهای بالاتر ویژوال استودیو که شامل ورژنهای مورد نیاز از دات نت نیز هستند میباشد.
برای این کار کافی است به مسیر زیر بر روی سیستم مراجعه نمایید:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages
در مسیر فوق، فولدرهای DotNetFX451 ،DotNetFX45 و DotNetFX452 را مشاهده میکنید که شامل فایلهای مورد نیاز برای اضافه کردن Bootstrapper به ویژوال استادیو 2010 است.
برای اینکار فولدر مربوطه را کپی نمایید و در مسیر زیر قرار دهید:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages
فقط توجه داشته باشید که باید فایل نصب دات نت (مثلا برای دات نت 4.5 فایل dotNetFx45_Full_x86_x64.exe ) را به آن اضافه نمایید.
حال اگر ویژوال استادیو 2010 را باز کنید و یک پروژه ستاپ ایجاد نمایید میبینید که ورژن مورد نظر به قسمت prerequisites اضافه شده است.
این مورد عموما به معنای استفاده نکردن از آخرین SDKها و ابزارهای موجود است.
- یا باید از VS 2017 استفاده کنید به همراه نصب وابستگیهای NET Core. و آخرین به روز رسانیهای آن (اجباری)
- یا از روش مطرح شدهی برای VSCode استفاده کنید.
- یا باید از VS 2017 استفاده کنید به همراه نصب وابستگیهای NET Core. و آخرین به روز رسانیهای آن (اجباری)
- یا از روش مطرح شدهی برای VSCode استفاده کنید.
dotnet restore dotnet run
نظرات مطالب
تاریخچهی نگارشهای مختلف دات نت فریم ورک
ممنون. دات نت فریم ورک پایه و اساس محصولات جدید مایکروسافت است. به همین جهت توسعهی آن برای آنها خیلی اهمیت دارد.
WF برای مثال در شیرپوینت و بیزتاک سرور داره استفاده میشه. یا خیلی از قسمتهایی که به ASP.Net داره اضافه میشه به نظر من با هدفگیری این محصولات است که خیرش داره به بقیه هم میرسه.
management studio اس کیوال سرورهای 2005 به بعد با دات نت نوشته شده.
و خیلی از مواردی که مایکروسافت از لحاظ امنیتی با آنها مشکل داشت با کوچ به دات نت فریم ورک به شدت امن شدهاند چون برای مثال buffer overflow attacks در دات نت معنی ندارد و اگر کد شما فقط از managed code تشکیل شده باشد، کاملا کنترل شده است. به همین جهت اگر به لیست تعداد حملات صورت گرفته به اس کیوال سرورهای 2005 به بعد مراجعه کنید، کاهش محسوسی رو میتونید ملاحظه کنید.
WF برای مثال در شیرپوینت و بیزتاک سرور داره استفاده میشه. یا خیلی از قسمتهایی که به ASP.Net داره اضافه میشه به نظر من با هدفگیری این محصولات است که خیرش داره به بقیه هم میرسه.
management studio اس کیوال سرورهای 2005 به بعد با دات نت نوشته شده.
و خیلی از مواردی که مایکروسافت از لحاظ امنیتی با آنها مشکل داشت با کوچ به دات نت فریم ورک به شدت امن شدهاند چون برای مثال buffer overflow attacks در دات نت معنی ندارد و اگر کد شما فقط از managed code تشکیل شده باشد، کاملا کنترل شده است. به همین جهت اگر به لیست تعداد حملات صورت گرفته به اس کیوال سرورهای 2005 به بعد مراجعه کنید، کاهش محسوسی رو میتونید ملاحظه کنید.
سلام؛ من سعی کردم این کدها رو تست کنم بنابراین قدم به قدم پیش رفتم. بعد وظیفه رو به شکل زیر فراخوانی کردم
دو بار web application رو اجرا کردم و نتیجه به شکل زیر بود
یعنی دفعه اول 5 بار وظیفه اجرا شده دفعه دوم 3 بار.
ولی هدف من از اعمال زمانبندی اینه که بی نهایت بار وظیفه اجرا بشه، به طور مثال در یک سایت آگهی شبیه ایستگاه، مثلاً دو روز قبل از انقضای آگهی به فرد اطلاع داده بشه که آگهی شما داره منقضی میشه.
البته من در لوکال تست کردم.
من بهتر از
جایی برای فراخوانی پیدا نکردم.
لطفاً راهنمایی کنید.
protected void Application_Start(object sender, EventArgs e) { Interface1 myTask = new HelloSchedule(); myTask.Run(); }
Message from HelloJob 6/19/2014 10:40:15 AM Message from HelloJob 6/19/2014 10:40:25 AM Message from HelloJob 6/19/2014 10:40:35 AM Message from HelloJob 6/19/2014 10:40:45 AM Message from HelloJob 6/19/2014 10:40:55 AM Message from HelloJob 6/19/2014 11:24:36 AM Message from HelloJob 6/19/2014 11:24:45 AM Message from HelloJob 6/19/2014 11:24:55 AM
ولی هدف من از اعمال زمانبندی اینه که بی نهایت بار وظیفه اجرا بشه، به طور مثال در یک سایت آگهی شبیه ایستگاه، مثلاً دو روز قبل از انقضای آگهی به فرد اطلاع داده بشه که آگهی شما داره منقضی میشه.
البته من در لوکال تست کردم.
من بهتر از
Application_Start
لطفاً راهنمایی کنید.
پاسخ به بازخوردهای پروژهها
فونت نستعلیق
- نیاز هست سورس iText رو پچ کرد (غیر رسمی است).
- پشتیبانی رسمی از GUSB در سال 2014 به مجموعه iText اضافه خواهد شد. نظر نویسنده اصلی iText در این مورد:
- پشتیبانی رسمی از GUSB در سال 2014 به مجموعه iText اضافه خواهد شد. نظر نویسنده اصلی iText در این مورد:
It's indeed not supported yet. It's on our roadmap for next year (2014). – Bruno Lowagie