Comments (15)
In general we need to be killing environment variables. Letting them influence our build this way is just creating a new razzle. Not our goal.
Instead use explicit parameters
from source-build.
I still have a inkling that the CLI could do something better to support this scenario. Maybe an option that doesn't set these env vars?
For sure, the "CscToolExe" env var is a hack. This doesn't work for non-built-in languages like F#, so why do we do C# this way?
The other 2 env vars MSBuildExtensionsPath
and MSBuildSDKsPath
are necessary though, it tells dotnet msbuild
where to find its assets.
I'd hate tell people that they can't/shouldn't use dotnet msbuild
to build their MSBuild projects, and they they have to go about finding/restoring/installing their own MSBuild just to build an MSBuild project. You should be able to use dotnet msbuild
in the normal cases.
from source-build.
It is still the case that we don't want anyone being dependent on the internal folder layout of the .NET Core SDK. So if you are still assuming that MSBuild.dll
is in a specific location of the SDK, then it still needs to be changed.
from source-build.
That being said, I also think we need to fix certain repos - like corefx - that don't use the CLI's dotnet to build on Windows, but use it to build on Linux. I think building corefx should be consistent across platforms.
Totally agree that is something that is being worked on by @joperezr
from source-build.
from source-build.
@eerhardt do you know if this is still the case?
from source-build.
@eerhardt I agree that we should try to use dotnet msbuild instead of assuming its location in the CLI and I also prefer that over downloading our own msbuild to use. What do you think is the right solution here? Should we fix the repos that don't work with this env variable or fix the CLI to stop setting them? Or do we have some extension point to try and clear those variables?
from source-build.
What do you think is the right solution here?
I think the right solution is what I said on Mar 7. #58 (comment)
I think the CLI needs to change to allow for this scenario.
from source-build.
If that is the case it sounds like we need a CLI issue tracking this so we can make some progress. cc @livarcocc @nguerrera
from source-build.
That being said, I also think we need to fix certain repos - like corefx - that don't use the CLI's dotnet
to build on Windows, but use it to build on Linux. I think building corefx should be consistent across platforms. Instead today it uses whatever MSBuild is on the path, which is different between machines, and different between command prompts on the same machine.
from source-build.
I would like to understand why it's a requirement to let any constituent repos of source build override the compiler that is used. Ultimately, everything should be building with the same LKG toolset.
from source-build.
Because as it currently exists, different repos use different toolsets.
For example, coreclr and corefx use BuildTools, which currently brings its own MSBuild, Roslyn, etc. And on Windows, these repos currently use whatever MSBuild.exe is on the $Path, so there's another toolset.
The cli repo uses a different toolset to build - it uses a previously build .NET Core SDK which has a different MSBuild, Roslyn, etc.
I agree we should be moving towards using the same toolset, but it is taking a long time to get there. And to me it doesn't look like it is happening any time soon.
Another reason is because there are varying needs between the repos, and the same toolset may not work for all repos at all times. For example, right now corefx is using C# 7.2 and the latest Roslyn compiler. However, the latest Roslyn compiler is breaking coreclr. See dotnet/coreclr#14002 (comment). So in this case, we would be blocking corefx from moving forward because coreclr can't take the updated compiler.
from source-build.
dotnet/cli#7311 by @khyperia will remove the setting of CscToolExe. :) It is going in to 15.5 SDK. I think we wait until source build can use a 15.5+ SDK as LKG and then switch source-build to plain dotnet msbuild
. I'm not worried about dotnet path/to/msbuild.dll
in the meantime because 2.0 SDK layout won't ever change.
from source-build.
We just took a PR in master from @khyperia where we are no longer setting CscToolExe
.
from source-build.
Applies to build.ps1
, build.sh
, and support/tarball/build.sh
.
from source-build.
Related Issues (20)
- [release/9.0] Building runtime failed with `ILCompiler.CodeGenerationFailedException` HOT 5
- Consider adding vulnerability detection to PR checks in SBRP HOT 3
- Reenable PublishSelfContained scenario test
- VMR Stage2 build fails with `error MSB1006: Property is not valid.` HOT 13
- [internal/release/9.0.1xx-rc1] All legs are building fails with `11 new packages used not in baseline` HOT 6
- License scan failure due to timeout of .il files
- Disable public runs of SDK diff and license scanning after 9.0 GA HOT 2
- [internal/release/9.0.1xx-rc1] All tests are failing in VMR HOT 2
- UB support for internal-only product builds HOT 2
- [main] Alpine tests fail loading ld-linux-x86-64.so.2 HOT 6
- [main] Stage 2 build is failing in prep step trying to find 9.0 P7 HOT 3
- 2 new binaries introduced into VMR HOT 4
- [internal/release/9.0.1xx-rc1] License scan failure due to timeout of .il files HOT 1
- WPF - sRGB Color Space Profile.icm is non-free HOT 7
- Automate the process to cleanup unreferenced SBRPs
- Update pipeline to test on Fedora 41 HOT 1
- Expand the scanning tools used for license detection for better coverage HOT 4
- Implement a strategy to publish productVersion.txt produced by the vertical build
- Unified Build Fit and Finish HOT 2
- VMR does not properly respect pre-set NUGET_PACKAGES paths HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from source-build.