The new .Net 5 was released a few hours ago at .Net Conf 2020. I looked forward to this release that marks the future of .Net. From now on all the new features for .Net will go to this branch while the full framework (4.8) only gets bugfixes.
I will soon move a web application to a different domain. Without any extra work this change will break the existing URLs. To prevent this from happening, I try a new approach with a small replacement application that accepts every request to the old domain name, logs its referring site and redirects the user after a few seconds to the new application.
As part of our build and deploy job in the user group project we create a backup of our Azure database before we run any data migrations. If something goes wrong, we do not lose any data and can restore our cloud database to a known good state.
It would be a great opportunity to take this backup file and restore our database to the local SQL Server on our developer machines. Unfortunately, the backup tool creates a *.bacpac file and not a *.bak. Restoring a *.bacpac file needs a few additional steps and, most importantly, a different entry point in the SQL Server Management Studio to start the restore process.
Visual Studio has an old but still helpful way to change your web.config file based on the environment or build mode. This allows you to replace connection strings or the configuration for web services without the need to fiddle with XML. You still need to write XML Transformation code, but that is a lot simpler than modifying everything on your own.
Creating links between web pages is the foundation of the world wide web. You can do that with the HTML a tag and the href attribute. The default behaviour of a web browser is to bring you on the top of that linked page. While this works for most cases, sometimes you want to link to a more specific part. There is a simple solution to improve the user experience if you can modify the linked page.
I try to keep my build jobs free from warnings. Otherwise they tend to grow rapidly, and it gets impossible to notice upcoming problems early on. From time to time a build job throws a warning message like this one:
I use GitHub Desktop since it was called GitHub for Windows. In those 8 years I never had problems with this Git client – at least until a few days ago where nothing worked at all.
It started as I tried to push to one of my Git repositories at GitHub. Instead of synchronising my changes, GitHub Desktop asked if I want to create a remote repository. I expected that my login token was no longer valid. Therefore, I signed out and logged in to get a new one. That did not change anything. I put this problem aside and tried to clone another one of my repositories. However, the list of my GitHub repositories was empty.
Last week I run into the strangest problem with Azure DevOps since we started using it in 2015. From one day to the next, one of our local build servers took massively more time to do its work. Build steps that took 30 seconds now run for 10 minutes, some even for more than an hour.
Nothing had changed in the application or in our environment, but now we had an unusable situation. I first checked status.dev.azure.com to see if there was a known problem. All services where up and running, no news on Twitter and Google only showed problems like mine from years ago.
The installer of SQL Server has a little annoyance: By default, the available memory for your database is set to 2147483647 (or Int32.MaxValue) :
Creating a client-side SSL certificate that you can use to log in on a web site is a challenge. Every part from your certificate to the settings in your web application must work together or you only get an error message. You may have created SSL server certificates without any problems, but believe me, client certificates are another beast.