Posts

.NET Legacy App migration to Azure Cloud

Migrating from.NET legacy application from on-premise to Cloud environment is not a very easy going task every time. Complexity depends upon from which version to which version it is getting migrated. Generally the migration executed in four phases - Reviewing, Planning, Migration, and Testing. Below are the five migration oriented links you can visit before you get your hands dirty. Get free compatibility report -  https://azure.microsoft.com/en-us/products/app-service/migration-tools/?WT.mc_id=dotnet-35129-website Review wiki for migrating to App Service - https://github.com/Azure/App-Service-Migration-Assistant/wiki Readiness Checkpoint -  https://github.com/Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks Migration guide, .NET upgrade assistant -  https://learn.microsoft.com/en-us/dotnet/core/porting/upgrade-assistant-overview .NET portability Analyzer -  https://learn.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer And the final...

OOPS Concept - Static class and static constructor

This post is about refreshing couple of basis rules/points in respect of OOPS. Considering C# as one of the languages which support OOPS, following points has been described. Let's start wih the concept. A static class is basically the same as a non-static class, but there is one difference: a static class cannot be instantiated. You need to call class.method directly like Math.Abs() or Math.Floor(). Creating a static class is basically the same as creating a class that contains only static members and a private constructor. A private constructor prevents the class from being instantiated. Non-Static Class, Static field and constructure, usage like singleton and below: A typical use of static constructors is when the class is using a log file and the constructor is used to write entries to this file. Static constructors are also useful when creating wrapper classes for unmanaged code, when the constructor can call the LoadLibrary method. Static constructors are also a convenient pl...

Reliability in Azure Well-Architected Framework

Image
Reliability the one pillar concept of Azure Architected Framework . What is it? Where we can use this and how we can use this in Azure? What we need to know to utilize this effectively? Let's go through some points to discover reliability in details. Build-in Resiliency features in Azure Platform: • Azure Storage, Azure SQL Database, and Azure Cosmos DB all provide built-in data replication across availability zones and regions. • Azure managed disks are automatically placed in different storage scale units to limit the effects of hardware failures. • Virtual machines (VMs) in an availability set are spread across several fault domains. Spreading VMs across fault domains limits the impact of physical hardware failures, network outages, or power interruptions. • Availability Zones are physically separate locations within each Azure region. With availability zones, you can design and operate applications, and databases that automatically transition between zones without inter...

The new challenge - Azure Well-Architected Framework

Image
 Microsoft introducing Azure Well-Architected Framework   - A set of guiding principles that you can use to improve the quality of a workload. This framework consists of below five pillars of architectural excellence: Reliability |  Security  |  Cost optimization  |  Operational excellence  |  Performance efficiency Six supporting elements surrounding the Well-Architected Framework . This make sense, how these pillar work and how they can bring the value to our IT Work Execution Lifestyle.    Great! Reliability - Platform Reliability and Application Reliability A reliable workload is both resilient and available. Resiliency is the ability of the system to recover from failures and continue to function.  The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Availability is whether your users can access your workload when they need to. How do we make our IT enviro...

SharePoint Framework Reference Guide

SPFx stands for SharePoint Framework -  https://learn.microsoft.com/en-us/javascript/api/overview/sharepoint?view=sp-typescript-latest   Below are the packages of SPFx and we are using them while using SPFx framework for development in our day-to-day activities. .'@microsoft/decorators' - https://learn.microsoft.com/en-us/javascript/api/decorators?view=sp-typescript-latest '@microsoft/sp-core-library' - https://learn.microsoft.com/en-us/javascript/api/sp-core-library?view=sp-typescript-latest '@microsoft/sp-component-base package' - https://learn.microsoft.com/en-us/javascript/api/sp-component-base?view=sp-typescript-latest '@microsoft/sp-application-base package' - https://learn.microsoft.com/en-us/javascript/api/sp-application-base?view=sp-typescript-latest '@microsoft/sp-dynamic-data package' - https://learn.microsoft.com/en-us/javascript/api/sp-dynamic-data?view=sp-typescript-latest '@microsoft/sp-extension-base package' - http...

Publish WebAPI in Azure using Visual Studio

Image
 Microsoft always make your life easier. Publishing a WebAPI using Visual Studio is all about a couple of clicks. Before start, you must have a WebAPI working at your local and you must have a Azure subscription. Once build done, right click on the project and click on publish. At this stage, it identify what is the Resource Group, and API Management object is required to be fit in.  Next couple of screens are very simple and self explanatory.  In this stage, click on P ublish button to allow visual studio to publish your WebAPI. Now, you can check and test your WebAPI through Azure and see how it is working. Make sure all backend call are executing as expected.

Best Practices for ASP.NET Core

A common performance problem in ASP.NET Core apps is blocking calls that could be asynchronous. Many synchronous blocking calls lead to  Thread Pool starvation  and degraded response times.         Do not  block asynchronous execution by calling  Task.Wait  or  Task<TResult>.Result .          Do not  acquire locks in common code paths.          Do not  call  Task.Run  and immediately await it - ASP.NET Core already runs app code on normal Thread Pool threads, so calling  Task.Run  only results in extra unnecessary Thread Pool scheduling.        Do  make  hot code paths  asynchronous.       Do  call data access, I/O, and long-running operations APIs asynchronously if an asynchronous API is available.     Do not  use  Task.Run  to make a synchronous API asynchronous.   ...