عدم نیاز برنامه به وجود دی ال ال ها در هنگام اجرا

[soroush_vs]

ضمن سلام و عرض تبریک سال نو
حتما میدونید که برنامه های اجرایی که با ویژوال سی پی پی نوشته میشه نیاز به یه سری دی ال ال برای اجرا داره.به عنوان مثال هنگامی که قصد انتقال برنامه که کامپیوتر دیگه ای رو داشته باشد حتما باید اون دی ال ال ها رو هم انتقال بدید.
حال سوال من این هست که آیا میشه طوری کامپایل رو انجام داد که نیازی دیگه به اون دی ال ال ها نباشه و در حقیقت هر آنچه که برنامه برای اجرا نیاز داره درون خود فایل اجرایی باشه؟
با تشکر

[amir_civil]

Project\Properties\General\UseOf Mfc\=>Use MFC in a Static Library

[soroush_vs]

یه نکته وجود داره اول اینکه پروژه ای که الان دارم و میخام این کار رو باهاش بکنم پروژه ام اف سی نیست.
در پروژه هایی که ام اف سی نیستن چه باید کرد
الان همین کار رو با این پروژه انجام دادمو هنگام لینک کردن حدود 56 ارو تولید شد.
پروزه از نوع win32 هست

[joker]

enjoy IT
..........

[amir_civil]

هیچ فرقی نمیکنه
پروژه چی هست؟
از چه کتابخانه استفاده کردی؟

[Nima_NF]

برای win32 احتمالا بتوانید از کامپایل در حالت static این dll ها استفاده کنید، فقط توجه داشته باشید این کار محدودیت های زیادی دارد و در کل فقط در موارد خاص توصیه نمی شود، به مسیر زیر بروید:



Project -> Properties ->C/C++ -> Code Generation -> Runtime library -> /MT

در فیلد فوق /MT را فعال کنید تا static از کتابخانه runtime استفاده کند.

[soroush_vs]

آقا نیما من دلفی هم کار کردم در دلفی ما هر پروژه ای رو که بخایم ایجاد و توزیع کنیم این پروژه به هیچ دی ال الی نیاز نداره و به قولی کاملا مستقل هست.
من میخام برای انواع پروژه هایی که در سی پلاس پلاس میشه ساخت بفهمم چگونه میشه این حالت رو داشته باشیم که بدون نیاز به دلی ال ال ها بتونیم برنامه رو توزیع کنیم ..یعنی دی ال ال ها درون فایل اجرایی به شکلی داشته باشیم.
برای پروژه های MFC که فرمودید راه حلش چی هست.
برای پروژه های Win32 میخام بدونم آیا راه حل مشخصی که برنامه نویسان ازش استفاده میکنن وجود داره؟

[Nima_NF]

برای پروژه های Win32 میخام بدونم آیا راه حل مشخصی که برنامه نویسان ازش استفاده میکنن وجود داره؟

روشی که در فوق گفتم برای همان win32 هست و می توانید از آن استفاده کنید، اما تقریبا هیچ نرم افزاری از آن استفاده نمی کند. همواره dll ها را در کنار فایل اجرایی کپی می زنند یا آن ها را با نصب در ویندوز کپی می کنند.

مجددا تاکید می کنم که یکپارچه کرده dll ها در فایل اجرایی و مستقل کردن از dll ها (static link) محدودیت های بسیار زیادی ایجاد می کند و در همه موارد نمی توان از آن استفاده کرد.

[vcldeveloper]

