The art of simplicity

You have to love these days when everything seems to go haywire at the same time. Your code no longer compiles, your CI build status turns red and your unit tests become flaky. Today turned out to be one of such days as our build started to fail with the following error message: System.AggregateException: One or more errors occurred. ---> NuGet.CommandLine.CommandLineException: Error parsing solution file at D:\b\3\_work\154\s\Source\MyApp\MyApp.sln: Exception has been thrown by the target of an invocation. In our pipeline we were using the NuGetToolnstaller task: - task: NuGetToolInstaller@1 inputs: versionSpec: '4.x' We had just installed the latest version of the Visual Studio Build tools on our build server. This new version has a breaking change with regard to older versions of NuGet. As a fix, we switched to a newer NuGet version: - task: NuGetToolInstaller@1 inputs: versionSpec: '5.x' That’s it!

Short post today as a reminder for myself if I ever get this error again... When trying to build and deploy an older .NET Core 3.1 app, the build server returned the following error message: :\Program Files\dotnet\sdk\5.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): Error NETSDK1005: Assets file 'D:\b\4\agent\_work\2\s\Loket\obj\project.assets.json' doesn't have a target for 'netcoreapp3.1'. Ensure that restore has run and that you have included 'netcoreapp3.1' in the TargetFrameworks for your project. Process 'msbuild.exe' exited with code '1'. We discovered that the issue was caused by a change in the .NET SDK starting from .NET 5.0. The project.assets.json mentioned in the error message above is created by NuGet in the obj\ folder. The .NET SDK uses it to get information about packages to pass into the compiler. In .NET 5, Nuget added a new field called TargetFrameworkAlias, and thus in...

On our last architecture board, one of the architects shared the following problem. After upgrading to Visual Studio 17.5 Razor ViewComponents were no longer rendered. Instead the viewcomponent tag remained on the page. *UPDATE: In the meanwhile Visual Studio 2022 version 17.5.2 got released which contains a fix for the issue I'm explaining below* This problem manifested not only on the local developer machine but also on the build server after upgrading the Visual Studio Build tools to 17.5.  The root cause is a bug in the latest dotnet runtimes that are installed as part of the Visual Studio upgrade. It affects the following dotnet runtimes  6.0.14 and 7.0.3 that match with this SDK version: 6.0.114, 6.0.309, 6.0.406 for .Net 6 and 7.0.103, 7.0.200 and 7.0.201 for .Net 7. As a workaround we included an extra build step in our yaml pipeline that uses a non affected SDK version: Of course this would require all our teams to update their projects. So what we did instead...

With the dotnet pack command you can build a project and create a Nuget package. By default, when you execute this command the package version will be set to 1.0.0 . If you want to specify the package version you can either set the Version or the PackageVersion in your csproj file: If you are using the Version parameter both the FileVersion of the embedded dll and the NuGet package version will be updated. Using the PackageVersion will only impact the version number of the NuGet package. By default, PackageVersion takes the same value as Version. You can override the package version at pack time by using the PackageVersion parameter : dotnet pack /p:PackageVersion=1.2.3-beta It is also possible to set a VersionPrefix and VersionSuffix . The VersionPrefix allows you to set a “base” version number. This can be combined with a VersionSuffix to create the final version. For example, when you set the VersionPrefix to 1.2.3 and VersionSuffix to beta , the Version wi...

Last week the latest Visual Studio 2022 update was announced; v17.4. This is not a post about all the new features but about an issue I encountered after doing the update. In the previous release Live Unit Testing was announced as a preview. At that time I enabled this preview feature to check what was possible and help me in my test driven development lifecycle. After installing the 17.4 update, this caused an unexpected side-effect. I no longer succeeded in compiling any of my projects and all of them failed with exceptions like this: Build started... 1>------ Build started: Project: BlazorShared, Configuration: Debug Any CPU ------ 1>D:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Microsoft.Common.props(73,3): error MSB4024: The imported project file "D:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Imports\Microsoft.Common.props\ImportBefore\Microsoft.LiveUnitTesting.props" could not be loaded. Root elemen...

When trying to build a .NET application on our build server, it failed with the following error message: ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3326,5): Error MSB3326: Cannot import the following key file: . The key file may be password protected. To correct this, try to import the certificate again or import the certificate manually into the current user’s personal certificate store. C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(3326,5): error MSB3326: Cannot import the following key file: . The key file may be password protected. To correct this, try to import the certificate again or import the certificate manually into the current user’s personal certificate store. [D:\b\3\_work\32\s\Source\Example.csproj] ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.C...

A collegae contacted me today with the following question; his builds started to fail suddenly with the following error: ##[error]C:\Program Files\dotnet\sdk\6.0.101\Microsoft.Common.CurrentVersion.targets(5100,5): Error MSB3030: Could not copy the file "StaticWebAssets.xml" because it was not found. He was wondering if something was changed on the build server and indeed he was right; we recently installed the .NET 6 SDK on the build server. As you can see in the error message, the project was built using the .NET 6 SDK. To fix the error we provided a short and long term solution. The short term solution The short term solution was triggering a clean solution before building the project. This will remove all remaining build artifacts and guarantees a clean slate. To achieve this in Azure DevOps using the Classic pipeline: Go to your Build pipeline Select the Get Sources Tab Set the Clean value to true Save the pipeline and run the build ...

So far I’ve always used xcopy in a pre or post build event to copy files between projects: But did you know that you don’t need this and that it can be done by standard msbuild features? (By the way the code above doesn’t even work on Linux) To achieve the same thing you can use the following msbuild configuration in your csproj file: 2 important things to notice: You can use file patterns in the 'Include' to specify a set of files You can use ‘LinkBase’ to specify a target folder

When creating a nuget package from a .NET Core project, I noticed the following warning in the NuGet Package Explorer : Source Link (which I’ll talk about in another post) is Valid but the build is marked as ‘Non deterministic’ . What does this mean? By default builds are non-deterministic, meaning there is no guarantee that building the same code twice(on the same or different machines) will produce exactly the same binary output. Deterministic builds are important as they enable verification that the resulting binary was built from the specified source and provides traceability. How to fix it? To enable deterministic builds a property should be set to through: ContinuousIntegrationBuild . Important : This property should not be enabled during local dev as the debugger won't be able to find the local source files. Therefore, you should use your CI system's variable to set them conditionally. For Azure Pipelines,the variable is TF_BUILD can be used: ...

With the release of MSBuild version 15, you no longer need to add custom properties to every project in your solution. Instead you can create a single file called Directory.Build.props in the root folder of your source.When MSBuild runs, it will search for this file and loads it when found. I use this on my projects to set common properties: Directory.Build.props is imported very early in the build pipeline and can be overridden elsewhere in the project file or in imported files. If you want to override properties set in a specific project, use Directory.Build.targets instead. It is used and discovered in the same way, but it is loaded much later in the build pipeline. So, it can override properties and targets defined in specific projects. More information: https://docs.microsoft.com/nl-nl/visualstudio/msbuild/customize-your-build?view=vs-2019#directorybuildprops-and-directorybuildtargets

Sonar Cloud is the SaaS version of SonarQube , a static code analyzer. It can inspect your code against a set of quality standards, detect bugs, security vulnerabilities,  calculate technical debt and see how your code quality evolves over time. If you want to use it in Azure DevOps you should first install the SonarCloud extension from the marketplace: https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud After the extension is installed you get 3 new build tasks: Remark: Notice that this are not the same build tasks as should be used when using SonarQube(!) Let’s create a build pipeline that uses these tasks: First add the Prepare analysis on SonarCloud task. This task should be added to the beginning of your pipeline.  In this task you should configure the SonarCloud Service Endpoint, specify an Organization and set a Project Key and Project Name. This information will be used to create a new project inside SonarCloud. A ...

After installing the latest Visual Studio version on our build servers, some of our builds started to fail with the following error message: This error only happened on the build servers running MSBuild version 16.5.0.12403: One or more errors occurred. ---> NuGet.CommandLine.CommandLineException: Error parsing solution file at D:\b\4\agent\_work\153\s\VLM.MELO.sln: Exception has been thrown by the target of an invocation. at NuGet.CommandLine.MsBuildUtility.GetAllProjectFileNamesWithMsBuild(String solutionFile, String msbuildPath) at NuGet.CommandLine.RestoreCommand.ProcessSolutionFile(String solutionFileFullPath, PackageRestoreInputs restoreInputs) This turns out to a bug in the NuGet client where older versions have trouble with this new version of MSBuild. To resolve this issue in Azure Pipelines, add a NuGet Tool Installer task to your pipeline before any tasks that use NuGet, and set the version field to include the latest version.

Detecting if Visual Studio is installed on the build server can be quite painful. I’ve seen a few times where the build agent didn’t pick up the Visual Studio installation, making the build server useless. As Visual Studio is not added to the capabilities of the build agent, the specific agent is never used to conduct a build. If everything is OK, you should see something like this in your Build Agent capabilities: But how does the build agent detects that Visual Studio is there? This is all done through vswhere.exe, a tool I blogged about before. Vswhere is installed as one of the tools of the build agent, but in case of trouble you can run it yourself to see what is going wrong. Let’s try this: Login on your build server and open the installation folder of one of your build agents. Go to the externals\vswhere  subfolder. Here you should find the vswhere.exe Let’s see what options are available by calling vswhere.exe –help : PS D:\builds\dev-agent-1\exte...

A customer contacted me about a problem on their build servers. The build for one of their applications failed sometimes with the following error message: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(550,5): Error MSB4018: The "SqlBuildTask" task failed unexpectedly. Microsoft.Isam.Esent.Interop.EsentVersionStoreOutOfMemoryException: Version store out of memory (cleanup already attempted) at Microsoft.Isam.Esent.Interop.Api.Check(Int32 err) The solution contained a SQL Server Database project, that resulted in the error above. When we removed the database project from the build configuration, the error disappeared. Further investigation brought us to a final solution; an update of the SQL Server Data Tools on the Build server solved the problem.

Part of the magic inside Orleans happens through the usage of code generation. However when I tried to build my Orleans app it failed with the following error message: Error MSB3073 The command ""dotnet" "C:\Users\UserName.nuget\packages\microsoft.orleans.orleanscodegenerator.build\2.1.0\build..\tasks\netcoreapp2.1\Orleans.CodeGeneration.Build.dll" "@C:\projects\myProjectName\_obj\Debug\Bots\netcoreapp2.1\codegen\Bots.orleans.g.args.txt"" exited with code 3. Bots C:\Users\UserName.nuget\packages\microsoft.orleans.orleanscodegenerator.build\2.1.0\build\Microsoft.Orleans.OrleansCodeGenerator.Build.targets 82 This error message  is not very useful, but it brought me to the following issue on GitHub: https://github.com/dotnet/orleans/issues/5038 . I accidently downloaded and used the wrong NuGet package; I was using Microsoft.Orleans.CodeGenerator.Build where in fact I needed Microsoft.Orleans.CodeGenerator.MsBuild . I don’t know ex...

After deploying an ASP.NET Core application to IIS, it failed to start with the following error message: Application 'MACHINE/WEBROOT/APPHOST/SampleApp/' with physical root 'C:\Sites\sampleapp\' failed to start process with commandline '%LAUNCHER_PATH% %LAUNCHER_ARGS%', ErrorCode = '0x80070002' : 0. So what is going on? By default when you add a web.config file to your ASP.NET core project, the following configuration is added: You see the 2 environment variables'(%LAUNCHER_PATH%, %LAUNCHER_ARGS%) that are added to the config and also mentioned in the error message above. These 2 variables are their for Visual Studio and are replaced by Visual Studio when you try build and run your app. For example when you do a debug build, the web.config is transformed to: <aspNetCore processPath=" C:\Program Files\dotnet\dotnet.exe " arguments=" exec &quot;C:\projects\sampleapp\bin\Release\netcoreapp2.2\sampleapp.dll&q...

On one of my projects we are ‘default literals’, one of the features introduced in C#7.1.  To be able to use this, you have to change your project properties to point to the latest minor version(more information here: https://bartwullems.blogspot.com/2017/09/how-to-start-using-c-71.html ). Unfortunately on the build server it didn’t work as expected, but got the following error in our build logs: error CS8107: Feature ‘default literal’ is not available in C# 7.0. Please use language version 7.1 or greater. The strange this was that on the same build server,  another build using the same feature did succeed. So it couldn’t be linked to the possibility that C# 7.1 was not installed on the build server. Then I got some inspiration, maybe it was related to the Build Configuration. And indeed when I switched from Debug to Release the problem appeared in my Visual Studio as well: When enabling C# 7.1 for this project, a <langversion> is introduced in the csproj ...

Yesterday I lost some time searching the exact parameters to publish a specific publish profile using Web Deploy. To help me get this done faster in the future, here are the correct parameters I used (with some explanation): /p:DeployOnBuild=true –> Triggers web deploy /p:PublishProfile=Development –> The name of the Publish Profile that should be used /p:AllowUntrustedCertificate=True –> This is only necessary if the server certificate doesn’t match the server name(which normally shouldn’t be necessary) /p:username=WebDeployUser  --> The IIS user account used to connect to the IIS Web Management service(WMSVC) /p:password=WebDeployPassword –> The password of the IIS user account

After setting the Language version to C# latest minor version for my project, our TFS build started to fail with the following error message: Error CS1617: Invalid option 'latest' for /langversion; must be ISO-1, ISO-2, Default or an integer in range 1 to 6 While looking through the build logs I noticed that the build server was still using MSBuild v14 instead of 15. I first thought that my build agents were not up to date, so I triggered an upgrade: http://bartwullems.blogspot.be/2017/09/team-foundation-serverupgrade-your.html This made no difference, the used build tasks were not able to discover the newer version of MSBuild on the build server as they didn’t use VSWhere.exe yet. In the end I decided to do an upgrade of TFS(a TFS 2017 instance) to TFS 2017 Update 3. After doing that, a new version of the Build task was available that correctly found MSBuild v15.0 and allowed me to use the new C# features. Finally!

When trying to build a newly created project on our build server, it failed with the following error message: ##[error]CSC(0,0): Error CS5001: Program does not contain a static 'Main' method suitable for an entry point I was using the new async main functionality in C# 7.1 but for a reason I didn’t understand the build server didn’t pick this up. Locally however, everything was working as expected. The only difference I noticed that I was building on my machine with a Debug configuration whereas on the Build server a Release configuration was used. And indeed after changing my local settings to Release, my build started to fail. Lesson learned: You have to change the Language Version for every configuration you are using…