The art of simplicity

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

A colleague contacted me with the following problem; when running his ASP.NET Core application it failed with the following error message: Cannot resolve IApiLoggingService from root provider because it requires scoped service NHibernate.IInterceptor In this post I walk you through the different steps we took to investigate the issue and explain how we solved it. But before I dive into the problem itself I first want to give some background info on dependency injection in ASP.NET Core and service lifetimes. Dependency injection and service lifetimes ASP.NET Core supports the dependency injection (DI) software design pattern, which is a technique for achieving Inversion of Control (IoC) between classes and their dependencies. Registration of a dependency is done in the built-in service container, IServiceProvider . Services are typically registered at the app's start-up and appended to an IServiceCollection . Once all services are added, you use BuildServiceProvider to

At one of my clients, Seq is used as the main tool to store structured log messages. If you never heard about Seq before, on their website they promote Seq like this: The self-hosted search, analysis, and alerting server built for structured logs and traces. It certainly is a great tool, easy to use with a lot of great features. But hey, this post is not to promote Seq, I want to talk about a problem we encountered when using it. A developer contacted me and shared the following screenshot: Instead of the structured log message itself being logged, we got the error message above for a subset of our messages. The problem was that the structured log message contained a large JSON object exceeding the default limit of 262144 bytes. Although you could wonder if it’s a good idea to log such large messages in general, for this specific use case it made sense. So you can override the default for a specific application by setting the eventBodyLimitBytes argument when configurin

Microsoft announced last month, the .NET Smart Components, an experimental set of AI-powered UI components that can be added to your .NET apps. They asked us to give these components a try and share our feedback. And that is exactly what we are going to do in this blog post. Right now we have 3 components available: Smart Paste Smart Textarea Smart Combobox If you want a good overview of the available components, check out the video from Steve Sanderson: Although the video shows some compelling use cases for each of these components, we have to start somewhere. So in this post I’ll focus on the Smart Combobox as it doesn’t require any language model backend. Here is the main use case that Smart Combobox tries to solve: The problem with a traditional combobox is that if there are a lot of options available, it can be a challenge to select the right item from the list. With Smart Combobox,  the component uses semantic matching to find an item from the list t

In this post I want to introduce you to Ollama . Ollama is a streamlined tool for running open-source LLMs locally, including Mistral and Llama 2. It bundles model weights, configurations, and datasets into a unified package managed by a Modelfile. Ollama supports a variety of LLMs including LLaMA-2, uncensored LLaMA, CodeLLaMA, Falcon, Mistral, Vicuna model, WizardCoder, and Wizard uncensored. Installation To install Ollama on Windows, first download the executable available here: https://ollama.com/download/OllamaSetup.exe Run the executable to start the Installation wizard: Click Install to start the installation process. After the installation has completed Ollama will be running in the background: We can now open a command prompt and call ollama: Download a model Before we can do anything useful, we first need to download a specific language model. The full list of models can be found at https://ollama.com/library . Here are some examples: Model