مطالب
لیست شماره نگارش‌های دات نت فریم ورک تا این تاریخ

از زمانیکه دات نت فریم ورک ارائه شده (حدودا 8 سال یا بیشتر اگر بتای آن‌را هم به حساب بیاوریم به سال 2000 بر می‌گردد)، نگارش‌های متفاوتی تا به امروز در اختیار عموم قرار گرفته اند.
جدول زیر این موارد را تا این تاریخ لیست کرده و شماره نگارش دقیق آن‌ها را نیز بر می‌شمارد:

.NET version

Actual version

3.5 SP1

3.5.30729.1

3.5

3.5.21022.8

3.0 SP2

3.0.4506.2152

3.0 SP1

3.0.4506.648

3.0

3.0.4506.30

2.0 SP2

2.0.50727.3053

2.0 SP1

2.0.50727.1433

2.0

2.0.50727.42

1.1 SP1

1.1.4322.2032

1.1 SP1 (in 32 bit version of Windows 2003)

1.1.4322.2300

1.1

1.1.4322.573

1.0 SP3

1.0.3705.6018

1.0 SP2

1.0.3705.288

1.0 SP1

1.0.3705.209

1.0

1.0.3705.0


برای بدست آوردن شماره نگارش‌های نصب شده بر روی یک کامپیوتر متاسفانه راه ساده‌‌ای وجود ندارد. امکاناتی هم که خود دات نت فریم ورک به صورت ذاتی ارائه می‌دهد به صورت زیر است:

class NetVersion
{
public static string Version
{
get
{
return Environment.Version + "\n" +
Environment.OSVersion;
}
}
}

که خروجی آن فقط آخرین نگارش CLR را شامل می‌شود.
برای مثال روی ویندوز اکس پی سرویس پک 3 با دات نت فریم ورک سه و نیم، سرویس پک یک خواهیم داشت:
2.0.50727.3053
Microsoft Windows NT 5.1.2600 Service Pack 3
که عدد نگارش ارائه شده با دات نت فریم ورک 2 سرویس پک 2 تطابق دارد. به عبارت دیگر آخرین نگارش CLR هنوز همان 2 است و موارد دیگر (مثل wf و wcf و ...) فقط یک سری افزونه برای این هسته به شمار می‌روند.
خوبی این روش هم این است که اگر در یک هاست اینترنتی قصد داشتید شماره نگارش دات نت فریم ورک سرور را بررسی کنید، بدون مشکل پاسخ خواهد داد. برای مثال اگر به دات نت فریم ورک 2 سرویس پک 2 رسیدید، یعنی دات نت فریم ورک سه و نیم، سرویس پک یک حتما روی سرور نصب است، چون این دو با هم ارائه شده‌اند و به صورت مجزا ارائه نشده‌اند.

برای بدست‌ آوردن لیست دات نت فریم ورک‌های مختلف باید به رجیستری ویندوز مراجعه کرد. مسیرهای:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform


این روش یا حتی لیست کردن فولدرهای نصب شد در مسیر C:\WINDOWS\Microsoft.NET\Framework نیز شماره نگارش کامل را ارائه نمی‌دهند. تنها راه باقیمانده مراجعه به فایل mscorlib.dll هر پوشه و بررسی نگارش آن است:



اینکار را با برنامه نویسی به صورت زیر می‌توان انجام داد:

public static string MscorlibVersion
{
get
{
//using System.Diagnostics;
FileVersionInfo myFileVersionInfo = FileVersionInfo.GetVersionInfo(
Environment.GetEnvironmentVariable("windir") +
@"\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll");
return myFileVersionInfo.ProductVersion;
}
}

پاسخ به بازخورد‌های پروژه‌ها
مشکل در IDENTITY و سیستم کاربران
- لطفا از این قسمت برای انجمن پرسش و پاسخ استفاده نکنید. این سایت، انجمن عمومی نیست.
- قسمت پروژه‌ها فقط مرتبط هست به مشکلات پروژه‌ها و هیچ هدف دیگری ندارد. لطفا رعایت کنید.
عدم رعایت این مساله در آینده، سبب حذف شما از سایت خواهد شد.
سایت ما هدف تبدیل شدن به انجمن عمومی پرسش و پاسخ را ندارد. از روز اول نداشته‌است. 

- این پروژه از روش دات نت 4 استفاده می‌کند. به عبارتی از ASP.NET Identity نوشته شده برای دات نت 4.5 به بعد کمک نگرفته‌است و از روش Forms authentication استفاده می‌کند. اطلاعات بیشتر
- برای استفاده از کلاس‌های شخصی در ASP.NET Identity به این مقاله مراجعه کنید.
نظرات مطالب
امکان تعریف اعضای static abstract در اینترفیس‌های C# 11
اضافه شدن Generic Parsing به دات نت 7

