If you intend to build infrastructure in Azure as part of your build or release pipelines, for example using Azure Resource Management (ARM) templates, you should use a service principal to connect to your Azure subscription. In this post, I’ll show you how to use the Azure CLI to create a service principal with sufficient permissions for both creating resources and assigning roles to them, and how to setup a service connection to use it in Azure DevOps.
To create a custom entry point for a WPF application that is created using the default template in Visual Studio and targets the .NET Framework, you can change the
Build Action property of the
App.xaml file from
Page and create a class with a static
Main method. That’s what I did in a previous post about handling protocol activation and redirection in packaged apps.
PublishSingleFile option in .NET Core 3 lets you package an application into a single executable (
.exe) file that contains all assemblies, resources, content files and other stuff that the app requires at runtime. This means that the output directory of an app that previously would contain a bunch of framework specific and referenced DLLs, configuration files and other content can now be reduced to contain only a single
.exe file that you can simply double-click on to run the app. These single-file executables do however come with some gotchas.
.runsettings file with a
<TestRunParameters> element is a convenient way to keep sensitive information required by your integration tests, such as for example username and passwords, out of source control. At least if you run your tests on Windows using Visual Studio Test or the
VSTest@2 task in Azure Pipelines.
Microsoft announced at Build 2018 back in May that they are bringing .NET Core to the Windows desktop applications frameworks, including both WPF and Windows Forms. This means that your client applications will be able to take advantage of the various performance improvements that have been introduced in .NET Core and that you will be able to deploy them as self-contained executables (.exes) that have no dependency upon any pre-installed version of .NET. Read »