آقا نیما من دلفی هم کار کردم در دلفی ما هر پروژه ای رو که بخایم ایجاد و توزیع کنیم این پروژه به هیچ دی ال الی نیاز نداره و به قولی کاملا مستقل هست.
من میخام برای انواع پروژه هایی که در سی پلاس پلاس میشه ساخت بفهمم چگونه میشه این حالت رو داشته باشیم که بدون نیاز به دلی ال ال ها بتونیم برنامه رو توزیع کنیم ..یعنی دی ال ال ها درون فایل اجرایی به شکلی داشته باشیم.در دلفی شما مفهومی دارید بنام Package که به شما این امکان را میده که در صورت استفاده از بخشی از کد آن، فقط همان بخش از کد را به پروژه لینک کنید. Packageها هر چند نوعی DLL هستند، ولی انعطاف پذیری بیشتری نسبت به DLL عادی ویندوز دارند، برای همین هم دلفی از آنها استفاده میکنه. تمام کامپوننت هایی هم که در پروژه خودتان استفاده می کنید، از یک یا چند Package تشکیل شدند.
اگر شما در یک پروژه دلفی بخواید از DLLهای عادی استفاده کنید، آن وقت باید مثل ++VC آنها را به همراه پروژه خودتان به سیستم هدف منتقل کنید. در ++VC چون چیزی مثل Package در دلفی وجود نداره، شما همیشه به اینگونه DLLها نیاز دارید، و runtime این زبان هم بصورت DLL منتشر میشه. پس انتقال DLLهای مربوطه با برنامه یک امر کاملا عادی محسوب میشه. در حالی که در دلفی runtime و تمام کامپوننت های استاندارد و 3rd Party بصورت Package منتشر میشند، و حالت پیش فرض کامپایل هم Stand alone هست، پس خروجی پروژه شما در بیشتر مواقع یک فایل EXE هست که نیازی به هیچ فایل دیگه ایی برای اجرا نداره. زمانی در دلفی نیاز به انتقال DLL با برنامه دارید که در برنامه از DLL خاصی (بجز Packageها) استفاده کرده باشید. این حالت معمولا زمانی پیش میاد که شما بخواید از کدی که با زبانی غیر از دلفی نوشته شده، استفاده کنید.
البته دلفی یک حالت build with runtime packages هم داره که در اون صورت باید علاوه بر فایل EXE تولید شده، Packageهای استفاده شده در برنامه را هم به همراه برنامه به سیستم مقصد منتقل کنید.

[MSJazayeri]

روشی که در فوق گفتم برای همان win32 هست و می توانید از آن استفاده کنید، اما تقریبا هیچ نرم افزاری از آن استفاده نمی کند. همواره dll ها را در کنار فایل اجرایی کپی می زنند یا آن ها را با نصب در ویندوز کپی می کنند.

مجددا تاکید می کنم که یکپارچه کرده dll ها در فایل اجرایی و مستقل کردن از dll ها (static link) محدودیت های بسیار زیادی ایجاد می کند و در همه موارد نمی توان از آن استفاده کرد.

در مورد این محدودیت ها میتونید یک مثال بزنید؟

[Nima_NF]

در مورد این محدودیت ها میتونید یک مثال بزنید؟

1) هنگام کار با کلاس هایی مثل CWinFormsDialog برای ترکیب برنامه های MFC با برنامه های دات نت (که طی مقاله آموزشی در شماره اول مجله برنامه نویس مطرح شد) نمی توان از static linking استفاده کرد:



MFC Windows Forms integration works only in projects that link dynamically with MFC (projects in which AFXDLL is defined).




2) برای استفاده از سوییچ clr/ نیز نمی توان (C Run-Time Libraries):




You cannot use the statically linked CRT ( /MT or /MTd options) with /clr. Use the dynamically-linked libraries (/MD or /MDd) instead.


3) توابعی که موقعیت ها و مکان ها را در هر مرحله در خود ذخیره می کنند مانند strtok که در برنامه های خودم زیاد استفاده کرده ام (C Run-Time Libraries):




Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. For example, if you use strtok, _strtok_l, wcstok, _wcstok_l, _mbstok, _mbstok_l when using a statically linked CRT, the position of the strtok parser is unrelated to the strtok state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. In contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. This concern does not apply if you use the new more secure versions of these functions; for example, strtok_s does not have this problem.



کامپایل با نسخه های مختلف کتابخانه ها (مثلا با VC++2008):




If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C++. For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. Now that the CRT DLL has been renamed to msvcr90.dll, applications may have some components linked to msvcrt.dll and others to msvcr90.dll. If your DLLs pass CRT resources across the msvcrt.dll and msvcr90.dll boundary, you will encounter issues with mismatched CRTs and need to recompile your project with Visual C++ 2008.



و موارد دیگر که همواره در حالت static باید مواظب آن ها باشیم.