تا قبل از دات نت 7، متدهای Parse و TryParse جزو استاندارد اغلب نوع‌ها در دات نت بودند؛ اما امکان استفاده‌ی جنریک از آن‌ها وجود نداشت. این مشکل به لطف وجود اعضای استاتیک اینترفیس‌ها در دات نت 7 و C# 11 برطرف شده‌است. برای این منظور دو اینترفیس جدید System.IParsable و System.ISpanParsable به دات نت 7 اضافه شده‌اند که امکان دسترسی به متد T.Parse را میسر می‌کنند.
دو نمونه مثال از نحوه‌ی استفاده‌ی از این API جدید را در ادامه مشاهده می‌کنید:
public static T ParseIt<T>(string content, IFormatProvider? provider) where T : IParsable<T>
{
   return T.Parse(content, provider);
}

public IEnumerable<T> ParseCsvRow<T>(string content, IFormatProvider? provider) where T : IParsable<T>
{
   return content.Split(',').Select(str => T.Parse(str, provider));
}
اگر می‌خواستیم متد ParseIt را به صورت جنریک و بدون استفاده از ویژگی‌های جدید زبان #C و دسترسی مستقیم به T.Parse بنویسیم، یک روش آن، استفاده از Reflection به صورت زیر می‌بود:
public static T ParseIt<T>(string content, IFormatProvider? provider)
{
   var type = typeof(T);
   var method = type.GetMethod("Parse", BindingFlags.Static | BindingFlags.Public,
     new[] { typeof(string), typeof(IFormatProvider) });
   return (T)method!.Invoke(null, new object?[] { content, provider })!;
}
مطالب
اضافه کردن Net 4.5. و بالاتر به پروژه ستاپ ویژوال استودیو 2010
در این مطلب یک ترفند ساده و سریع برای دوستانی که می‌خواهند از ویژوال استودیو 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 اضافه شده است.
 
نظرات مطالب
روش نصب NET SDK. بر روی لینوکس Ubuntu

برای نصب از طریق دانلود فایل های دات نت به صورت آفلاین بر روی سرور بدون اینترنت میتوانید از روش زیر هم استفاده کنید.

  • ابتدا فایل های دات نت رو بسته به معماری سیستم دانلود کنید. (Arm32 | Arm32 Alpine | Arm64 | Arm64 Alpine | x64 | x64 Alpine)
  • سپس فایل دات نت رو به سرور خود منتقل کنید و از طریق دستورات زیر، خط فرمان dotnet رو به ترمینال اضافه کنید:
export DOTNET_ROOT="$HOME/yourpath/dotnet"
export PATH="$PATH:$HOME/yourpath/dotnet"

مشابه با Edit the system environment variables در ویندوز

و اکنون با نوشتن دستور dotnet --version میتوانید نگارش ورژن دات رو مشاهده کنید.

همچنین اگر نیاز به نصب tools هایی مانند ef core نیاز دارید میتوانید از دستور زیر استفاده کنید:

dotnet tool install --global dotnet-ef
export PATH="$PATH:$HOME/.dotnet/tools"

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

نظرات مطالب
مقایسه امنیت Oracle11g و SQL server 2008 از دید آمار در سال 2009
کم شدن باگ‌های امنیتی مایکروسافت در چند سال اخیر سه دلیل عمده داشته:
- استفاده بیشتر از دات نت فریم ورک در محصولات عمده خودش (اس کیوال سرور، exchange server، SharePoint و ...). برای مثال دات نت فریم ورک به حملات سرریز بافر (اگر کد خالص دات نتی باشد و از API ویندوز به صورت ناشیانه استفاده نکرده باشد) مقاوم است و خیلی مسایل دیگر که به صورت توکار در دات نت لحاظ شده.
- وضع کردن یک سری قوانین سفت و سخت در مورد کتابخانه‌ها و توابع C مورد استفاده در محصولات نوشته شده با سی و CPP
https://www.dntips.ir/2009/05/bannedh.html
- تهیه برنامه‌هایی که کار آنالیز خودکار فایل‌های باینری و همچنین سورس‌ کدهای سازمان آن‌را انجام می‌دهند. به این صورت قبل از اینکه دیگران از سیستم‌های آن‌ها باگ‌های متداول را درآورند، خودشان نسبت به اینکار اقدام می‌کنند.
http://blogs.msdn.com/bharry/archive/2009/10/02/two-free-security-tools-from-microsoft-sdl-team.aspx
https://www.dntips.ir/2009/11/blog-post.html
پروژه‌ها
ادغام، اضافه کردن و جدا کردن صفحات PDF
این پروژه ساده را به صورت Windows Form Application و با زبان Python ساختم. می‌تواند مثالی باشد برای کسانی که میخواهند پایتون را در ویندوز یاد بگیرند و اجرا کنند. اگر کسی پروژه را امتحان کرد، خوشحال خواهم شد خطا‌ها و اشکالات را اینجا اعلام کند.
  1. ادغام چند فایل PDF به صورت فایل واحد (Merging)
  2. اضافه کردن یک فایل PDF به یک فایل موجود (Appending)
  3. جدا کردن صفحات دلخواه از یک فایل و ذخیره آنها در یک فایل جدا (Splitting)
