Unlike most other tools, PowerShell does not offer us a -version flag to tell us its version number. There is a -Version flag (with a capital V), but that we need to use a specific version of PowerShell. What can we do to find out what version we run?
We use Seq to find valuable insights in the vast sea of our structured log messages. While the search usually works straightforward without any surprises, this time we run into a minor problem.
As long as your application does not use Blazor, upgrading from .Net 7 to .Net 8 is a walk in the park. The only obstacle we run into while upgrading the user group site was the publish task. Microsoft has made some simplifications to the runtime identifiers that are a breaking change.
If you spend May 2020 focused on other things than tech news, you may have missed the announcement of the Windows Package Manager. It took me a while to find this little gem and noticed that many developers had no clue either that this tool runs on their Windows 10 and 11 machines.
This package manager is not as comprehensive as the ones on Linux. Nevertheless, the number of applications you can manage is impressive and goes way beyond Microsoft products. Let us explore the command line tool winget, that allows us to manage our applications.
As I tried to update my WSL (Windows Subsystem for Linux) installation, I run into this error message:
While solving the annoying problem with the *.bacpac files, I was not sure what edition of SQL Server I have installed on my machine. The simplest way to figure out what edition you run is to start SQL Server Management Studio, connect to your SQL Server and right click on the Server node. In the Properties you find an entry for the Product and that shows what edition you use:
With a higher usage of our build agents in Azure DevOps, we run out of disk space twice in the same week. It was now time to find a solution that would declutter our local build agents.
The last time I searched for a solution I could not find anything that would allow me to clean up the working directory of a build agent without creating a solution by myself. Luckily, Microsoft listened to the countless complaints and created a solution directly in the build agent pool of Azure DevOps.
SQL Server Management Studio may not include all important parts of your table when you let it write the CREATE TABLE script. For instance, the full-text index for a table is omitted by default. If you use the full-text search feature, you should make sure that SQL Server Management Studio includes them in the create scripts. You can change the behaviour with these steps:
A while ago we noticed a performance problem with Seq and the other applications that run on the same server. As it turned out, Seq allocated all the memory and left next to nothing for the other applications. A restart of Seq will only be a temporary solution, for a more durable one we need to restrict the memory consumption of Seq. Luckily, we can do that with a simple change in the configuration.
We use AsciiDoc as the format for our documentation for the user group project. AsciiDoc is a bit like Markdown, but it supports multi-file documents out of the box and without any quirks.
We use the Ruby app Asciidoctor to turn our AsciiDoc files into a PDF as part of our build job. Since building the whole application takes time, it is not the fastest way to get feedback when we write the documentation. To shorten the feedback cycle, we put Asciidoctor into a development container to create the PDF whenever we want to check something.