You have your own ASP.NET Core project that using Orchard Core NuGet packages, but every time when you update them you have to do it one-by-one across the whole solution? Wouldn't it be easier to just update the package versions in one place? Then you may need to have a Directory.Build.targets file to define the versions! MSBuild projects that use the standard build process (importing Microsoft.Common.props and Microsoft.Common.targets) have several extensibility hooks that you can use to customize your build process. Directory.Build.targets is imported from Microsoft.Common.targets after importing .targets files from NuGet packages. So, it can override properties and targets defined in most of the build logic, but sometimes you may need to customize the project file after the final import. Without going into too much detail, Directory.Build.targets can be used to provide customizations to project files located under a certain directory, this means that if you create such a file at the root of your solution, it would normally be able to customize all the .csproj files in your solution as they would exist in the child directories. Let's see a small example! Imagine you have an ASP.NET Core web application with a MyAwesomeWebApp.Web.csproj file. If you referenced Orchard Core in this project, your file contains a similar section: <ItemGroup> <PackageReference Include="OrchardCore.Logging.NLog" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.Application.Cms.Targets" Version="1.0.0-rc1-10106" /></ItemGroup> I assume you also have some custom modules and themes in your solution. The .csproj file of your module (MyAwesomeModule.csproj) could contain a section like: <ItemGroup> <PackageReference Include="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.Module.Targets" Version="1.0.0-rc1-10106" /></ItemGroup> where the OrchardCore.Module.Targets is mandatory if it is a module. Imagine that your theme (MyAwesomeTheme.csproj of course) has the following: <ItemGroup> <PackageReference Include="OrchardCore.Theme.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Include="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /></ItemGroup> You can see that we referenced OrchardCore.DisplayManagement and OrchardCore.ResourceManagement packages multiple times. If there will be a new release of Orchard Core we have to make sure that we use the same versions of every package across the whole solution. And if we have several projects we have to change the version numbers in every project one by one. To solve this issue add a Directory.Build.targets file at the root of your solution. We set the version in this file and specify how each <PackageReference /> should be updated by MSBuild. Note that here we have to use Update instead of Include. <?xml version="1.0" encoding="utf-8"?><Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <!-- Implicit Package References --> <PackageReference Update="OrchardCore.Application.Cms.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.DisplayManagement" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Logging.NLog" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Module.Targets" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.ResourceManagement" Version="1.0.0-rc1-10106" /> <PackageReference Update="OrchardCore.Theme.Targets" Version="1.0.0-rc1-10106" /> </ItemGroup></Project> Now let's rewrite the content of all the .csproj files and see the result of the MyAwesomeTheme.csproj for an example! The Include attribute specifies the package ID and the Version attribute specifies the version of the package to restore. But as you can see here the only change we did is to remove the Version attribute. <ItemGroup> <PackageReference Include="OrchardCore.Theme.Targets" /> <PackageReference Include="OrchardCore.DisplayManagement" /> <PackageReference Include="OrchardCore.ResourceManagement" /></ItemGroup> Now nothing will stop you from easily update the Orchard Core NuGet packages of your ASP.NET Core website! Did you like this post? It's part of our Orchard Core Nuggets series where we answer common Orchard questions, be it about user-facing features or developer-level issues. Check out the other posts for more such bite-sized Orchard Core tips and let us know if you have another question!

Installing the recently released Anniversary Update (version 1607) of Windows 10 seems to destabilize IIS by shutting down Application Pools, thus resulting in a 503 error when trying to run an application, which is caused by some DLLs failing to load when the worker process starts. Fortunately, the lovely folks of the interwebz are coming to the rescue! First, check out the Windows Event Viewer (Win+X, V) to see what you need to fix: Open "Windows Logs", then "Application" and look for "Error" level entries with the source "IIS-W3SVC-WP" (may be different if the name of your IIS instance is not the default one). In the details, you will see a short message, like this: The Module DLL <path-to-DLL> failed to load. The data is the error. Depending on your configuration, there may be different DLLs causing this kind of problem and they will occur one by one, so you will need to keep checking the Event Logs and fix the issues until your application properly starts up. To be sure, before every attempt, stop IIS and close IIS Manager. Here are two specific issues we've experienced so far and how to fix them, but you may bump into completely different ones: "C:\WINDOWS\system32\inetsrv\rewrite.dll" (reference) Go to "Programs and Features" (Win+X, F) and repair "IIS URL Rewrite Module 2". "C:\WINDOWS\system32\inetsrv\aspnetcore.dll" (reference) Go to "Programs and Features" (Win+X, F) and repair "Microsoft .NET Core 1.0.0 - VS 2015 Tooling ...". Happy updating!