نحوه اجرا: 
  1. در صورت نصب امکانات پایتون برای ویژوال استودیو مثل سایر پروژه‌های دات نت قابل اجرا و دیباگ است.
  2. از طریق خط فرمان  و دستور ipy که در ادامه مثالی میزنم.
  3. من خودم از طریق یک برنامه کنسول ساده پروژه را خارج از محیط توسعه اجرا میکنم که در ادامه مثالی میزنم.
 اجرا از خط فرمان:
  ipy C:\\PdfTools\\PdfTools.py

اجرا از برنامه کنسول:
var process = new Process();
var startInfo = new ProcessStartInfo
      {
            WindowStyle = ProcessWindowStyle.Hidden,
            FileName = "CMD.exe",
            Arguments = "/C ipy C:\\PdfTools\\PdfTools.py"
      };
process.StartInfo = startInfo;
process.Start();
نکته: در صورتی که بخواهید از برنامه کنسول برای اجرا استفاده کنید آیکن‌های برنامه باید در پوشه Debug وجود داشته باشند! 

مطالب
مروری بر کاربردهای Action و Func - قسمت اول
delegate‌ها، نوع‌هایی هستند که ارجاعی را به یک متد دارند؛ بسیار شبیه به function pointers در C و CPP هستند، اما برخلاف آن‌ها، delegates شی‌ء‌گرا بوده، به امضای متد اهمیت داده و همچنین کد مدیریت شده و امن به شمار می‌روند.
سیر تکاملی delegates را در مثال ساده زیر می‌توان ملاحظه کرد:
using System;

namespace ActionFuncSamples
{
    public delegate int AddMethodDelegate(int a);
    public class DelegateSample
    {
        public void UseDelegate(AddMethodDelegate addMethod)
        {
            Console.WriteLine(addMethod(5));
        }
    }

    public class Helper
    {
        public int CustomAdd(int a)
        {
            return ++a;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Helper helper = new Helper();

            // .NET 1            
            AddMethodDelegate addMethod = new AddMethodDelegate(helper.CustomAdd);
            new DelegateSample().UseDelegate(addMethod);

            // .NET 2, anonymous delegates
            new DelegateSample().UseDelegate(delegate(int a) { return helper.CustomAdd(a); });

            // .NET 3.5
            new DelegateSample().UseDelegate(a => helper.CustomAdd(a));
        }
    }
}
معنای کلمه delegate، واگذاری مسئولیت است. به این معنا که ما در متد UseDelegate، نمی‌دانیم addMethod به چه نحوی تعریف خواهد شد. فقط می‌دانیم که امضای آن چیست.
در دات نت یک، یک وهله از شیء AddMethodDelegate ساخته شده و سپس متدی که امضایی متناسب و متناظر با آن را داشت، به عنوان متد انجام دهنده مسئولیت معرفی می‌شد. در دات نت دو، اندکی نحوه تعریف delegates با ارائه delegates بی‌نام، ساده‌تر شد و در دات نت سه و نیم با ارائه lambda expressions ، تعریف و استفاده از delegates باز هم ساده‌تر و زیباتر گردید.
به علاوه در دات نت 3 و نیم، دو Generic delegate به نام‌های Action و Func نیز ارائه گردیده‌اند که به طور کامل جایگزین تعریف طولانی delegates در کدهای پس از دات نت سه و نیم شده‌اند. تفاوت‌های این دو نیز بسیار ساده است:
اگر قرار است واگذاری قسمتی از کد را به متدی محول کنید که مقداری را بازگشت می‌دهد، از Func و اگر این متد خروجی ندارد از Action استفاده نمائید:
Action<int> example1 = x => Console.WriteLine("Write {0}", x);
example1(5);

Func<int, string> example2 = x => string.Format("{0:n0}", x);
Console.WriteLine(example2(5000));
در دو مثال فوق، نحوه تعریف inline یک Action و یا Func را ملاحظه می‌کنید. Action به متدی اشاره می‌کند که خروجی ندارد و در اینجا تنها یک ورودی int را می‌پذیرد. Func در اینجا به تابعی اشاره می‌کند که یک ورودی int را دریافت کرده و یک خروجی string را باز می‌گرداند.

پس از این مقدمه، در ادامه قصد داریم مثال‌های دنیای واقعی Action و Func را که در سال‌های اخیر بسیار متداول شده‌اند، بررسی کنیم.


