The fourth preview of .NET 7 includes enhancements to observability in
the .NET implementation of OpenTelemetry, the addition of properties to
track microseconds and nanoseconds in date and time structures, new
metrics for caching extensions, performance-boosting “on stack
replacement,” APIs to work with .tar
archives, and additional features as part of an ongoing effort to
improve the performance of and add features to regular expressions in
.NET 7.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<NoWarn>RCS1090</NoWarn>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\ASPNETCore2JwtAuthentication.WebApp\ASPNETCore2JwtAuthentication.WebApp.csproj" />
</ItemGroup>
<ItemGroup>
<None Include="..\ASPNETCore2JwtAuthentication.WebApp\appsettings.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
<ItemGroup>
<Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c329}" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="fluentassertions" Version="5.10.3" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="3.1.8" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1" />
<PackageReference Include="MSTest.TestAdapter" Version="2.1.2" />
<PackageReference Include="MSTest.TestFramework" Version="2.1.2" />
</ItemGroup>
</Project> using ASPNETCore2JwtAuthentication.WebApp;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.AspNetCore.TestHost;
using Microsoft.Extensions.DependencyInjection.Extensions;
using Microsoft.Extensions.Hosting;
namespace ASPNETCore2JwtAuthentication.IntegrationTests
{
public class CustomWebApplicationFactory : WebApplicationFactory<Program>
{
protected override IWebHostBuilder CreateWebHostBuilder()
{
var builder = base.CreateWebHostBuilder();
builder.ConfigureLogging(logging =>
{
//TODO: ...
});
return builder;
}
protected override void ConfigureWebHost(IWebHostBuilder builder)
{
builder.ConfigureTestServices(services =>
{
// Don't run `IHostedService`s when running as a test
services.RemoveAll(typeof(IHostedService));
});
}
}
} using System;
using System.Threading;
using System.Net.Http;
namespace ASPNETCore2JwtAuthentication.IntegrationTests
{
public static class TestsHttpClient
{
private static readonly Lazy<HttpClient> _serviceProviderBuilder =
new Lazy<HttpClient>(getHttpClient, LazyThreadSafetyMode.ExecutionAndPublication);
/// <summary>
/// A lazy loaded thread-safe singleton
/// </summary>
public static HttpClient Instance { get; } = _serviceProviderBuilder.Value;
private static HttpClient getHttpClient()
{
var services = new CustomWebApplicationFactory();
return services.CreateClient(); //NOTE: This action is very time consuming, so it should be defined as a singleton.
}
}
} using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;
using System.Threading.Tasks;
using FluentAssertions;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace ASPNETCore2JwtAuthentication.IntegrationTests
{
[TestClass]
public class JwtTests
{
[TestMethod]
public async Task TestLoginWorks()
{
// Arrange
var client = TestsHttpClient.Instance;
// Act
var token = await doLoginAsync(client);
// Assert
token.Should().NotBeNull();
token.AccessToken.Should().NotBeNullOrEmpty();
token.RefreshToken.Should().NotBeNullOrEmpty();
}
[TestMethod]
public async Task TestCallProtectedApiWorks()
{
// Arrange
var client = TestsHttpClient.Instance;
// Act
var token = await doLoginAsync(client);
// Assert
token.Should().NotBeNull();
token.AccessToken.Should().NotBeNullOrEmpty();
token.RefreshToken.Should().NotBeNullOrEmpty();
// Act
const string protectedApiUrl = "/api/MyProtectedApi";
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token.AccessToken);
var response = await client.GetAsync(protectedApiUrl);
response.EnsureSuccessStatusCode();
// Assert
var responseString = await response.Content.ReadAsStringAsync();
responseString.Should().NotBeNullOrEmpty();
var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.CamelCase };
var apiResponse = JsonSerializer.Deserialize<MyProtectedApiResponse>(responseString, options);
apiResponse.Title.Should().NotBeNullOrEmpty();
apiResponse.Title.Should().Be("Hello from My Protected Controller! [Authorize]");
}
private static async Task<Token> doLoginAsync(HttpClient client)
{
const string loginUrl = "/api/account/login";
var user = new { Username = "Vahid", Password = "1234" };
var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Post, loginUrl)
{
Content = new StringContent(JsonSerializer.Serialize(user), Encoding.UTF8, "application/json")
});
response.EnsureSuccessStatusCode();
var responseString = await response.Content.ReadAsStringAsync();
responseString.Should().NotBeNullOrEmpty();
return JsonSerializer.Deserialize<Token>(responseString);
}
}
}
این روش تا زمانیکه برنامه‌ی ما برای اجرا شدن، تنها از یک سرور استفاده کند، بهترین انتخاب خواهد بود؛ چرا که به دلیل نزدیک بودن، سریع‌ترین بازخورد را نیز به درخواست‌ها ارائه میدهد.
اما شرایطی را فرض کنید که برنامه از چندین سرور برای اجرا شدن استفاده میکند و به طبع هر سرور درخواست‌های خودش را داراست که ما باید برای هر یک بصورت جداگانه‌ای یک کش In-Memory را در حافظه Ram هرکدام ایجاد کنیم.
فرض کنید دیتای ما 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 باشد. بخشی از دیتا در Server 1 کش میشود (1 , 3 , 5 , 9) و بخشی دیگر در Server 2 کش خواهد شد (2 , 4 , 6 ,7 , 8 , 10).
در اینجا مشکلات و ضعف هایی به وجود خواهد آمد :
روش هایی وجود دارد که بتوان از سیستم Local Caching در حالت چند سروری هم استفاده کرد و این مشکلات را از بین برد، اما روش استاندارد در حالت چند سروری، استفاده از Distributed Cacheها است.
روش دوم : Distributed Caching
در این روش برنامه‌ی ما برای اجرا شدن از چندین سرور شبکه شده به هم، در حال استفاده هست و Cache برنامه، توسط سرورها به اشتراک گذاشته شده.
در این حالت سرور‌های ما از یک کش عمومی استفاده میکنند که مزایای آن شامل :
■ درخواست‌ها به چندین سرور مختلف از هم ارسال شده، اما دیتای کش بصورت منسجم در هریک وجود خواهد داشت.
■ با خراب شدن یا Down شدن یک سرور، کش موجود در سرور‌های دیگر پاک نمیشود و کماکان قابل استفاده است.
■ به حافظه Ram یک سرور محدود نیست و مشکلات زیادی همچون کمبود سخت افزاری و محدودیت‌های حافظه‌ی Ram را تا حد معقولی کاهش میدهد.
طریقه استفاده از Cache در Asp.Net Core :
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddMemoryCache();
}
public class HomeController : Controller
{
private readonly IMemoryCache _cache;
public HomeController(IMemoryCache cache)
{
_cache = cache;
}
....
}
public IActionResult Set()
{
_cache.Set("CacheKey", data , TimeSpan.FromDays(1));
return View();
} در پارامتر اول این متد (CacheKey)، یک کلید، برای اطلاعاتی که میخواهیم کش کنیم قرار میدهیم. دقت کنید که این کلید، شناسه‌ی دیتای شماست و باید طوری آن را در نظر گرفت که با صدا زدن این کلید از سرویس کش، همان دیتای مورد نظر را برگشت دهد (هر Object دیتا، باید کلید Unique خود را داشته باشد).
در پارامتر دوم، دیتای مورد نظر را که میخواهیم کش کنیم، به متد میدهیم و در پارامتر سوم نیز زمان اعتبار و تاریخ انقضای دیتای کش شده را وارد میکنیم؛ به این معنا که دیتای کش شده، بعد از مدت زمان گفته شده، از حافظه کش(Ram) حذف شود و برای دسترسی دوباره و کش کردن دوباره اطلاعات، نیاز به خواندن مجدد از دیتابیس باشد.
public IActionResult Get()
{
string data = _cache.Get("CacheKey");
return View(data);
} تنها پارامتر ورودی این متد، کلید از قبل نسبت داده شده به اطلاعات کش هست که با استفاده از یکسان بودن کلید در ورودی این متد و کلید Set شده از قبل در حافظه Ram، دیتا مربوط به آن را برگشت میدهد.
public IActionResult Set()
{
DateTime data;
// Look for cache key.
if (!_cache.TryGetValue( "CacheKey" , out data))
{
// Key not in cache, so get data.
data= DateTime.Now;
// Save data in cache and set the relative expiration time to one day
_cache.Set( "CacheKey" , data, TimeSpan.FromDays(1));
}
return View(data);
} این متد ابتدا بررسی میکند که کلیدی با نام "CacheKey" وجود دارد یا خیر؟ در صورت عدم وجود، آن را میسازد و دیتای مورد نظر را به آن نسبت میدهد.
public IActionResult GetOrCreate()
{
var data = _cache.GetOrCreate( "CacheKey" , entry =>
entry.SlidingExpiration = TimeSpan.FromSeconds(3);
return View(data);
});
return View(data);
}
در اینجا absolute expiration به این معنا است که یک زمان قطعی را برای منقضی شدن کش‌ها مشخص میکند؛ به عبارتی میگوییم کش با کلید فلان، در تاریخ و ساعت فلان حذف شود. اما در sliding expiration یک بازه زمانی برای منقضی شدن کش‌ها مشخص میکنیم؛ یعنی میگوییم بعد از گذشت فلان دقیقه از ایجاد کش، آن را حذف کن و اگر در طی این مدت مجددا خوانده شد، طول مدت زمان آن تمدید خواهد شد.
این تنظیمات را میتوانید در قالب یک option زمان Set کردن یک کش، به آن بدهید.
MemoryCacheEntryOptions options = new MemoryCacheEntryOptions();
options.AbsoluteExpiration = DateTime.Now.AddMinutes(1);
options.SlidingExpiration = TimeSpan.FromMinutes(1);
_cache.Set("CacheKey", data, options ); در مثال بالا هردو option اضافه شده یک کار را انجام میدهند؛ با این تفاوت که absolute expiration تاریخ now را گرفته و یک دقیقه بعد را به آن اضافه کرده و تاریخ انقضای کش را با آن تاریخ set میکند. اما sliding expiration از حالا بمدت یک دقیقه اعتبار دارد.
این اولویت بندی‌ها زمانی کاربرد خواهند داشت که حافظه اختصاصی Ram، برای کش‌ها پر شده باشد و در این حالت سیستم کشینگ بصورت خودمختار، کش‌های با الویت پایین را از حافظه حذف میکند و کش‌های با الویت بیشتر، در حافظه باقی میمانند. این با شماست که الویت را برای دیتا‌های خود تعیین کنید؛ پس باید با دقت و فکر شده این کار را انجام دهید.
MemoryCacheEntryOptions options = new MemoryCacheEntryOptions();
// Low / Normal / High / NeverRemove
options.Priority = CacheItemPriority.High;
cache.Set("CacheKey", data, options); به این صورت میتوانید الویت‌های متفاوت را در قالب option به کش‌های خود اختصاص دهید.
در این مقاله سعی شد مفاهیم اولیه Cache، طوری گفته شود، تا برای افرادی که میخواهند به تازگی این سیستم را بیاموزند و در پروژه‌های خود استفاده کنند، کاربردی باشد و درک نسبی را نسبت به مزایا و محدودیت‌های این سیستم بدست آورند.
در قسمت دوم همین مقاله بطور تخصصی‌تر به این مبحث میپردازیم و یک پکیج آماده را معرفی میکنیم که خیلی راحت‌تر و اصولی‌تر کش را برای ما پیاده سازی میکند.
You'll often hear the terms framework and platform used interchangeably. This can be very confusing. You'll hear that .NET Core is a platform. Then you'll read that .NET Core is cross-platform. Next, you'll learn that .NET Core is a framework. And it doesn't help that framework is part of the name of the original full .NET Framework.
In this post, I explain the difference between frameworks and platforms and explain why sometimes you'll see .NET being referred to as a framework and other times see it referred to as a platform.
@attribute [ProtectedPage(GroupName = "Feature 1", Title = "Page 1", GlyphIcon = "bi bi-dot", GroupOrder = 1, ItemOrder = 1)]
The path specified by "C:\FileStream\ApplicantDocuements" is not in a valid directory. One or more files listed in the statement could not be found or could not be initialized.
The .NET Framework 4.8 includes an updated toolset as well as improvements in several areas:
ASP.NET Core: Saturating 10GbE at 7+ million request/s
In these “platform” comparisons that’s:
- x1.78 faster than ngnix
- x2.93 faster than Java’s Servlet (x7.76 faster than Servlet on Tomcat)
- x7.36 faster than Golang’s “net/http” package
- x8.06 faster than node.js running as a cluster of 28 processes (as node.js is single threaded)
// webpack.config.js file
module.exports = {
entry:'./main.js'
,output:{
filename:'bundle.js'
}
} //for when webpack is installed globally webpack --watch //for when webpack is installed locally in project npm run webpack -- --watch
//webpack.config.js file
module.exports = {
entry:'./main.js'
,output:{
filename:'bundle.js'
}
,watch :true
} 
// to install globally : npm install -g webpack-dev-server //to install locally in project : npm install -D webpack-dev-server
//package.json file
{
"name": "dntwebpack",
"version": "1.0.0",
"description": "",
"main": "main.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"webpack": "webpack",
"webpackserver": "webpack-dev-server"
},
"author": "mehdi",
"license": "ISC",
"devDependencies": {
"webpack": "^1.13.1",
"webpack-dev-server": "^1.14.1"
}
} npm run webpackserver
// user.js file
function userLog() {
console.log("ahooy from user module file");
}
module.exports={
userLog:userLog
} //main.js file
var user = require("./user");
user.userLog();
console.log(`i'm bundled by webpack`); 
// shared.js file
console.log('log message from shared module !'); //webpack.config.js file
module.exports = {
entry:['./shared.js','./main.js']
,output:{
filename:'bundle.js'
}
,watch :true
} 
npm install -D ts-loader
// main.ts file
let user = require("./user");
user.userLog();
let mainlogger = () => {
console.log(`i'm bundled by webpack in an arrow function`);
}
mainlogger(); //webpack.config.js
module.exports = {
entry:['./shared.js','./main.js']
,output:{
filename:'bundle.js'
}
,watch :true
,module:{
loaders:[
{
test:/\.ts$/
,exclude:/node_modules/
,loader:'ts-loader'
}
]
}
} 