نظرات اشتراک‌ها
ReSharper Ultimate 10.0.1 منتشر شد
سیستم کار با نسخه‌ی 10 اون کمی فرق کرده. نیاز به یک سری فایل رجیستری داره تا نسخه‌ی آزمایشی اون 30 هزار روزه بشه: ReSharperUltimate.10.7z

پاسخ به بازخورد‌های پروژه‌ها
بروز خطا هنگام افزودن نقش جدید
سلام.
بله این پروژه دارای مشکلاتی است. قصد من از قرار دادن این پروژه به صورت آزمایشی این بود که سر نخ را برای کسانی که می‌خواهند به این شکل پروژه پیاده سازی کنند، به دست بیارند و ساختار کلی پیاده سازی آن را در یابند.
نظرات نظرسنجی‌ها
کدامیک از سرویس دهنده‌های ابری زیر را پیشنهاد می‌کنید
بله. جدیدا بصورت آزمایشی اضافه شده. کار کردن باهاش خیلی راحته و از طریق cli خیلی راحت deploy میشه. ولی فعلا SLI تهیه نشده و در مورد production نمیشه نظری داد.
مطالب
امکان رمزنگاری اطلاعات شخصی کاربران در ASP.NET Core Identity 2.1
از نگارش ASP.NET Core Identity 2.1 به بعد، ویژگی جدید ProtectedPersonalData در تعاریف موجودیت کاربران سیستم مشاهده می‌شود:
public class IdentityUser<TKey> where TKey : IEquatable<TKey>
{
    [ProtectedPersonalData]
    public virtual string UserName { get; set; }