مثال یک) ساده سازی تعاریف API ارائه شده به استفاده کنندگان از کتابخانه‌های ما
عنوان شد که کار delegates، واگذاری مسئولیت انجام کاری به کلاس‌های دیگر است. این مورد شما را به یاد کاربردهای interfaceها نمی‌اندازد؟
در interfaceها نیز یک قرارداد کلی تعریف شده و سپس کدهای یک کتابخانه، تنها با امضای متدها و خواص تعریف شده در آن کار می‌کنند و کتابخانه ما نمی‌داند که این متدها قرار است چه پیاده سازی خاصی را داشته باشند.
برای نمونه طراحی API زیر را درنظر بگیرید که در آن یک interface جدید تعریف شده که تنها حاوی یک متد است. سپس کلاس Runner از این interface استفاده می‌کند:
using System;

namespace ActionFuncSamples
{
    public interface ISchedule
    {
        void Run();
    }

    public class Runner
    {
        public void Exceute(ISchedule schedule)
        {
            schedule.Run();
        }
    }

    public class HelloSchedule : ISchedule
    {
        public void Run()
        {
            Console.WriteLine("Just Run!");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            new Runner().Exceute(new HelloSchedule());
        }
    }
}
در اینجا ابتدا باید این interface را در طی یک کلاس جدید (مثلا HelloSchedule) پیاده سازی کرد و سپس حاصل را در کلاس Runner استفاده نمود.
نظر شما در مورد این طراحی ساده شده چیست؟
using System;

namespace ActionFuncSamples
{
    public class Schedule
    {
        public void Exceute(Action run)
        {
            run();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            new Schedule().Exceute(() => Console.WriteLine("Just Run!"));
        }
    }
}
با توجه به اینکه هدف از معرفی interface در طراحی اول، واگذاری مسئولیت نحوه تعریف متد Run به کلاسی دیگر است، به همین طراحی با استفاده از یک Action delegate نیز می‌توان رسید. مهم‌ترین مزیت آن، حجم بسیار کمتر کدنویسی استفاده کننده نهایی از API تعریف شده ما است. به علاوه امکان inline coding نیز فراهم گردیده است و در همان محل تعریف Action، بدنه آن‌را نیز می‌توان تعریف کرد.
بدیهی است delegates نمی‌توانند به طور کامل جای interfaceها را پر کنند. اگر نیاز است قرارداد تهیه شده بین ما و استفاده کنندگان از کتابخانه، حاوی بیش از یک متد باشد، استفاده از interfaceها بهتر هستند.
از دیدگاه بسیاری از طراحان API، اشیاء delegate معادل interface ایی با یک متد هستند و یک وهله از delegate معادل وهله‌ای از کلاسی است که یک interface را پیاده سازی کرده‌است.
علت استفاده بیش از حد interfaceها در سایر زبان‌ها برای ابتدایی‌ترین کارها، کمبود امکانات پایه‌ای آن زبان‌ها مانند نداشتن lambda expressions، anonymous methods و anonymous delegates هستند. به همین دلیل مجبورند همیشه و در همه‌جا از interfaceها استفاده کنند.

ادامه دارد ...

 
مطالب
پیش‌نیازهای نصب SharePoint 2010

نسخه‌ی بتای شیرپوینت 2010 که با نام رمز Fourteen تهیه شده، مدتی است که در دسترس عموم می‌باشد. همانطور که مطلع هستید، از نام این محصول کلمه آفیس حذف و تبدیل به Microsoft SharePoint Server شده است (البته در نگارش نهایی آن).
پس از دریافت این محصول که فقط به صورت 64 بیتی ارائه خواهد شد، بر روی ویندوز سرور 2003 نگارش 64 بیتی نصب نشد.







برای نصب آن نیاز به پیش نیازهای زیر است:
  • ویندوز سرور 2008 نگارش 64 بیتی (معمولی یا R2)
  • نسخه‌های 64 بیتی اس کیوال سرور 2008 یا 2005
  • IIS7 و دات نت فریم ورک 3 و نیم
ظاهر آن‌را می‌شود نسخه‌ی Ajax ایی شیرپوینت 2007 به همراه ریبون‌های جدید آفیس به شماره آورد، به همین منظور نیاز است تا کلاینت‌های شما IE خود را حتما از نگارش 6 به نگارش‌های بالاتر ارتقاء بدهند. (اگر تابحال اینکار را نکرده‌اند و با IE6 سازگار نیست)


سایر موارد مورد نیاز را به صورت خودکار از اینترنت دریافت کرده و نصب می‌کند. کلا پروسه نصب مشابهی با شیرپوینت 2007 دارد.
و به صورت خلاصه اگر قصد استفاده از اکثر محصولات جدید مایکروسافت را دارید، باید سخت افزار و سیستم عامل 64 بیتی را تهیه نمائید.