- 
                Notifications
    
You must be signed in to change notification settings  - Fork 440
 
Disable CheckEolTargetFramework for all projects #15222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 
           If I remember correctly the reason we had this in F# environment variables was that the command line variables weren't actually being propagated all the way through the build. I think it might be safer to add an EnvironmentVariable entry in Directory.Build.props instead of the StandardSourceBuildArgs.  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should consider backporting this to 6.0. With 3.1 reaching EOL, I would bet we will see EOL failures once the SDK check is enabled in a couple months.
| <StandardSourceBuildArgs>$(StandardSourceBuildArgs) /p:SourceBuildUseMonoRuntime=$(SourceBuildUseMonoRuntime)</StandardSourceBuildArgs> | ||
| 
               | 
          ||
| <!-- https://github.com/dotnet/source-build/issues/3081 --> | ||
| <StandardSourceBuildArgs>$(StandardSourceBuildArgs) /p:CheckEolTargetFramework=false</StandardSourceBuildArgs> | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work in most if not all cases. The reason is that build properties don't get automatically flown into the repo inner builds. An environment variable (example) would be the way to accomplish this given the way the system currently works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This documentation describes how the source-build works for a repo. The outer build properties do not flow into the inner build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichaelSimons - Does this mean that the original content that I removed from xliff-tasks wasn't actually working as intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means that in main/.NET 8.0, they removed the EOL TFMs that were causing the build to break. If you were to backport these changes to .net 7.0 or 6.0, I would suspect you would get a build failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...continuing that thought. I am sure you would get a build failure in FSharp. I can't answer why the xliff-tasks pattern works without looking at a binlog.
3784d07    to
    4327cd9      
    Compare
  
    | 
           Ok, I've updated to address the issue of flowing to the inner projects and also rebased to target release/6.0.1xx branch.  | 
    
This fixes the issue described in dotnet/source-build#3081 where source-build can encounter EOL TFMs during its build. This generates a warning which can then produce an error if warnings are treated as errors. We need to avoid having source-build be blocked by this situation.
So these changes disable the
CheckEolTargetFrameworkMSBuild property globally for all projects. It also removes some the disabling of that property that was targeted for a couple specific projects.Fixes dotnet/source-build#3081