On a buildserver, you always do clean rebuilds. (Azure does allow you to break this rule and use non-clean work environments. But Reproducibility frowns on this approach. People have learned the hard way that not having reproducible builds can cause so much pain you'll be scarred for life).

You could have different project files for building dev machine vs build server. Maintaining that will be an error-prone drag, so you should script the auto-generation of the build server csproj files from the standard ones. The build server can then get dependencies from nuget, whilst the dev machine uses source and also pushes updates of successfully built libraries to the nuget feed.

NuGet feeds with symbols offers the most-mainstream and probably most-simple solution. Probably because that nuget capability has been designed to solve what may be your problem: give me the fastest possible builds but also access to source code when debugging.

You could have different project files for building dev machine vs build server. Maintaining that will be an error-prone drag, so you should script the auto-generation of the build server csproj files from the standard ones. The build server can then get dependencies from nuget, whilst the dev machine uses source and also pushes updates of successfully built libraries to the nuget feed.

NuGet feeds with symbols offers the most-mainstream, and simplest, attempt to solve this.

Nuget can give you the full “source code when debugging” experience because you can publish to Nuget including source symbols. This is covered on the same page at the anchor,

On the developer machine you would then replace dependencies on projects in the solution with dependencies on the NuGet package. You then get the normal nuget experience of:

• the nuget feed compiled .dlls will be cached on your machine
• NuGet will tell you when updates are available
• You choose when to get latest ; OR you can enforce always update on build ; OR you can enforce always update on checkout.

Force update-on-checkout will give you the source-code-style experience of always looking at the (nearly) latest code whilst keeping the fastest possibly build from binary whilst you are developing. You can force update-on-git-checkout by adding a git post-checkout hook to run nuget update, so that every git get latest will simultaneously get-latest from nuget. https://ddg.gg/example%20git%20oncheckout%20hook%20windows.

There is no out-of-the-box solution for this because it is an unusual requirement. Instead, ask again what exactly are you trying to achieve?

If you merely want to be confident that you are building from the very latest sources, then Option 1 already resolves this -- give or take a few seconds -- for both build server and dev machines, because your Azure nuget feeds will always contain the very latest builds. In fact, if you have automated tests, Option 1 is better than build from source, because it used the 'most recent source that builds and passes tests' rather than 'most recent thing someone accidentally checked in'.

On a buildserver, you always do clean rebuilds. (Azure does allow you to break this rule and use non-clean work environments. But Reproducibility frowns on this approach. People have learned the hard way that not having reproducible builds can cause so much pain you'll be mentally scarred for life)

You could have different project files for building dev machine vs build server. Maintaining that will be an error-prone drag, so you should script the auto-generation of the build server csproj files from the standard ones. The build server can then get from nuget, whilst the dev machine references source and also pushes updates of successfully built libraries to the nuget feed.

Nuget can give you the full “source code when debugging” experience because Nuget publish can include source symbols. This is covered on the same page at the anchor,

On the developer machine, replace dependencies on projects in the solution with dependencies on the NuGet package. You then get the normal nuget experience of:

• NuGet caches compiled .dlls from the feed on your machine
• NuGet will tell you when updates are available
• You choose when to get latest ; OR you can enforce always-update-on-build ; OR you can enforce always-update-on-checkout.

Force update-on-checkout will give you the source-code-style experience of always looking at the (nearly) latest code but still have the fastest possibly build from binary. You can force update-on-git-checkout by adding a git post-checkout hook to run nuget update, so that every git get latest will simultaneously get-latest from nuget. https://ddg.gg/example%20git%20oncheckout%20hook%20windows.

There is no out-of-the-box solution for this because it is an unusual requirement. The 'simple' approach is to have separate projects and solutions. Instead, ask again what exactly are you trying to achieve?

If you just want to be sure of building from very latest sources, then Option 1 already resolves this -- give or take a few seconds -- for both build server and dev machines, because your Azure nuget feeds will always contain the very latest builds.

( In fact, if you use automated tests, Option 1 is better than build from source, because it used the 'most recent source that builds and passes tests' rather than 'most recent thing someone accidentally checked in'. )

On a buildserver, you always do clean rebuilds. (Azure does allow you to break this rule and use non-clean work environments. But Reproducibility frowns on this approach. People have learned the hard way that not having reproducible builds can cause so much pain you'll be scarred for life).

You could have different project files for building dev machine vs build server. Maintaining that will be an error-prone drag, so you should script the auto-generation of the build server csproj files from the standard ones. The build server can then get dependencies from nuget, whilst the dev machine uses source and also pushes updates of successfully built libraries to the nuget feed.