Extending HttpClient With Delegating Handlers in ASP.NET Core

Delegating handlers are like ASP.NET Core middleware. Except they work with the HttpClient. The ASP.NET Core request pipeline allows you to introduce custom behavior with middleware. You can solve many cross-cutting concerns using middleware — logging, tracing, validation, authentication, authorization, etc.

But, an important aspect here is that middleware works with incoming HTTP requests to your API. Delegating handlers work with outgoing requests.

Read more here

https://www.milanjovanovic.tech/blog/extending-httpclient-with-delegating-handlers-in-aspnetcore

App Registration vs Enterprise Applications

All applications that get registered in AAD, in the tenant, two types of objects get created once the app registration is done.

  • Application Object
  • Service Principal Object

The Application Object is what you see under App Registrations in AAD. This object acts as the template where you can go ahead and configure various things like API Permissions, Client Secrets, Branding, App Roles, etc. All these customizations that you make to your app, get written to the app manifest file. The application object describes three aspects of an application: how the service can issue tokens in order to access the application, resources that the application might need to access, and the actions that the application can take.

The Service Principal Object is what you see under the Enterprise Registration blade in AAD. Every Application Object (created through the Azure Portal or using the Microsoft Graph APIs, or AzureAD PS Module) would create a corresponding Service Principal Object in the Enterprise Registration blade of AAD. A service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.

Similar to a class in object-oriented programming, the application object has some static properties that are applied to all the created service principals (or application instances).

You can read more on the following objects here: https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Reference

https://learn.microsoft.com/en-us/training/modules/implement-app-registration/2-plan-your-line-business-application-registration-strategy

Last Run Date on a Stored Procedure in SQL Server

We starting to get a lot of stored procedures in our application. Many of them are for custom reports many of which are no longer used. Here is a query that can be run on the system views in SQL Server 2005 – 2022 that would tell us the last date a stored procedure was executed?

SELECT o.name, 
       ps.last_execution_time 
FROM   sys.dm_exec_procedure_stats ps 
INNER JOIN 
       sys.objects o 
       ON ps.object_id = o.object_id 
WHERE  DB_NAME(ps.database_id) = '' 
ORDER  BY 
       ps.last_execution_time DESC

Reference

https://stackoverflow.com/questions/595742/last-run-date-on-a-stored-procedure-in-sql-server

Using varchar(MAX) vs TEXT on SQL Server

The VARCHAR(MAX) type is a replacement for TEXT. The basic difference is that a TEXT type will always store the data in a blob whereas the VARCHAR(MAX) type will attempt to store the data directly in the row unless it exceeds the 8k limitation and at that point it stores it in a blob.

Using the LIKE statement is identical between the two datatypes. The additional functionality VARCHAR(MAX) gives you is that it is also can be used with = and GROUP BY as any other VARCHAR column can be. However, if you do have a lot of data you will have a huge performance issue using these methods.

In regard to if you should use LIKE to search, or if you should use Full Text Indexing and CONTAINS. This question is the same regardless of VARCHAR(MAX) or TEXT.

If you are searching large amounts of text and performance is key then you should use a Full Text Index.

LIKE is simpler to implement and is often suitable for small amounts of data, but it has extremely poor performance with large data due to its inability to use an index.

Reference

https://stackoverflow.com/questions/834788/using-varcharmax-vs-text-on-sql-server

finding all stored procedures that is calling functions

I would like to find all the stored procedures that has reference of Functions or called Functions from Store procedures.

Here is the script;

Select 
	Schema_Name(p.schema_id) As ProcedureSchema, p.name As ProcedureName, 
	Schema_Name(f.schema_id) As FunctionSchema, f.name as FunctionName
From sys.sql_expression_dependencies d
Inner Join sys.objects p On 
	p.object_id = d.referencing_id And p.type_desc = 'SQL_STORED_PROCEDURE'
Inner Join sys.objects f On 
	f.object_id = d.referenced_id And f.type In ('AF', 'FN', 'FS', 'IF', 'TF');