    [ProtectedPersonalData]
    public virtual string Email { get; set; }
این ویژگی در حقیقت یک نشانه‌گذار است. کار آن اعلام نیاز به ذخیره سازی رمزنگاری شده‌ی اینگونه اطلاعات در بانک اطلاعاتی، جهت محافظت از اطلاعات شخصی کاربران سیستم، در حین دسترسی‌های غیرمجاز می‌باشد.


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

اگر برنامه‌ی پیشین خود را به نگارش‌های جدیدتر ASP.NET Core Identity ارتقاء داده باشید، احتمالا متوجه وجود یک چنین قابلیتی نشده‌اید؛ چون به صورت پیش‌فرض غیرفعال است. برای فعالسازی آن، می‌توان به صورت زیر عمل کرد:
services.AddIdentity<IdentityUser, IdentityRole>(options =>
{
   options.Stores.ProtectPersonalData = true;
   // ...
})


ویژگی ProtectedPersonalData چگونه به صورت خودکار پردازش می‌شود؟

پیشنیاز درک نحوه‌ی پردازش ویژگی ProtectedPersonalData، مطلب «رمزنگاری خودکار فیلدها توسط Entity Framework Core» است. در اینجا نیز دقیقا یک «تبدیلگر مقدار» برای رمزنگاری و رمزگشایی خودکار فیلدهای مزین به ProtectedPersonalData تدارک دیده شده‌است:
private class PersonalDataConverter : ValueConverter<string, string>
{
  public PersonalDataConverter(IPersonalDataProtector protector) :
      base(s => protector.Protect(s), s => protector.Unprotect(s), default)
      { }
}

سپس در IdentityUserContext تعریف شده و متد OnModelCreating آن، ابتدا بررسی می‌کند که آیا پیشتر ProtectPersonalData را به true تنظیم کرده‌اید یا خیر؟ اگر بله، تمام خواصی را که با ویژگی ProtectedPersonalDataAttribute مزین شده‌اند، یافته و سپس توسط متد HasConversion به آن‌ها تبدیلگر مقداری از نوع PersonalDataConverter را اضافه می‌کند:
        protected override void OnModelCreating(ModelBuilder builder)
        {
            var encryptPersonalData = storeOptions?.ProtectPersonalData ?? false;

            builder.Entity<TUser>(b =>
            {
                if (encryptPersonalData)
                {
                    converter = new PersonalDataConverter(this.GetService<IPersonalDataProtector>());
                    var personalDataProps = typeof(TUser).GetProperties().Where(
                                    prop => Attribute.IsDefined(prop, typeof(ProtectedPersonalDataAttribute)));
                    foreach (var p in personalDataProps)
                    {
                        if (p.PropertyType != typeof(string))
                        {
                            throw new InvalidOperationException(Resources.CanOnlyProtectStrings);
                        }
                        b.Property(typeof(string), p.Name).HasConversion(converter);
                    }
                }
// ...


سرویس پیش‌فرض IPersonalDataProtector در ASP.NET Core Identity

اگر در کدهای فوق، به جائیکه new PersonalDataConverter نوشته شده دقت کنید؛ یک سرویس از نوع IPersonalDataProtector را دریافت می‌کند که توسط آن دو متد Protect و Unprotect به کلاس خصوصی PersonalDataConverter تزریق می‌شوند:
public interface IPersonalDataProtector
{
   string Protect(string data);
   string Unprotect(string data);
}
 پیاده سازی پیش‌فرض این سرویس رمزنگاری را در اینجا می‌توانید مشاهده کنید.


تاثیر فعالسازی ProtectPersonalData بر روی سایر سرویس‌های ASP.NET Core Identity

اگر options.Stores.ProtectPersonalData را به true تنظیم کنید، سرویس UserManager اینبار انتظار خواهد داشت که IUserStore ای که به آن تزریق می‌شود، از نوع جدید IProtectedUserStore باشد؛ در غیراینصورت یک استثناء را صادر می‌کند:
if (Options.Stores.ProtectPersonalData)
 {
     if (!(Store is IProtectedUserStore<TUser>))
     {
         throw new InvalidOperationException(Resources.StoreNotIProtectedUserStore);
     }
     if (services.GetService<ILookupProtector>() == null)
     {
         throw new InvalidOperationException(Resources.NoPersonalDataProtector);
     }
 }
که البته اگر از UserStore ای با امضای زیر استفاده می‌کنید، IProtectedUserStore را هم پیاده سازی کرده‌است:
 public class UserStore<TUser, TRole, TContext, TKey, TUserClaim, TUserRole, TUserLogin, TUserToken, TRoleClaim> : ...

همچنین تمام متدهای سرویس UserManager که با خواص مزین شده‌ی به [ProtectedPersonalData] کار می‌کنند، جهت استفاده‌ی از متد ProtectPersonalData به روز رسانی شده‌اند:
public virtual async Task UpdateNormalizedUserNameAsync(TUser user)
{
    var normalizedName = NormalizeName(await GetUserNameAsync(user));
    normalizedName = ProtectPersonalData(normalizedName);
    await Store.SetNormalizedUserNameAsync(user, normalizedName, CancellationToken);
}


چگونه می‌توان بجای DefaultPersonalDataProtector پیش‌فرض، از یک نمونه‌ی سفارشی استفاده کرد؟

برای انجام اینکار نیاز است ILookupProtector خودتان را نوشته و به سیستم معرفی کنید. یک نمونه از پیاده سازی سفارشی آن‌را در پروژه‌ی AspNetCoreIdentityEncryption می‌توانید مشاهده نمائید.
نظرات مطالب
یافتن لیست اسمبلی‌های ارجاعی
ببخشید آقای نصیری که این رو اینجا مطرح کردم. من به سفارش شما تو شرکت از SVN استفاده کردم . بدین نحو که اول خود SVN رو نصب کردم بعد TortoiseSVN . بعدش هم که .برنامه رو سرور مثل سعت کار میکنه , ولی رو کلاینت ها مورد داره . پروژه رو هم رو سرور share کردم و کلاینت هم اون رو Map کردند . حالا وقتی Solution رو باز می کنیم برای هر پروژه این warning رو میده: Project Location Is not Trusted .
وقتی هم که روی یک button کلیک میکنیم این error رو میده : Soure file f:\solution\project1 does not belong to the project being debogged.

وقتی هم میخاییم solution رو commit کنیم error میده که :
Unable to open an ra_local url.unable to open repository.
البیته خیلی من رو ببخشید که اندازه یه تاپیک پست دادم.
مطالب
PowerShell 7.x - قسمت سوم - آشنایی با Redirection
در PowerShell به صورت پیش‌فرض، خروجی، PowerShell Host یا همان کنسول است. PowerShell از چندین استریم پشتیبانی میکند:
  • Success
  • Error
  • Warning
  • Verbose
  • Debug
  • Information 
برای هر کدام از استریم‌های فوق یک آی‌دی اختصاص داده شده‌است که به ترتیب از 1 تا ۶ میباشد. همچنین برای هرکدام یک cmdlet مجزا وجود دارد:
cmdlet  Name   Id
 Write-Output  Success  1
 Write-Error  Error  2
 Write-Warning  Warning  3
 Write-Verbose  Verbose  4
 Write-Debug  Debug  5
 Write-Information  Information  6

به جز دو مورد اول، بقیه cmdletها خروجی را به صورت پیش‌فرض درون کنسول نمایش نمیدهند. به عنوان مثال اسکریپت زیر را در نظر بگیرید:

Write-Output 'Output'                          
Write-Error 'This is an error'                 
Write-Warning 'This is a warning'              

Write-Verbose 'This is verbose'                
Write-Debug 'This is Debug'                    
Write-Information 'This is information'

با اجرای اسکریپت فوق خروجی زیر را خواهیم داشت:

Output
Write-Error: This is an error
WARNING: This is a warning

همانطور که مشاهده میکنید سه cmdlet فوق، خروجی را درون کنسول نمایش نداده‌اند. این رفتار توسط مفهومی تحت عنوان Action Preference قابل تنظیم است که در واقع یک Enum است با مقدار زیر:

  6  Break
رخداد به صورت عادی مدیریت شده و برنامه ادامه پیدا میکند  2  Continue
به طور کلی از رخداد صرفنظر خواهد شد؛ بدون اینکه چیزی در استریم نمایش داده شود 4  Ignore
سوال پرسیده خواهد شد که برنامه را ادامه دهد یا متوقف کند  3  Inquire
به طور کلی از رخداد صرفنظر خواهد شد    
0  SilentlyContinue
 دستور را متوقف خواهد کرد  Stop
 دستور به نوعی معلق خواهد شد 5  Suspend

بنابراین با تغییر Action Preference برای هر کدام از cmdletها میتوانیم رفتار اسکریپت قبلی را تغییر دهیم:

Write-Output 'Output'                          
Write-Error 'This is an error'                 
Write-Warning 'This is a warning'              

$VerbosePreference = 'Continue'
Write-Verbose 'This is verbose'

$DebugPreference = 'Continue'
Write-Debug 'This is Debug'  

$InformationPreference = 'Continue'
Write-Information 'This is information'

اکنون اگر اسکریپت فوق را اجرا کنید، سه خروجی آخر را نیز مشاهده خواهید کرد:

Output
Write-Error: This is an error
WARNING: This is a warning
VERBOSE: This is verbose
DEBUG: This is Debug
This is information

هر کدام از استریم‌های فوق قابل redirect شدن نیز هستند؛ برای اینکار میتوانیم از redirect operatorهایی که در PowerShell پشتیبانی میشود استفاده کنیم:

>
>>
>&1

به عنوان مثال میتوانیم تمام خطاها یا هشدارهای درون یک اسکریپت را به یک فایل منتقل کنیم:

./script.ps1 2>&1 > .\logs.txt

یا میتوانیم تمام Success streamها را به یک فایل هدایت کنیم:

.\script.ps1 > script.log

ارسال تمام Success, Warning, Errorها به یک فایل:

&{
   Write-Warning "hello"
   Write-Error "hello"
   Write-Output "hi"
} 3>&1 2>&1 > C:\Temp\redirection.log

ارسال تمام استریم‌ها به یک فایل:

.\script.ps1 *> script.log

همچنین میتوانیم استریمی را به اصطلاح suppress کنیم که در خروجی نمایش داده نشود:

./script.ps1 1> $null 2> $null

./script.ps1 *> $null

از تکنیک فوق برای drop کردن خروجی‌هایی که نمیخواهیم نمایش داده شوند، استفاده میشود. در کد فوق دو Idهای ۱ و ۲ را به متغیر ویژه‌ی null هدایت کرده‌ایم؛ همچنین میتوانستیم از یک رشته‌ی خالی نیز بجای null استفاده کنیم. در خط بعدی از * استفاده کرده‌ایم که به معنای تمامی استریم‌های موجود است؛ با اینکار چیزی در خروجی نمایش داده نخواهد شد. یک روش دیگر برای drop کردن، استفاده از دستور Out-Null است:

Get-ChildItem | Out-Null

لازم به ذکر است که این cmdlet تا قبل از نسخه ۶ خیلی کند بود؛ زیرا همانند دیگر cmdletهای درون pipeline میبایست یک ورودی (InputObject) را دریافت کند که باعث میشد هزینه‌ی پردازشی بالایی داشته باشد. اما در نسخه ۶ به بعد این مشکل رفع شده‌است و پارزر به محض رسیدن به این keyword به صورت کلی خروجی را discard میکند بدون اینکه Out-Null را فراخوانی کند؛ در واقع این cmdlet یک hint برای پارزر است. روش دیگر برای drop کردن خروجی، انتساب نتیجه یک دستور به متغییر null است:

New-Item -Type Directory -Path $path | Out-Null

$null = New-Item -Type Directory -Path $path

همچنین میتوانیم خروجی یک دستور را به void تبدیل کنیم؛ که نتیجه مشابه با تکنیک‌های فوق دارد:

[void](New-Item -Name test -ItemType Directory)

یک نکته در مورد Out-Null

در loopهای بزرگ ممکن است Out-Null حتی در PowerShell 7.x هم کند عمل کند:

PS > Measure-Command { for($i=0; $i -lt 1mb; $i++) { $i | Out-Null } } | Select-Object TotalSeconds

TotalSeconds
------------
   4.3056315


PS > Measure-Command { for($i=0; $i -lt 1mb; $i++) { $null = $i } } | Select-Object TotalSeconds

TotalSeconds
------------
   1.1210884

PS > Measure-Command { for($i=0; $i -lt 1mb; $i++) { [void]$i } } | Select-Object TotalSeconds

TotalSeconds
------------
    1.130507

PS > Measure-Command { for($i=0; $i -lt 1mb; $i++) { $i > $null } } | Select-Object TotalSeconds

TotalSeconds
------------
   1.3832427