opened
dougbu
username_0
- #22556
- make `-BuildNative` primarily useful when you want _only_ native assets
- remove `-ForceCoreMsbuild` option

nit: extra `Remove-Item`s caused `MSBuild` function to do redundant work
Build native assets by default
issue
created
dougbu
username_0
https://dev.azure.com/dnceng/internal/_build/results?buildId=674531 demonstrated the success of this change in addressing #22556. The Windows build worked fine though the `dotnet test`s failed miserably (perhaps they need `--no-build`❔).
comment
created
dougbu
username_0
After my update:
- [20200607.1](https://dev.azure.com/dnceng/internal/_build/results?buildId=675255&view=results) run of aspnetcore-blazor-daily-tests failed about the same way; build was fine `dotnet test` not so much
- [20200607.1](https://dev.azure.com/dnceng/public/_build/results?buildId=675252&view=results) succeeded and demonstrated more of our build scripts are working fine these days.
comment
created
jkotalik
username_1
Can you clarify this statement a bit more? So now calling `build.cmd -BuildNative` will only build native bits?

I think this breaks the build.cmd script in the IIS folder: https://github.com/dotnet/aspnetcore/blob/master/src/Servers/IIS/build.cmd. Could you adjust that accordingly?
comment
created
dougbu
username_0
@username_1 good catch. That command previously worked because desktop `msbuild` would handle any `*.vcxproj` dependencies of the managed projects listed. The `$(BuildNative)` setting made sure those dependencies weren't ignored. Now, the script will attempt to build the managed projects using desktop `msbuild` and fail unless the system has VS 16.6.0 (actually preview 2 IIRC) or later.

Fix is simply to remove `-buildNative` from the command line. Will do before I merge.
comment
created
dougbu
username_0
That command has always done that. The differences are
1. `.\build.cmd -projects {some projects}` will build the projects using `dotnet msbuild` while `.\build.cmd -buildNative {some projects}` will build them using desktop `msbuild`
2. `.\build.cmd` will build both managed and native projects because native projects are built _except_ if you specify `-noBuildNative`
comment
created
jkotalik
username_1
Does that mean you need to have the VS toolsets necessary to build native for build.cmd to succeed? What happens if I call build.cmd without having it installed?

We made a very conscious decision to make it so build.cmd wouldn't build native dlls, as it isn't easy to have everything installed and slows down the build process.
comment
created
dougbu
username_0
@username_1 the answer depends on the specific build.cmd script you run. The problem without the fixes we've made over the week or so (starting with 14d6b6e28661) is builds using desktop `msbuild` failed miserably with VS 2019 16.5 or earlier failed because that `msbuild` didn't understand `net5.0`.

We're not in the perfect place with this. But, it's better than those failures or (worse) having to run `.\build.cmd` multiple times to pick up the native assets needed in the shared framework i.e. to get the CI builds working.

In any case, those who don't care about building the shared framework properly or aren't testing with IIS can execute `./build.cmd -noBuildNative`. The native build takes about 3 minutes for the rest of us.
comment
created
jkotalik
username_1
From my experience, it takes significantly longer than 3 minutes on CI to build native. I was seeing ~15 minutes when I was testing ways to speed up build times for our CI.
comment
created
dougbu
username_0
I'm not so sure. We also have issue #6304 about having the root build.cmd script building everything.

If we do something here, would be separate from `-buildNative` because that has the side effect of changing how `-projects` is interpreted. Maybe `-includeNativePhase`❔ One concern would be the need to change a bunch of the YAML and build.cmd|ps1 files to get the CI working again ☹️
comment
created
jkotalik
username_1
If that's the direction for the root build.cmd, I think that's fine. I think I'm most concerned about the subdirectory build.cmd calls and how they are affected. For example, what happens when calling src/Servers/Kestrel/build.cmd when someone doesn't have the native dependencies installed? Does the build fail? That's my main concern.
comment
created
dougbu
username_0
build.ps1 isn't smart enough to notice the user lacks the needed `msbuild` components to build native projects. So, it'll run desktop `msbuild` with `/p:BuildNative=true` that global property means the [override here](https://github.com/dotnet/aspnetcore/blob/master/eng/Common.props#L14) doesn't work and the build will fail.

This brings to mind another solution option if we decide the experience is significantly degraded: We could figure out a way to skip the native phase when the needed `msbuild` components are missing, a bit like what we do when NodeJS isn't found. The other option is to fail up front, a lot like we do when Java isn't found. (Notice the inconsistency there ☹️)

@username_1 should we move this to a new issue on the DoI board❔ I suspect we want to change something somewhere and am not surprised given how quickly we've pivoted to using `dotnet msbuild` by default then cleaning up.
comment
created
jkotalik
username_1
I'd be okay with that option. We could briefly bring this up at DoI as well.
comment