At one of my customers we store files in the database in varbinary(max) columns. To debug an issue we wanted to read out the files. Of course we could create a small program to do this, but we wanted to do it directly from the SQL Server Management Studio. We created a small database script that uses OLE Automation procedures: To use this script for your own purposes, replace the query after the cursor creation: DECLARE FILEPATH CURSOR FAST_FORWARD FOR <Add your own SELECT query here> The first time that we executed this script, it failed with the following error messages: Msg 15281, Level 16, State 1, Procedure sp_OACreate, Line 1 [Batch Start Line 0] SQL Server blocked access to procedure 'sys.sp_OACreate' of component 'Ole Automation Procedures' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Ole Automation Procedures' by using sp_configure. For more
Yesterday I talked about a problem we encountered when trying to inject a scoped service into ASP.NET Core middleware. The middleware used was convention based middleware, one of the ways to construct middleware in ASP.NET Core. With convention based middleware there isn’t a base class or interface to implement. The only rules your middleware class needs to apply to are: It has a public constructor with a parameter of type RequestDelegate . It contains a public method named Invoke or InvokeAsync . This method must: Return a Task . Accept a first parameter of type HttpContext . Convention based middleware is registered with a singleton lifetime, so you can only constructor injection for the dependencies with a singleton lifetime. For transient and scoped dependencies you need to add extra parameters to the InvokeAsync() method: There is a log of magic going on when using convention based middleware and it shouldn’t be a surprise that pe