dotnet
Try building once
@jmarolf for some reason Razor was being built twice, with ever so slightly different parameters on each. This looks to be causing problems with symbol uploads, as the PDB from one build is ending up in the VSIX built by another, which means checksums don't match.
Wondering if you have any idea as to whether combining them in this way will be safe? The main thing that concerns me is the msbuildEngine difference.
Obviously i'm going to do a test build to try and validate it all :)
Failed because there was no nuget restore done.. but it passes in -restore? No idea!
https://dev.azure.com/dnceng/internal/_build/results?buildId=2012965&view=logs&j=7c8326b9-0a5f-532a-e6de-db8515c72d9a&t=06c773de-aa2b-5fd5-6aaa-ea6cf87a3134&l=205
Changing msbuildengine doesn't have any effect. Putting Restore in the list of targets in rzls.csproj doesn't have any effect. ~Maybe i'll try just separating build and publish?~ Nope that doesn't make sense, its the pack command that seems like the one having issues, but they both have pack 🤷♂️
Looks like we build and restore completely different projects depending on the presence of the BuildVsix property: https://github.com/dotnet/razor-tooling/blob/1b38348c65e67a844e6691a26cabc95eac622036/eng/Build.props#L9-L11
If we are going to combine these builds then we should remove this property and instead have Razor.sln contain everything. If not building the vsix was originally done for perf reasons I can do some of the same optimizations I did for the roslyn build. Building with the dotnet version of msbuild (as opposed to vs) should be sufficient to skip the vsix targets.
Nice find!
Looks like it was done for perf, and to allow building net5 projects: https://github.com/dotnet/razor-tooling/pull/1902
I think our builds are fast enough and building Razor.sln is fine, we can just do it twice. I doubt there is anything we can do to deliberately slow down our build such that it will be slower than the node stuff :)
Val build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2013054&view=results
hmm, I don't understand why we build twice. the vs msbuild engine should be a super-set of the dotnet msbuild engine. We should be able to do everything in a single build. I could see using the dotnet msbuild engine for pull requests since it will be faster and (if I am reading this yaml correctly) we don't have to build the vsix since we are going to build in in the integration test pipeline anyway. It appears that there was some effort to split the build into "stages" which imho makes things a bit harder to reason about because now build steps implicitly depend on each other (like assuming restore has already run).
I would propose that we just have a single build step that does everything.
Perhaps it wasn't a superset at the time of that PR? If my val build passes then it will at least confirm that the vs build engine can build everything, so one build makes sense
New val build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2013190&view=results
Test insertion https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/428115
Damnit, SymbolCheck still failed, and failed worse now. Previously only one DLL wasn't uploading symbols, now its more of them. So previously the second build was causing issues, but only built one DLL. Now we only have one build, and its the one causing issues ¯\_(ツ)_/¯