[release/10.0.2xx] Source code updates from dotnet/roslyn#3244
[release/10.0.2xx] Source code updates from dotnet/roslyn#3244dotnet-maestro[bot] wants to merge 25 commits intorelease/10.0.2xxfrom
Conversation
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
…f69-499b-a68e-fb46180df7a5
…a68e-fb46180df7a5
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/product-construction for assistance. |
…a68e-fb46180df7a5
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
…a68e-fb46180df7a5
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
|
The error "Unable to find a stable package Microsoft.DotNet.FileBasedPrograms" should be fixed by a change made in dotnet/roslyn#81105 |
…a68e-fb46180df7a5
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
|
Looks like some build infra issue that SDK repo cannot access a package from the Roslyn repo: src/sdk/src/BuiltInTools/dotnet-watch/dotnet-watch.csproj(0,0): error NU1102: (NETCORE_ENGINEERING_TELEMETRY=Restore) Unable to find package Microsoft.CodeAnalysis.Contracts with version (>= 5.3.0-ci) |
…a68e-fb46180df7a5
…10.0.2xx-320cebc1-5f69-499b-a68e-fb46180df7a5
|
Note PRs from original repository included in this codeflow update:
💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
|
@jjonescz no, it looks like that package didn't get built when building roslyn for some reason: |
|
It does get built in the Windows job so maybe a Linux/source-build issue |
|
Now the error is different ;) |
| <Uri>https://github.com/dotnet/runtime</Uri> | ||
| <Sha>9d5a6a9aa463d6d10b0b0ba6d5982cc82f363dc3</Sha> | ||
| </Dependency> | ||
| <Dependency Name="Microsoft.DotNet.FileBasedPrograms" Version="10.0.200-preview.0.25556.104"> |
There was a problem hiding this comment.
This is not allowed. You can't take a dependency on a package from the SDK until that package version has been shipped. This is because of the repo build order. roslyn builds before sdk. So if you want something from sdk, it needs to have shipped first. Bootstrapping the VMR to be based on a newer SDK is not an option either. That's only allowed during 1xx previews.
There was a problem hiding this comment.
But the package has shipped from the VMR already, it's merged in the release/10.0.2xx branch. This PR came afterwards.
There was a problem hiding this comment.
By "shipped" I mean "included in a release". In other words, it would need to be included in the 10.0.200 release which hasn't happened yet.
There was a problem hiding this comment.
I see, thanks. That's... unfortunate. cc @RikkiGibson
There was a problem hiding this comment.
Yes, this is a source build requirement.
There was a problem hiding this comment.
In a true monorepo, I think this would be pretty straightforward to represent, by just putting the sources in a directory which is referenced by both roslyn and SDK, for example.
Agreed, and that's what I'm trying to emulate with referencing the sources from SDK directly when in VMR.
The fact that this is just a source package (i.e., we just need the source files, no binaries) feels to me like this sort of dependency should be allowed since we don't actually need building SDK before Roslyn.
There was a problem hiding this comment.
For local dev, it would be sufficient to just restore the sources package and then edit it, if it's just a sources package that you want to make manual edits to...no need to rebuild roslyn or do a dual repo layout. The circular reference is a problem, whether or not it's a source-only package. The VMR might allow you to kind of cheat this, but the layering problem still exists as soon as you step outside of the VMR.
What is the plan when this feature ships? Will the source be included in the SDK, such that roslyn just references the LKG from the last shipped SDK?
There was a problem hiding this comment.
The VMR might allow you to kind of cheat this, but the layering problem still exists as soon as you step outside of the VMR.
I thought the product ships out of VMR these days, so that's all that matters?
What is the plan when this feature ships? Will the source be included in the SDK, such that roslyn just references the LKG from the last shipped SDK?
I'm not sure what you mean by this. Why would there need to be a specific/different plan for "when the feature ships"? I would imagine we would just do what we are trying to do now.
Anyway, if this is a problem, we can perhaps do a simple change here to have a copy of the sources in both roslyn and sdk, and have a super simple GitHub Action that will alert us if they are out of sync.
There was a problem hiding this comment.
The copy approach that has been taken before when there is shared source. I think that would be better. I think between aspnetcore and runtime. The VMR shouldn't be used to ignore repo layering.
What you could do, is add the source package as a Toolset dependency (this avoids layering issues). At roslyn PR time, read the contents of the package and compare to the checked in versions.
There was a problem hiding this comment.
Thanks. Didn't find how exactly aspnetcore/runtime do this; but I did it via a PackageDownload and a test script: dotnet/roslyn#81284
If you're not able to configure the repo to reference |
If you really need this version, it also needs to be defined in SBRP. Otherwise, just use the |
I'm not sure what even changed here, there were no changes to that package in long time afaict. Oh, I guess it might be missing
I can't imagine we would really need that patch version, let me try downgrading. |
|
Caution There was a conflict in the PR branch when flowing source from https://github.com/dotnet/roslyn/tree/5b20f50823167975bfd1b6dd55fcbdba73ff3a6c
Updates from this subscription will be blocked until the conflict is resolved, or the PR is merged 💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance. |
See dotnet/dotnet#3244 (comment). This should unblock our code flow to VMR. --------- Co-authored-by: Rikki Gibson <[email protected]>
Version 8.0.1 is causing source build errors in VMR: dotnet/dotnet#3244 (comment)

Note
This is a codeflow update. It may contain both source code changes from the source repo as well as dependency updates. Learn more here.
This pull request brings the following source code changes
From https://github.com/dotnet/roslyn