Besides the AccelerateBuildsInVisualStudio MSBuild property, because environment variables are turned into MSBuild properties, you can define a AccelerateBuildsInVisualStudio environment variable.
VS is a long-running process that has a lot of information about your code available in memory at the moment a build is requested. This is how we can determine whether a build can be avoided in just a few milliseconds. By contrast, a command-line build is starting from cold. Another difference between builds in VS and on the command line is that VS supports solutions using a mix of build systems. While most VS projects use MSBuild, not all do and so the approach to building code in VS is quite different to the CLI.
@@drewnoakes Thanks for the detailed reply! I am just looking forward to this issue from the perspective of a dotnet user. dotnet on cli is fast, if it can add similar feature, dotnet will get more love from developers. :)
AFAIK it can be turned on globally by putting the Directory.build.props file in the root folder of the drive. Unless there's a D.B.P file between the project directory and the root, that is. MSBuild will look for a file with that name in the parent folder, and if not found, its parent folder and so on until it finds one. But unlike editorconfig, it'll stop once it finds one. Though it is possible to use that DBP file to tell it to look again in the parent folder etc. It would also be possible to edit the main build file in the VS installation folder/tree, but that might be nuked by update. Note that trying to make it global in either of these ways is incredibly heavy handed and I wouldn't suggest doing it. It'll break stuff, or not work because there's another DBP file you missed etc. 😅
Yes D.B.props could be placed higher in the tree, but I wouldn't recommend this for two reasons. Firstly, it's unlikely that any one build property applies to every projects you might conceivably want to build. Secondly, if a solution already ships a D.B.props file, then it has to explicitly chain to an ancestor instance. Most repositories won't look for one above their own top-level one. What this means in practice is that the property would only apply to the subset of repositories that don't have a D.B.props file already, which limits how helpful such a strategy could be. Better to identify the projects for which Build Acceleration works and opt them in explicitly for now.
Besides the AccelerateBuildsInVisualStudio MSBuild property, because environment variables are turned into MSBuild properties, you can define a AccelerateBuildsInVisualStudio environment variable.
Sounds cool! Can it be a dotnet build feature or used in dotnet cli?
VS is a long-running process that has a lot of information about your code available in memory at the moment a build is requested. This is how we can determine whether a build can be avoided in just a few milliseconds. By contrast, a command-line build is starting from cold. Another difference between builds in VS and on the command line is that VS supports solutions using a mix of build systems. While most VS projects use MSBuild, not all do and so the approach to building code in VS is quite different to the CLI.
@@drewnoakes Thanks for the detailed reply! I am just looking forward to this issue from the perspective of a dotnet user. dotnet on cli is fast, if it can add similar feature, dotnet will get more love from developers. :)
AFAIK it can be turned on globally by putting the Directory.build.props file in the root folder of the drive. Unless there's a D.B.P file between the project directory and the root, that is.
MSBuild will look for a file with that name in the parent folder, and if not found, its parent folder and so on until it finds one. But unlike editorconfig, it'll stop once it finds one. Though it is possible to use that DBP file to tell it to look again in the parent folder etc.
It would also be possible to edit the main build file in the VS installation folder/tree, but that might be nuked by update.
Note that trying to make it global in either of these ways is incredibly heavy handed and I wouldn't suggest doing it. It'll break stuff, or not work because there's another DBP file you missed etc. 😅
Yes D.B.props could be placed higher in the tree, but I wouldn't recommend this for two reasons. Firstly, it's unlikely that any one build property applies to every projects you might conceivably want to build. Secondly, if a solution already ships a D.B.props file, then it has to explicitly chain to an ancestor instance. Most repositories won't look for one above their own top-level one.
What this means in practice is that the property would only apply to the subset of repositories that don't have a D.B.props file already, which limits how helpful such a strategy could be. Better to identify the projects for which Build Acceleration works and opt them in explicitly for now.
@@drewnoakes I always put a D.B.props at the solution level to avoid any higher up D.B.props leaking into my solutions.
Does it test to make sure interfaces in the libraries didn't break compatibility?
Yes, if you change a public API then any referencing projects are built accordingly.
Excellent! I kind-of feel like this is the way it always should have been done... 🤔
A bit "command liney"? We are programmers, we don't need graphical buttons for every knob. I feel you are treating us as incompetent idiots