.\" .\" mono-shlib-cop manual page. .\" (C) 2005-2006 Jonathan Pryor .\" Author: .\" Jonathan Pryor (jonpryor@vt.edu) .\" .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .TH "mono-shlib-cop" 1 .SH "نام (NAME)" mono-shlib-cop \- بررسی‌کننده نحوه استفاده از کتابخانه‌های مشترک .SH "خلاصه دستور (SYNOPSIS)" .B mono-shlib-cop [OPTIONS]* [ASSEMBLY-FILE-NAME]* .SH "گزینه‌ها (OPTIONS)" .TP .I \-p, --prefixes=PREFIX پیشوندهای نصب Mono. این گزینه برای پیدا کردن $prefix/etc/mono/config به کار می‌رود. پیش‌فرض بر اساس مکان mscorlib.dll تعیین می‌شود و معمولاً درست است. .PP .SH "توضیحات (DESCRIPTION)" .I mono-shlib-cop ابزاری است که یک اسمبلی مدیریت‌شده را برای یافتن استفاده‌های نادرست یا مشکوک از کتابخانه‌های مشترک بررسی می‌کند. .PP این ابزار یک یا چند نام فایل اسمبلی را دریافت کرده و هر اسمبلی مشخص‌شده را بررسی می‌کند. .PP خطاهای مورد بررسی عبارتند از: .TP * آیا کتابخانه مشترک وجود دارد؟ .TP * آیا نماد درخواستی در کتابخانه مشترک وجود دارد؟ .PP هشدارهای مورد بررسی عبارتند از: .TP * آیا کتابخانه مشترک هدف، یک کتابخانه نسخه‌دار است؟ (فقط در سیستم‌های یونیکس مرتبط است، نه Mac OS X یا Windows.) .PP به طور کلی، فقط کتابخانه‌های نسخه‌دار مانند .I libc.so.6 روی سیستم کاربر وجود دارند، و تلاش برای بارگذاری .I libc.so منجر به .B System.DllNotFoundException خواهد شد. سه راه‌حل برای این مسئله وجود دارد: .TP 1. از کاربر خواسته شود که بسته‌های .I -devel را که کتابخانه بدون نسخه را ارائه می‌دهند نصب کند. این کار معمولاً مستلزم این است که کاربر تعداد زیادی بسته اضافی نصب کند که فرایند نصب را پیچیده می‌کند. .TP 2. استفاده از یک نام کاملاً نسخه‌دار در دستورات .B DllImport خود. این کار مستلزم ویرایش کد منبع و کامپایل مجدد در هر بار نیاز به هدف قرار دادن نسخه متفاوتی از کتابخانه مشترک است. .TP 3. ارائه یک فایل .I assembly.config که حاوی عناصر برای نگاشت مجدد نام کتابخانه مشترکِ استفاده‌شده توسط اسمبلی شما به کتابخانه مشترک نسخه‌دار واقعیِ موجود در سیستم کاربر باشد. Mono تعدادی ورودی از پیش موجود، از جمله برای .I libc.so و .I libX11.so ارائه می‌دهد. .SH "مثال‌ها (EXAMPLES)" کد زیر شامل مثال‌هایی از خطاها و هشدارهای فوق است: .nf using System.Runtime.InteropServices; // for DllImport class Demo { [DllImport ("bad-library-name")] private static extern void BadLibraryName (); [DllImport ("libc.so")] private static extern void BadSymbolName (); [DllImport ("libcap.so")] private static extern int cap_clear (IntPtr cap_p); } .fi .TP نام کتابخانه نادرست با فرض اینکه کتابخانه .I bad-library-name روی سیستم شما وجود ندارد، .I Demo.BadLibraryName یک خطا تولید خواهد کرد، زیرا به یک کتابخانه مشترک نیاز دارد که نمی‌تواند بارگذاری شود. این مورد ممکن است قابل چشم‌پوشی باشد؛ بخش .B "گزارش باگ‌ها (BUGS)" را ببینید. .TP نام نماد نادرست .I Demo.BadSymbolName یک خطا تولید خواهد کرد، زیرا .I libc.so (که توسط فایل .I $prefix/etc/mono/config مونو به .I libc.so.6 نگاشت مجدد شده است) شامل تابع .I BadSymbolName نیست. .TP وابستگی به کتابخانه بدون نسخه با فرض اینکه فایل .I libcap.so را دارید، .I Demo.cap_clear یک هشدار تولید خواهد کرد، زیرا هرچند .I libcap.so می‌تواند بارگذاری شود، ممکن است .I libcap.so روی سیستم کاربر وجود نداشته باشد (در FC2، فایل .I /lib/libcap.so توسط .I libcap-devel ارائه می‌شود، و شما نمی‌توانید فرض کنید که کاربران نهایی بسته‌های .I "-devel" را نصب دارند). .SH "اصلاح کد (FIXING CODE)" رفع مشکل به نوع هشدار یا خطا بستگی دارد: .TP نام‌های کتابخانه نادرست از یک نام کتابخانه معتبر در صفت .B DllImport استفاده کنید، یا یک ورودی برای نگاشت نام کتابخانه موجود خود به یک نام کتابخانه معتبر ارائه دهید. .TP نام‌های نماد نادرست به نمادی ارجاع دهید که واقعاً در کتابخانه هدف وجود دارد. .TP وابستگی به کتابخانه بدون نسخه یک ورودی برای ارجاع به یک کتابخانه به درستی نسخه‌دار شده ارائه دهید، یا از هشدار صرف‌نظر کنید (بخش .B "گزارش باگ‌ها (BUGS)" را ببینید). .SH "ورودی‌های DLLMAP (DLLMAP ENTRIES)" مونو برای هر اسمبلی بارگذاری‌شده، به دنبال یک فایل .I ASSEMBLY-NAME \.config می‌گردد و این فایل را برای یافتن اطلاعات نگاشت Dll می‌خواند. برای مثال، برای .I mcs.exe ، مونو فایل .I mcs.exe.config را می‌خواند، و برای .I Mono.Posix.dll ، مونو فایل .I Mono.Posix.dll.config \. را می‌خواند. .PP فایل .I .config یک سند XML است که حاوی یک بخش سطح بالای با ورودی‌های تو در توی است که شامل صفت‌های .B dll و .B target می‌باشد. صفت dll باید شامل همان رشته‌ای باشد که در مقدار صفت .B DllImport استفاده شده است، و صفت target مشخص می‌کند که مونو در زمان اجرا .I واقعاً کدام کتابخانه مشترک را باید بارگذاری کند. .PP یک نمونه فایل .config عبارت است از: .nf .fi .SH "گزارش باگ‌ها (BUGS)" .TP * فقط ورودی‌های .B DllImport بررسی می‌شوند؛ کدهای IL پیرامون نادیده گرفته می‌شوند. در نتیجه، اگر یک بررسی در زمان اجرا برای انتخاب این که کدام کتابخانه مشترک فراخوانی شود انجام گیرد، حتی اگر کتابخانه مشخص‌شده هرگز استفاده نشود یک خطا گزارش خواهد شد. این کد را در نظر بگیرید: .nf using System.Runtime.InteropServices; // for DllImport class Beep { [DllImport ("kernel32.dll")] private static extern int Beep (int dwFreq, int dwDuration); [DllImport ("libcurses.so")] private static extern int beep (); public static void Beep () { if (System.IO.Path.DirectorySeparatorChar == '\\\\') { Beep (750, 300); } else { beep (); } } } .fi اگر .I mono-shlib-cop روی این اسمبلی اجرا شود، خطایی برای استفاده از .I kernel32.dll گزارش خواهد شد، حتی اگر .I kernel32.dll هرگز در پلتفرم‌های یونیکس استفاده نشود. .TP * در حال حاضر .I mono-shlib-cop تنها پسوند فایل کتابخانه مشترک را بررسی می‌کند تا تعیین کند که آیا باید هشداری ایجاد شود یا خیر. یک پسوند .I .so همیشه یک هشدار تولید می‌کند، حتی اگر .I .so یک پیوند نمادین نباشد، در یک بسته .I -devel ارائه نشده باشد، و هیچ کتابخانه مشترک نسخه‌داری وجود نداشته باشد (نمونه‌های محتمل شامل .I /usr/lib/libtcl8.4.so ، .I /usr/lib/libubsec.so و غیره). .Sp در نتیجه، هشدارها برای چنین کتابخانه‌هایی بی‌استفاده و نادرست هستند. .Sp سیستم‌های Windows و Mac OS X هرگز هشداری ایجاد نمی‌کنند، زیرا این پلتفرم‌ها از پسوندهای متفاوتی برای کتابخانه‌های مشترک استفاده می‌کنند. .SH "فهرست‌های پستی (MAILING LISTS)" برای جزئیات بیشتر به http://lists.ximian.com/mailman/listinfo/mono-devel-list مراجعه کنید. .SH "وب‌گاه (WEB SITE)" برای جزئیات بیشتر به http://www.mono-project.com مراجعه کنید.