بررسی ساختار ویجتهای وب Kendo UI
- این فایلها را در مخزن کد مرتبط با آن میتوانید پیدا کنید.
+ «نکتهای در مورد دریافت آخرین نگارشهای Kendo UI»
برای افزودن یک ماژول به پروژه از طریق گریدل، به صورت زیر اقدام میکنیم:
هر ماژول شامل یک فایل به نام build.gradle است که تنظیمات سطح آن ماژول را به عهده دارد و پروژه نیز یک build.gradle دارد که تنظیمات آن در سطح پروژه صورت میگیرد. برای اقزودن سورس در سطح یک ماژول لازم است که تعدادی خط کد را که معرف و آدرس آن سورس را دارد، به فایل build.gradle اضافه کنیم. به عنوان مثال برای سورس Active Android را که یک ORM عالی در سطح اندروید به شمار میآید، به ماژولمان اضافه میکنیم:
dependencies { compile 'com.michaelpardo:activeandroid:3.1.0-SNAPSHOT' }
سوال : اندروید استودیو، کتابخانههای اندرویدی را از کجا دانلود میکند؟
Apache Maven یک سیستم آزاد است که برای توزیع کتابخانهها مورد استفاده قرار میگیرد. سرورهای این سیستم شامل یک مخزن maven هستند که کتابخانهها در آن قرار میگیرند و شناسهی دسترسی به آن کتابخانه از طریق همان شناسهای است که شما در build.gradle تعریف میکنید. به طور عادی دو سرور استاندارد برای اینکار وجود دارند که یکی از آنها jcenter و دیگری mavenCnteral است. البته سرورهای دیگری نیز وجود دارند، یا اینکه حتی خودتان هم میتوانید میزبانی را به عهده بگیرید و یا بعضی از شرکتها برای خود مخزنی جداگانه دارند.
JCenter
این سرور که یک مخزن maven است، توسط Bintray میزبانی میشود که میتوانید آن را در این آدرس بیابید. برای اینکه شناسههای gradle مربوط به این سرور در اندروید استودیو دانلود شود، نیاز است خط زیر را به build.gradle سطح پروژه اضافه کنید:
allprojects { repositories { jcenter() } }
MavenCentral
این مخزن توسط Sonatype.org میزبانی میشود که کل مخزن آن را میتوانید در این آدرس بیابید. برای دسترسی به مخازن این سرور نیاز است خطوط زیر را به gradle سطح پروژه اضافه کنید:
allprojects { repositories { mavenCentral() } }
به عنوان مثال Twitter's Fabric.io خودش کتابخانهی خودش را میزبانی میکند و مخزن آن در این آدرس https://maven.fabric.io/public قرار گرفته است و برای افزودن این کتابخانه به پروژه نیاز است مسیر زیر طی شود:
//project build.gradle repositories { maven { url 'https://maven.fabric.io/public' } } //module build.gradle dependencies { compile 'com.crashlytics.sdk.android:crashlytics:2.2.4@aar' }
سوال : کدامیک از مخازن بالا را انتخاب کنیم؟
دلایل مهاجرت از mavencentral به jcenter:
- سیستم jcenter از طریق یک CDN عمل میکند که در این صورت میتواند تجربهی خوبی از سرعت بهتر را برای توسعه دهندگان به همراه داشته باشد.
- کتابخانههای jcenter بسیار بیشتر از mavencentral هستند؛ تا جایی که میتوان گفت اکثر کتابخانههایی که روی mavencenteral پیدا میشوند، روی jcenter هم هست و jcenter بزرگترین مخزن به شمار میآید.
- آپلود کتابخانه بر روی jcenter بسیار راحتتر است و نیاز به کار پیچیدهای ندارد.
بررسی قسمتهای یک شناسه Gradle
هر شناسه شامل سه قسمت میشود:
GROUP_ID:ARTIFACT_ID:VERSION
کتابخانههای زیر، از یک خانواده هستند که به راحتی میتوانید آنها را از هم تشخیص دهید:
dependencies { compile 'com.squareup:otto:1.3.7' compile 'com.squareup.picasso:picasso:2.5.2' compile 'com.squareup.okhttp:okhttp:2.4.0' compile 'com.squareup.retrofit:retrofit:1.9.0' }
شناخت فایلهای AAR
همانطور که میدانید فرمت فایلهای بایت کدی جاوا JAR میباشد که هم توسط جاوا و هم اندروید پشتیبانی میشود. ولی در صورتیکه کلاس شما یک پروژهی اندرویدی باشد، نمیتوانید آن را در قالب یک فایل JAR منتشر کنید. چرا که که کلاس اندرویدی میتواند شامل فایل مانیفست، منابع و ... باشد که در فایل JAR جایی برای آنها مهیا نشده است. به همین علت فایلهای نوع AAR برای اینکار مهیا شدهاند که این فایل در واقع یک فایل زیپ است که محتویات مورد نظر داخل آن قرار گرفته است و یکی از آن فایل Classes.jar برای کدهاست و مابقی آن به شرح زیر است:
- /AndroidManifest.xml (الزامی) - /classes.jar (الزامی ) - /res/ (الزامی ) - /R.txt (الزامی ) - /assets/ (اختیاری) - /libs/*.jar (اختیاری ) - /jni/<abi>/*.so (اختیاری ) - /proguard.txt (اختیاری ) - /lint.jar (اختیاری )
در مقالهی بعدی کار را با jcenter آغاز میکنیم.
آیا میدانید چند درصد از کدهای یک پروژه شما در قسمتهای مختلف آن تکراری هستند و تا چه حد نیاز به refactoring کدهای موجود جهت مدیریت و نگهداری سادهتر از آن پروژه وجود دارد؟
اخیرا پروژه سورس بازی در سایت CodePlex به نام Clone detective ارائه شده است که این کار را به صورت خودکار با یکپارچه شدن با Visual studio برای شما انجام میدهد. این افزودنی از آدرس زیر قابل دریافت است:
http://www.codeplex.com/CloneDetectiveVS
بهترین آموزش نحوه استفاده از آن هم از طریق ویدیوی زیر در دسترس است:
مشاهده
در نگارش فعلی آن تنها پروژههای سی شارپ پشتیبانی میشوند و در نگارشهای آتی آن قرار است VB.net و CPP نیز افزوده شوند.
به چه دلیلی به این ابزار نیاز داریم؟
فرض کنید کلاسی را جهت انجام مقصودی خاص توسعه دادهاید. در کلاسی دیگر برای اتمام آن، 15 سطر از یکی از توابع کلاس اول را کپی کرده و مورد استفاده قرار دادهاید. در یک پروژه بزرگ از این موارد شاید زیاد رخ دهد (خصوصا در یک کار تیمی که ممکن است قسمتی از کار شما بهعنوان پایه اولیه کاری دیگر مورد استفاده قرار گیرد). پس از مدتی، تغییراتی را در کلاس اول ایجاد کرده و یک سری از عیوب آن 15 سطر را که جزئی از یک تابع است برطرف خواهید کرد. بسیار هم خوب! آیا این پایان کار است؟ خیر!
آیا این مورد به کل پروژه منتقل شده است؟ آیا نگهداری یک پروژه بزرگ که دارای قسمتهای تکراری زیادی است کار سادهای است؟
علاوه بر ابزار فوق، برنامه دیگری نیز جهت تشخیص کدهای تکراری در یک پروژه به نام Simian موجود است. Simian را از آدرس زیر میتوانید دریافت کنید:
http://www.redhillconsulting.com.au/products/simian/overview.html
این ابزار به صورت یک افزودنی VS.net ارائه نشده است اما میتوان از طریق منوی tools آنرا به مجموعه ابزارهای مورد استفاده اضافه کرد. نحوه انجام اینکار به صورت مصور در وبلاگ زیر بیان شده است:
مشاهده
همچنین از ابزارهای دیگری از این دست میتوان به برنامه رایگان CCFinder اشاره کرد: (ثبت نام دریافت آن رایگان است)
http://www.ccfinder.net
معرفی DNTProfiler
هدیهی نوروزی سایت net tips. پروژهی پروفایلر سورس بازی است که با EF 6.x و همچنین NHibernate 4.x سازگار است. این پروژه از دو قسمت کلاینت و سرور تشکیل میشود.
نصب کلاینت EF برنامهی DNTProfiler
تفاوتی نمیکند که برنامهی شما وبی است یا ویندوزی؛ برای هر دو حالت ابتدا دستور ذیل را در کنسول پاورشل نیوگت اجرا کنید:
PM> Install-Package DNTProfiler.EntityFramework.Core
<configuration> <entityFramework> <interceptors> <interceptor type="DNTProfiler.EntityFramework.Core.DatabaseLogger, DNTProfiler.EntityFramework.Core"> <parameters> <parameter value="http://localhost:8080" /> <parameter value="|DataDirectory|\ErrorsLog.Log" /> </parameters> </interceptor> </interceptors> </entityFramework> </configuration>
دریافت و راه اندازی برنامهی DNTProfiler
آخرین نگارش برنامهی DNTProfiler را از برگهی releases مخزن کد آن میتوانید دریافت کنید:
https://github.com/VahidN/DNTProfiler/releases
این برنامه برای دات نت 4 نوشته شدهاست. بنابراین اگر هنوز از ویندوز XP استفاده میکنید، امکان کار کردن با آنرا خواهید داشت.
البته بستهی نیوگت DNTProfiler.EntityFramework.Core آن برای دات نت 4 و 4.5 تهیه شدهاست و به صورت خودکار بر اساس ساختار پروژهی شما، یکی از آنها نصب خواهد شد.
تا اینجا کار راه اندازی این برنامه به پایان میرسد. برای استفادهی از آن باید ابتدا برنامهی DNTProfiler را اجرا کنید. این برنامه به پیامهای رسیدهی از برنامهی اصلی شما (ارسال شده توسط DNTProfiler.EntityFramework.Core) گوش فرا میدهد و سپس شروع به آنالیز آنها خواهد کرد. ساختار این تبادل اطلاعات هم بر اساس تهیهی یک ASP.NET Self host Web API است.
این برنامه به صورت ماژولار تهیه شدهاست و تمام آنالیز کنندههای آن در حقیقت یک پلاگین هستند (در حال حاضر دارای 32 پلاگین است). این پلاگینها در گروههای Alerts (برای مثال یافتن جوینهای تکراری و یک سری موارد بهینه سازی سرعت)، Loggers (طبقه بندی خام اطلاعات رسیده)، Visualizers (نمایش بصری اطلاعات رسیده) قرار میگیرند.
نظرات، پیشنهادات و همکاری
لطفا برای طرح سؤالات و ارائهی پیشنهادات خود در زمینهی این پروژه، به قسمت اختصاصی آن در سایت مراجعه نمائید:
https://www.dntips.ir/projects/details/21
یک مثال جهت بازتولید کدهای این مطلب
الف) یک پروژهی WPF جدید را به نام MergeAssembliesIntoWPF ایجاد کنید.
ب) یک پروژهی Class library جدید را به نام MergeAssembliesIntoWPF.ViewModels به این Solution اضافه کنید. از آن برای تعریف ViewModelهای برنامه استفاده خواهیم کرد.
برای نمونه کلاس ذیل را به آن اضافه کنید:
namespace MergeAssembliesIntoWPF.ViewModels { public class ViewModel1 { public string Data { set; get; } public ViewModel1() { Data = "Test"; } } }
به این پروژه ارجاعی را به اسمبلی قسمت (ب) اضافه نموده و برای نمونه User control ذیل را به نام View1.xaml به آن اضافه نمائید:
<UserControl x:Class="MergeAssembliesIntoWPF.Shell.View1" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" mc:Ignorable="d" xmlns:VM="clr-namespace:MergeAssembliesIntoWPF.ViewModels;assembly=MergeAssembliesIntoWPF.ViewModels" d:DesignHeight="300" d:DesignWidth="300"> <UserControl.Resources> <VM:ViewModel1 x:Key="ViewModel1" /> </UserControl.Resources> <Grid DataContext="{Binding Source={StaticResource ViewModel1}}"> <TextBlock Text="{Binding Data}" /> </Grid> </UserControl>
<Window x:Class="MergeAssembliesIntoWPF.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:V="clr-namespace:MergeAssembliesIntoWPF.Shell;assembly=MergeAssembliesIntoWPF.Shell" Title="MainWindow" Height="350" Width="525"> <Window.Resources> <V:View1 x:Key="View1" /> </Window.Resources> <Grid> <V:View1 /> </Grid> </Window>
ب) مدفون کردن خودکار اسمبلیهای جانبی برنامه در فایل EXE آن
فایل csproj پروژه اصلی را خارج از VS.NET باز کنید. در انتهای آن سطر ذیل قابل مشاهده است:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="AfterResolveReferences"> <ItemGroup> <EmbeddedResource Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.Extension)' == '.dll'"> <LogicalName>%(ReferenceCopyLocalPaths.DestinationSubDirectory)%(ReferenceCopyLocalPaths.Filename)%(ReferenceCopyLocalPaths.Extension)</LogicalName> </EmbeddedResource> </ItemGroup> </Target>
پس از این تغییر نیاز است یکبار پروژه را بسته و مجددا باز کنید. اکنون پروژه را build کنید و جهت اطمینان بیشتر آنرا برای مثال توسط ILSpy مورد بررسی قرار دهید:
همانطور که مشاهده میکنید، دو اسمبلی مورد استفاده در برنامه به صورت خودکار در قسمت منابع فایل EXE مدفون شدهاند.
اگر به مسیر LogicalName تنظیمات فوق دقت کنید، DestinationSubDirectory نیز ذکر شدهاست. علت این است که بسیاری از اسمبلیهای بومی سازی شده WPF با نامهایی یکسان اما در پوشههایی مانند fa، fr و امثال آن ذخیره میشوند. به همین جهت نیاز است بین اینها تمایز قائل شد.
ج) بارگذاری خودکار اسمبلیها در AppDomain برنامه
تا اینجا اسمبلیهای جانبی را در فایل EXE مدفون کردهایم. اکنون نوبت به بارگذاری آنها در AppDomain برنامه است. برای اینکار نیاز است تا روال رخدادگردان AppDomain.CurrentDomain.AssemblyResolve را تحت نظر قرار داده و اسمبلیهایی را که برنامه درخواست میکند، در همینجا از منابع خوانده و به AppDomain اضافه کرد.
انجام اینکار در برنامههای WinForms سادهاست. فقط کافی است به متد Program.Main برنامه مراجعه کرده و تعریف یاد شده را به ابتدای متد Main اضافه کرد. اما در WPF هرچند فایل App.xaml.cs به نظر نقطهی آغازین برنامه است، اما در واقع اینطور نیست. برای نمونه، پوشهی obj\Debug برنامه را گشوده و فایل App.g.i.cs آنرا بررسی کنید. در اینجا میتوانید همان رویه شبیه به برنامههای WinForm را در متد Program.Main آن، مشاهده کنید. بنابراین نیاز است کنترل این مساله را راسا در دست بگیریم:
using System; using System.Globalization; using System.Reflection; namespace MergeAssembliesIntoWPF { public class Program { [STAThreadAttribute] public static void Main() { AppDomain.CurrentDomain.AssemblyResolve += OnResolveAssembly; App.Main(); } private static Assembly OnResolveAssembly(object sender, ResolveEventArgs args) { var executingAssembly = Assembly.GetExecutingAssembly(); var assemblyName = new AssemblyName(args.Name); var path = assemblyName.Name + ".dll"; if (assemblyName.CultureInfo.Equals(CultureInfo.InvariantCulture) == false) { path = String.Format(@"{0}\{1}", assemblyName.CultureInfo, path); } using (var stream = executingAssembly.GetManifestResourceStream(path)) { if (stream == null) return null; var assemblyRawBytes = new byte[stream.Length]; stream.Read(assemblyRawBytes, 0, assemblyRawBytes.Length); return Assembly.Load(assemblyRawBytes); } } } }
پس از اینکه کلاس فوق را اضافه کردید، نیاز است کلاس Program اضافه شده را به عنوان Startup object برنامه نیز معرفی کنید:
انجام اینکار ضروری است؛ در غیراینصورت با متد Main موجود در فایل App.g.i.cs تداخل میکند.
اکنون برای آزمایش برنامه، یکبار آنرا Build کرده و بجز فایل Exe، مابقی فایلهای موجود در پوشهی bin را حذف کنید. سپس برنامه را خارج از VS.NET اجرا کنید. کار میکند!
MergeAssembliesIntoWPF.zip
یکی از نکات جالبی که در مورد Silverlight وجود دارد این است که هر چند تنها قسمتی از WPF را به ارث برده (برای اینکه حجم افزونهی آن قابل قبول باشد)، اما بیشتر از خود WPF مورد توجه مایکروسافت است! شاید یک دلیل آن استفاده از Silverlight در Windows phone 7 باشد. به عبارتی اگر برنامه نویس Silverlight هستید، هم اکنون برنامه نویس Windows phone 7 نیز میباشید.
این توجه بیشتر در Silverlight toolkit کاملا مشخص است. Silverlight toolkit از یک سری ابزار و کامپوننت برای توسعهی سادهتر برنامههای Silverlight به صورت سورس باز و تهیه شده توسط مایکروسافت، تشکیل شده است. حجم WPF toolkit که آن هم توسط مایکروسافت به صورت سورس باز ارائه و به روز میشود حدود 2 مگابایت است؛ اما حجم Silverlight toolkit حدود 18 مگابایت میباشد! بسیاری از کنترلها و امکانات Silverlight toolkit را در WPF نمیتوانید پیدا کنید مانند BusyIndicator ، ChildWindow ، DataForm و غیره. نمونهی دیگر این توجه WCF RIA Services است. هدفگیری اصلی این مورد نیز Silverlight است و نه WPF (که از آن در Visual studio LightSwitch هم استفاده کردهاند).
اخیرا یک گروه خیّر کار تبدیل و انتقال کنترلهای Silverlight toolkit به WPF toolkit را شروع کرده است که حاصل آن از آدرس ذیل قابل دریافت است: (این هم یکی از مزیتهای پروژههای سورس باز است)
Strong Name
System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35
برای استفاده از این تکنولوژی ابتدا نیاز است تا یک جفتکلید عمومی/خصوصی (توسط ادمین، منبع گواهینامهها، یک بانک یا یک ابزار خاص) فراهم شود تا از آن برای اینکریپشن استفاده شود. سپس دادههای موردنظر (هر داده کلی که قصد ارسال و توزیع آن را داریم مثل یک اسمبلی) با استفاده از یک الگوریتم هشکردن (مثل MD5، SHA یا ترکیبی از آنها، هرچند MD5 توصیه نمیشود) پردازش شده و یک هشکد مخصوص تولید میشود. این هشکد با استفاده از کلید خصوصی دردسترس اینکریپت میشود و به عنوان یک امضای دیجیتال به همراه داده موردنظر ارسال یا توزیع میشود. در سمت مصرف کننده که با استفاده از یک روش خاص و امن به کلید عمومی دسترسی پیدا کرده است عملیات دیکریپت کردن این امضای دیجیتال با استفاده از کلید عمومی انجام شده و هشکد مربوطه بدست میآید. همچنین عملیات تولید هشکد با استفاده از دادهها در سمت مصرف کننده انجام شده و هشکد دادهها نیز دوباره با استفاده از همان الگوریتم استفاده شده در سمت توزیعکننده تولید میشود. سپس این دو مقدار محاسبه شده در سمت مصرفکننده با یکدیگر مقایسه شده و درصورت برابر بودن میتوان اطمینان حاصل کرد همان دادهای که توزیع کننده در اصل ارسال کرده بدون تغییر به دست مصرف کننده رسیده است. درواقع ویژگی اینکریپت/دیکریپت کردن دادهها توسط جفتکلید این است که بهصورت یکطرفه بوده و دادههای اینکریپت شده با استفاده از یک کلید خصوصی را تنها با استفاده از کلید عمومی همان کلید خصوصی میتوان بدرستی دیکریپت کرد.
1. تولید و مدیریت جفتکلیدهای قوی- نامگذاریشده (Strongly Named Key Pairs)
همانطور که در قسمت قبل اشاره شد برای نامگذاری قوی یک اسمبلی به یک کلید عمومی (public key) و یک کلید خصوصی (private key) که در مجموع به آن یک جفت کلید (key pair) میگویند، نیاز است.برای اینکار میتوان با استفاده از برنامه sn.exe (عنوان کامل آن Microsoft .Net Framework Strong Name Utility است) یک جفت کلید تولید کرده و آن را در یک فایل و یا در CSP (یا همان cryptographic service provider) ذخیره کرد. همچنین اینکار را میتوان توسط ویژوال استودیو نیز انجام داد. امکان موردنظر در فرم پراپرتی یک پروژه و در تب Signing آن وجود دارد.
نکته: یک CSP عنصری از API کریپتوگرافی ویندوز (Win32 CryptoAPI) است که سرویسهایی چون اینکریپشن، دیکریپشن، و تولید امضای دیجیتال را فراهم میکند. این پرووایدرها همچنین تسهیلاتی برای مخازن کلیدها فراهم میکنند که از اینکریپشنهای قوی و ساختار امنیتی سیستم عامل (سیستم امنیتی و دسترسی کاربران ویندوز) برای محافظت از تمام کلیدهای کریپتوگرافی ذخیره شده در مخزن استفاده میکند. بهطور خلاصه و مفید میشود اشاره کرد که میتوان کلیدهای کریپتوگرافی را درون یک مخزن کلید CSP ذخیره کرد و تقریبا مطمئن بود که تا زمانیکه هیچکس کلمه عبور سیستم عامل را نداند، این کلیدها امن خواهند ماند. برای کسب اطلاعات بیشتر به دادههای CryptoAPI در اسناد SDK سیستم عامل خود مراجعه کنید.
برنامه sn به همراه SDKهای ویندوز نصب میشود. البته با نصب ویژوال استودیو تمام SDKهای موردنیاز مطابق با نسخههای موجود، نصب خواهد شد. مسیر نسخه 4 و 32 بیتی این برنامه در سیستم عامل Windows 7 بهصورت زیر است:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\sn.exe
با استفاده از آرگومان k همانند دستور زیر یک جفتکلید جدید تولید شده و در فایل MyKeys.snk در ریشه درایو d: ذخیره میشود:
sn –k d:\MyKeys.snk
نکته: به بزرگی و کوچکی حروف سوییچهای دستورات برنامه sn دقت کنید!
این کار یک جفت کلید کریپتوگرافی 1024 بیتی بهصورت تصادفی تولید میکند. این دستور را باید در خط فرمانی (Command Prompt) اجرا نمود که مسیر فایل sn.exe را بداند. برای راحتی کار میتوان از خط فرمان ویژوال استودیو (Visual Studio Command Prompt) استفاده کرد.
نکته: اجرای عملیات فوق در یک شرکت یا قسمت توسعه یک شرکت، تنها یک بار نیاز است زیرا تمام اسمبلیهای تولیدی تا زمانیکه عناوین ساده متمایزی دارند میتوانند از یک جفت کلید مشترک استفاده کنند.
نکته: هرچند که میتوان از پسوندهای دیگری نیز برای نام فایل حاوی جفت کلید استفاده کرد، اما توصیه میشود از همین پسوند snk. استفاده شود.
فایل تولید شده حاوی هر دو کلید «عمومی» و «خصوصی» است. میتوان با استفاده از دستور زیر کلید عمومی موجود در فایل mykeys.snk را استخراج کرده و در فایل mypublickey.snk ذخیره کرد:
sn –p d:\mykeys.snk d:\mypublickey.snk
sn -tp MyPublicKey.snk
sn -i MyKeys.snk MyStrongNameKeys
sn –m n
sn –m y
sn -d MyStrongNameKeys
نکته: برای استفاده از این ویژگی در ویژوال استودیو، باید در تب Signing در تنظیمات پروژه گزینه Sign the Assembly را انتخاب کرد. سپس میتوان فایل حاوی جفت کلیدهای تولیدشده را انتخاب یا فایل جدیدی تولید کرد. البته ویژوال استودیو تا نسخه 2010 امکانی جهت استفاده از مخازن CSP را ندارد.
[assembly:AssemblyKeyFileAttribute("MyKeys.snk")]
sn –vf MyAsm.exe
Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Failed to verify assembly -- Strong name validation failed for assembly MyAsm.exe'.
sn –p d:\MyKeys.snk d:\MyPublicKey.snk sn –pc MyKeysContainer d:\MyPublicKey.snk
csc.exe /delaysign /keyfile:d:\MyPublicKey.snk /out:d:\MyAsm.exe d:\Class1.cs
al /out:<assembly name> <module name> /keyfile:<file name>
sn –Vr d:\MyAsm.exe
sn –R d:\MyAsm.exe MyKeys.snk sn –R d:\MyAsm.exe MyKeysContainer
sn –D assembly1 assembly2
sn –Vu d:\MyAsm.exe
sn –Vx
sn –Vl
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\gacutil.exe
gacutil /i c:\MyAsm.dll
gacutil /u MyAsm
gacutil /u MyAsm,Version=1.3.0.5
gacutil /l
gacutil /l MyAsm
معرفی ELMAH
http://nuget.org/packages/elmah
- Pre-alpha
این مرحله شامل تمام فعالیتهای انجام شده قبل از مرحله تست میباشد. در این دوره آنالیز نیازمندیها، طراحی نرم افزار، توسعه نرم افزار و حتی تست واحد باشد. در نرم افزارهای سورس باز چندین نسخه قبل از آلفا ممکن است عرضه شوند. - Alpha
این مرحله شامل همه فعالیتها از زمان شروع تست میباشد. البته منظور از تست، تست تیمی و تست خود نرم افزار میباشد. نرم افزارهای آلفا هنوز ممکن است خطا و اشکالاتی داشته باشند و ممکن است اطلاعات شما از بین رود. در این مرحله امکانات جدیدی مرتبا به نرم افزار اضافه میگردد. - Beta
نرم افزار بتا، همه قابلیتهای آن تکمیل شده و خطاهای زیادی برای کامل شدن نرم افزار وجود دارد. در این مرحله بیشتر به تست کاهش تاثیرات به کاربران و تست کارایی دقت میشود. نسخه بتا، اولین نسخهای خواهد بود که بیرون شرکت و یا سازمان در دسترس قرار میگیرد. برخی توسعه دهندگان به این مرحله preview، technical preview یا early access نیز میگویند. - Release candidate
در این مرحله نرم افزار، آماده عرضه به مصرف کنندگان است و نرم افزارهایی مثل سیستم عاملهای ویندوز در دسترس تولید کنندگان قرار گرفته تا با جدیدترین سخت افزار خود یکپارچه شوند. -
General availability (GA)
در این مرحله، عرضه عمومی نرم افزار و بازاریابی و فروش نرم افزار مد نظر است و علاوه بر این تست امنیتی و در نرم افزارهای خیلی بزرگ عرضه جهانی صورت میگیرد
- Major Version
وقتی افزایش مییابد که تغییرات قابل توجهی در نرم افزار ایجاد شود - Minor Version
وقتی افزایش یابد که ویژگی جزئی یا اصلاحات قابل توجهی به نرم افزار ایجاد شود. - Build Number
به ازای هر بار ساخته شدن پروژه افزایش مییابد. - Revision
وقتی افزایش مییابد که نواقص و باگهای کوچکی رفع شوند.
major.minor[.build[.reversion]]
major.minor[.maintenance[.build]]
به عنوان یک راه حل، مجموعهی سادهای از قوانین و الزامات که چگونگی طراحی شمارههای نسخه و افزایش آن را مشخص میکند، وجود دارد. برای کار کردن با این سیستم، شما ابتدا نیاز به اعلام API عمومی دارید. این خود ممکن است شامل مستندات و یا اجرای کد باشد.
علیرغم آن، مهم است که این API، روشن و دقیق باشد. هنگامیکه API عمومی خود را تعیین کردید، تغییرات برنامه شما بر روی نسخه API عمومی تاثیر خواهد داشت و آنرا افزایش خواهد داد. بر این اساس، این مدل نسخهبندی را در نظر بگیرید: X.Y.Z یعنی (Major.Minor.Patch).
رفع حفرههایی که بر روی API عمومی تاثیر نمیگذارند، مقدار Patch را افزایش میدهند، تغییرات جدیدی که سازگار با نسخه قبلی است، مقدار Minor را افزایش میدهند و تغییرات جدیدی که کاملا بدیع هستند و به نحوی با تغییرات قبلی سازگار نیستند مقدار Major را افزایش میدهند.
- نرمافزارهایی که از نسخه بندی معنایی استفاده میکنند، باید یک API عمومی داشته باشند. این API میتواند در خود کد یا و یا به طور صریح در مستندات باشد که باید دقیق و جامع باشد.
- یک شماره نسخه صحیح باید به شکل X.Y.Z باشد که در آن X،Y و Z اعداد صحیح غیر منفی هستند. X نسخهی Major میباشد، Y نسخهی Minor و Z نسخهی Patch میباشد. هر عنصر باید یک به یک و بصورت عددی افزایش پیدا کند. به عنوان مثال: 1.9.0 -> 1.10.0 -> 1.11.0
- هنگامی که به یک نسخهی Major یک واحد اضافه میشود، نسخهی Minor و Patch باید به حالت 0 (صفر) تنظیم مجدد گردد. هنگامی که به شماره نسخهی Minor یک واحد اضافه میشود، نسخهی Patch باید به حالت 0 (صفر) تنظیم مجدد شود. به عنوان مثال: 1.1.3 -> 2.0.0 و 2.1.7 -> 2.2.0
- هنگامیکه یک نسخه از یک کتابخانه منتشر میشود، محتوای کتابخانه مورد نظر نباید به هیچ وجه تغییری داشته باشد. هر گونه تغییر جدیدی باید در قالب یک نسخه جدید انتشار پیدا کند.
- نسخهی Major صفر (0.Y.Z) برای توسعهی اولیه است. هر چیزی ممکن است در هر زمان تغییر یابد. API عمومی را نباید پایدار در نظر گرفت.
- نسخه 1.0.0 در حقیقت API عمومی را تعریف میکند. چگونگی تغییر و افزایش هر یک از نسخهها بعد از انتشار این نسخه، وابسته به API عمومی و تغییرات آن میباشد.
- نسخه Patch یا (x.y.Z | x > 0) فقط در صورتی باید افزایش پیدا کند که تغییرات ایجاد شده در حد برطرف کردن حفرههای نرمافزار باشد. برطرف کردن حفرههای نرمافزار شامل اصلاح رفتارهای اشتباه در نرمافزار میباشد.
- نسخه Minor یا (x.Y.z | x > 0) فقط در صورتی افزایش پیدا خواهد کرد که تغییرات جدید و سازگار با نسخه قبلی ایجاد شود. همچنین این نسخه باید افزایش پیدا کند اگر بخشی از فعالیتها و یا رفتارهای قبلی نرمافزار به عنوان فعالیت منقرض شده اعلام شود. همچنین این نسخه میتواند افزایش پیدا کند اگر تغییرات مهم و حیاتی از طریق کد خصوصی ایجاد و اعمال گردد. تغییرات این نسخه میتواند شامل تغییرات نسخه Patch هم باشد. توجه به این نکته ضروری است که در صورت افزایش نسخه Minor، نسخه Patch باید به 0 (صفر) تغییر پیدا کند.
- نسخه Major یا (X.y.z | X > 0) در صورتی افزایش پیدا خواهد کرد که تغییرات جدید و ناهمخوان با نسخه فعلی در نرمافزار اعمال شود. تغییرات در این نسخه میتواند شامل تغییراتی در سطح نسخه Minor و Patch نیز باشد. باید به این نکته توجه شود که در صورت افزایش نسخه Major، نسخههای Minor و Patch باید به 0 (صفر) تغییر پیدا کنند.
- یک نسخه قبل از انتشار میتواند توسط یک خط تیره (dash)، بعد از نسخه Patch (یعنی در انتهای نسخه) که انواع با نقطه (dot) از هم جدا میشوند، نشان داده شود. نشانگر نسخه قبل از انتشار باید شامل حروف، اعداد و خط تیره باشد [0-9A-Za-z-]. باید به این نکته دفت داشت که نسخههای قبل از انتشار خود به تنهایی یک انتشار به حساب میآیند اما اولویت و اهمیت نسخههای عادی را ندارد. برای مثال: 1.0.0-alpha ، 1.0.0-alpha.1 ، 1.0.0-0.3.7 ، 1.0.0-x.7.z.92
- یک نسخه Build میتواند توسط یک علامت مثبت (+)، بعد از نسخه Patch یا نسخه قبل از انتشار (یعنی در انتهای نسخه) که انواع آن با نقطه (dot) از هم جدا میشوند، نشان داده شود. نشانگر نسخه Build باید شامل حروف، اعداد و خط تیره باشد [0-9A-Za-z-]. باید به این نکته دقت داشت که نسخههای Build خود به تنهایی یک انتشار به حساب میآیند و اولویت و اهمیت بیشتری نسبت به نسخههای عادی دارند. برای مثال: 1.0.0+build.1 ، 1.3.7+build.11.e0f985a
- اولویتبندی نسخهها باید توسط جداسازی بخشهای مختلف یک نسخه به اجزای تشکیل دهنده آن یعنی Minor، Major، Patch، نسخه قبل از انتشار و نسخه Build و ترتیب اولویت بندی آنها صورت گیرد. نسخههای Minor، Major و Patch باید بصورت عددی مقایسه شوند. مقایسه نسخههای قبل از انتشار و نسخه Build باید توسط بخشهای مختلف که توسط جداکنندهها (نقطههای جداکننده) تفکیک شده است، به این شکل سنجیده شود:
بخشهایی که فقط حاوی عدد هستند، بصورت عددی مقایسه میشوند و بخشهایی که حاری حروف و یا خط تیره هستند بصورت الفبایی مقایسه خواهند شد.
بخشهای عددی همواره اولویت پایینتری نسبت به بخشهای غیر عددی دارند. برای مثال:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a
منبع نسخه بندی معنایی : semver.org