-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
9.0 .NET SDK shipping binaries from previous servicing bands #44370
Comments
It looks like a lot of these are in For the source generator cases we should not be deploying SCI at all. Compiler will load that so we can fix this by changing the builds to simply stop deploying that. |
Yeah that's what I mentioned here:
The part you quoted was meant to refer to the .NET build host - which I think is still targeting |
@marcpopMSFT - you should look at this and decide what to do for 9.0. |
Are you suggesting we fix this in servicing as that seems like something that has a high risk of us messing up? Regardless, it seems like there are a few different buckets in here:
I need @rainersigwald to weigh in on 1 as it sounds like that requires msbuild managing those dependencies. I need @jaredpar to comment on 3 and 4. Not sure the solution for the netfx tools. Do we just update the dependencies for each tool? I'll need @wtgodbe to comment on 5. |
In terms of (3) I think it's a fairly low risk change to remove the references. Think we should start by doing this in 9.0.200 and if that goes smoothly we can discuss back porting to 9.0.100. In terms of (4) that is a larger unknown (more complicated item and the main owner is temporarily on other items). I agree it's the right long term path though. So again would recommend try this out in 9.0.200 and if it goes well discuss back porting. |
Describe the bug
Similar to #44197 I did a broader scan of the SDK to find what other binaries it might contain from previous servicing bands. These don't have CVE's but if they did, we'd need to coordinate cross-release flow, or upgrade to newer packages.
Here's what I found:
I wonder if for many of these
net4x
copies if the answer is to exclude the binaries and rely on the copy from MSBuild or VS.For the case where the buildhost is pulling in 8.0.0 copies of packages - the fix here might be to have a version of that which targets 9.0. @jaredpar suggested that in #44197 (comment)
Checking on further references to out-of-date package versions I found the following old packages mentioned in deps files:
Ideally these would not be present in deps if they don't represent actual dependencies shipping in the SDK. Once we have supplied by platform it will be easier to clean these deps files up, but we may want to do something before then if any of these are likely to be serviced (like System.Text.Json).
To Reproduce
Examine the content of the SDK for stale versions. I have a tool that's dumping these that I can share.
Exceptions (if any)
None
The text was updated successfully, but these errors were encountered: