Ran into another interesting one when working with a .NET Core 3.0 project and Entity Framework Core – this time, RuntimeIdentifier configuration causing trouble. In short, running Update-Database (to apply code-first migrations to your local database) locally would return this, annoying error: Failed to load the dll from [runtimepath]\win-x86\hostpolicy.dll], HRESULT: 0x800700C1 An error occurred while loading required library hostpolicy.dll from [runtimepath]\win-x86\] I suspect this can happen with any x86 runtimeIdentifier, but the one I had specified in my .csproj-file was this: <RuntimeIdentifier>win-x86</RuntimeIdentifier> This value (or…Continue reading EF Core fails to load hostpolicy.dll when RuntimeIdentifier is win-x86
This was another peculiar one – something, that didn’t bring up too many results on Google. Always fun trying to figure out those! So, when configuring an Azure DevOps pipeline (build) for a .NET project, you might run into this annoying error: ##[error]The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory. Job: “The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages. Please specify…Continue reading Azure DevOps build fails with “The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages.”
There’s now a new version of the assembly Microsoft.IdentityModel.Clients.ActiveDirectory available – plenty of reasons to update right away! Let me offer you one hot take on the matter since the earlier 3.x -versions of the package had some issues. Why bother updating? In an earlier post I described an issue I had with Microsoft.IdentityModel.Clients.ActiveDirectory.Platform not getting copied during the build in a referencing project. In 3.17.0, which the developers published this month, they fixed the issue! The new package actually contains separate DLLs for different platforms. In…Continue reading New version of Microsoft.IdentityModel.Clients.ActiveDirectory (ADAL.NET) is out – good time to update!
Visual Studio failing to copy a referenced assembly to a project in build might lead to surprising runtime errors. This post will explain one method of fixing these issues, using Microsoft.IdentityModel.Clients.ActiveDirectory as the example – as earlier versions of that assembly had this issue! Problem After build, you might get this kind of error: Could not load file or assembly ‘Microsoft.IdentityModel.Clients.ActiveDirectory.Platform, Version=22.214.171.1246, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified. System.IO.FileNotFoundException at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,…Continue reading A quick (and handy!) hack to force referenced assembly to getting copied to a project
This post describes a few different ways of fixing the error “The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.” one can get encounter this issue at least when trying to package/publish a SharePoint solution, web site or an Azure Webjob. Symptoms Visual Studio throws the following error when packaging a SharePoint solution to a .wsp file, OR when deploying or publishing your…Continue reading Fixing error: “The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”