.\"
.\" 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 مراجعه کنید.