Enable source-build pre-built detection #8492

NikolaMilosavljevic · 2023-03-22T20:52:04Z

Summary of the changes

The goal is to enable per-repo source-build to detect prebuilt packages.

NikolaMilosavljevic · 2023-03-22T20:52:14Z

333fred · 2023-03-22T20:54:10Z

eng/Versions.props

    <RoslynPackageVersion>4.6.0-3.23164.6</RoslynPackageVersion>
    <VisualStudioLanguageServerProtocolVersion>17.6.4-preview</VisualStudioLanguageServerProtocolVersion>
-    <MicrosoftNetCompilersToolsetVersion>4.6.0-2.23128.3</MicrosoftNetCompilersToolsetVersion>
+    <MicrosoftNetCompilersToolsetVersion>$(RoslynPackageVersion)</MicrosoftNetCompilersToolsetVersion>


This change does not look correct. What's the purpose of it?

I'm not sure if this change should be conditioned for source-build only. It makes sense for Microsoft.Net.Compilers.Toolset package to be consumed from the same build as other roslyn packages, as it is built in roslyn. However, I don't know if this was an omission or intentional.

Source-build consumes packages from other repos, via intermediate packages, therefore we require that all packages from one repo have a matching version.

333fred · 2023-03-22T20:54:22Z

eng/SourceBuildPrebuiltBaseline.xml

+    <UsagePattern IdentityGlob="Microsoft.SourceBuild.Intermediate.*/*" />
+
+    <!-- TODO:
+         Comment about missing sbrp packages and reference to tracking issue. -->


Missing comment?

Comment is coming once I open the tracking issue.

Fixed with f765403

NikolaMilosavljevic · 2023-03-22T20:54:56Z

eng/Versions.props

    <RoslynPackageVersion>4.6.0-3.23164.6</RoslynPackageVersion>
    <VisualStudioLanguageServerProtocolVersion>17.6.4-preview</VisualStudioLanguageServerProtocolVersion>
-    <MicrosoftNetCompilersToolsetVersion>4.6.0-2.23128.3</MicrosoftNetCompilersToolsetVersion>
+    <MicrosoftNetCompilersToolsetVersion>$(RoslynPackageVersion)</MicrosoftNetCompilersToolsetVersion>


I'm not sure if this change should be conditioned for source-build only. It makes sense for Microsoft.Net.Compilers.Toolset package to be consumed from the same build as other roslyn packages, as it is built in roslyn. However, I don't know if this was an omission or intentional.

I don't think it should be conditioned. I'm not sure why M.N.C.T should diverge from the rest of the roslyn depss. The versions currently in there suggests that maybe this was an oversight in the first place.

I know in VS Mac we have at times had to split roslyn dependency for IDE tooling, from roslyn version used to build, but those times were few and far between, and because of strange mono/mac/arm issues. I would hope we don't hit anything that exciting here, so keeping them in sync makes sense to me.

mmitche · 2023-03-22T21:06:49Z

eng/Versions.props

    <Tooling_MicrosoftCodeAnalysisTestingVersion>1.1.2-beta1.22512.1</Tooling_MicrosoftCodeAnalysisTestingVersion>
    <MicrosoftVisualStudioShellPackagesVersion>17.5.0-preview-2-33117-317</MicrosoftVisualStudioShellPackagesVersion>
    <MicrosoftVisualStudioPackagesVersion>17.5.274-preview</MicrosoftVisualStudioPackagesVersion>
    <RoslynPackageVersion>4.6.0-3.23164.6</RoslynPackageVersion>


This should change to be a property matching the version.details.xml element you added: https://github.com/dotnet/razor/pull/8492/files#diff-fb62e94a1d6f29f863e3d0a22aa38269f6cd1d7f03b109dc06e2cbf2548b86d3R13

MicrosoftCodeAnalysisCSharpVersion

OK - I'll introduce the property, but also keep using RoslynPackageVersion as it's used in many places in this file.

@mmitche I've updated the dependency and tweaked the implementation a bit, in 049cc5d

I think this is now a bit cleaner.

mmitche · 2023-03-22T22:38:49Z

eng/Versions.props

    <MicrosoftVisualStudioShellPackagesVersion>17.5.0-preview-2-33117-317</MicrosoftVisualStudioShellPackagesVersion>
    <MicrosoftVisualStudioPackagesVersion>17.5.274-preview</MicrosoftVisualStudioPackagesVersion>
-    <RoslynPackageVersion>4.6.0-3.23164.6</RoslynPackageVersion>
+    <RoslynPackageVersion>$(MicrosoftNetCompilersToolsetVersion)</RoslynPackageVersion>


We can't actually use proxy properties like this. Product source build won't be able to override RoslynPackageVersion since no package has that name. So, in source-build, any dependency using RoslynPackageVersion will retain its original value, leading to prebuilts.

So we need to remove RoslynPackageVersion and replace its use with MicrosoftNetCompilersToolsetVersion. If it is cleaner and you don't want to use MicrosoftNetCompilersToolsetVersion for, say Microsoft.CommonLanguageServer.Protocol.Framework, then you can add additional dependencies in eng/version.Details.xml/versions.props.

Hold up a second. I'm very concerned by the direction this change is going: we're talking about two completely unrelated concepts here. The toolset compiler is the version of the compiler that is used to build this repository. RoslynPackageVersion determines what Roslyn APIs the razor compiler and tooling expect when being run. Dynamically moving this forward for source-build would mean that we're compiling a configuration that we don't test.

We can't actually use proxy properties like this. Product source build won't be able to override RoslynPackageVersion since no package has that name. So, in source-build, any dependency using RoslynPackageVersion will retain its original value, leading to prebuilts.

How does this work today, is this already an issue? Bunch of properties are initialized with value of RoslynPackageVersion -

razor/eng/Versions.props

Lines 138 to 151 in 625b592

<MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>

<MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>

<MicrosoftCodeAnalysisCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCommonPackageVersion>

<MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>

<MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>

<MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>

<MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>

<MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>

<MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>

<MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>

<MicrosoftCodeAnalysisRemoteServiceHubPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisRemoteServiceHubPackageVersion>

<MicrosoftCodeAnalysisVisualBasicWorkspacesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisVisualBasicWorkspacesPackageVersion>

<MicrosoftCodeAnalysisWorkspacesCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisWorkspacesCommonPackageVersion>

<MicrosoftCodeAnalysisWorkspacesMSBuildPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisWorkspacesMSBuildPackageVersion>

Source-build doesn't really have an option to bifurcate these. There are essentially only two roslyn compilers which can be used:

The one coming in from previously source-built artifacts (i.e. previous SDK that was built).

The one built from the roslyn sources in the current build.

@333fred Why not simply use the same version for what you compile with and the surface area you're compiling against?

My concern is that the interaction between that version of roslyn's APIs and Razor has not been tested. I don't care so much about what version of the toolset compiler is used to compile Razor; I care much more deeply about what version of Roslyn we're referencing when we build.

Looking through a few of them, I think the properties are all used for PackageReferences that are excluded from the Linux source build.

So, in that case @NikolaMilosavljevic, we should leave the RoslynPackageVersion properties alone and use add a property/dependency for Microsoft.Net.Compilers.Toolset, like you did before.

If these projects ever get pulled into Linux source build, this will have to be resolved.

So essentially, source build is only overriding M.N.C.T version.

Microsoft.CodeAnalysis.Common and Microsoft.CodeAnalysis.CSharp were showing as prebuilts until I synchronized $(RoslynPackageVersion) with $(MicrosoftNetCompilersToolsetVersion). As mentioned before, source-build needs to consume packages from a single roslyn intermediate package, so versions naturally have to be the same.

I'm not sure if repo source-build would produce different prebuilts from product source-build, but I suspect they should be exactly the same.

Can you root cause why that synchronization is necessary (where the package refs are used). They do have to be synchronized if the package refs show up in source build. But it looks like most of refs were in projects excluded from source build, which would not affect the pre-builts.

eng/SourceBuildPrebuiltBaseline.xml

Co-authored-by: Jan Jones <[email protected]>

mmitche · 2023-03-23T17:33:30Z

eng/Versions.props

-    <MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
+    <!-- Microsoft.CodeAnalysis.Common and Microsoft.CodeAnalysis.CSharp packages are consumed in source-build.
+         Package version has to match roslyn repo reference as specified in MicrosoftNetCompilersToolsetVersion -->
+    <MicrosoftCodeAnalysisCommonPackageVersion>$(MicrosoftNetCompilersToolsetVersion)</MicrosoftCodeAnalysisCommonPackageVersion>


I think these are the right versions now. IMO it may be good to:

Rename RoslynPackageVersion to something like:
"RoslynSurfaceAreaVersion" to better reflect its usage.

Add new dependencies to eng/Version.Details.xml for CodeAnalysis.Common and CodeAnalysis.CSharp and use their values explicitly here. Their versions would be the same as Microsoft.Net.Compilers.Toolset.

mmitche · 2023-03-23T17:35:32Z

@333fred I want to a dig a little deeper here on razor's expected behavior and what is happening in source build.

The reason we don't see new prebuilts in source-build today is that RoslynPackageVersion is used to set MicrosoftCodeAnalysisCSharpPackageVersion (and other properties). Then those properties are used in the actual PackageReferences. In source-build, after eng/Versions.props is imported, we import the versions of roslyn that were built before razor, and that overrides these properties. So source-build has never been building razor against the roslyn that it is tested against in this repo.

The other thing to note is that when we layout the razor binaries into the non-source build .NET SDK, we do not deploy the Microsoft.CodeAnalysis.* version that razor is built against here. Instead, we use the roslyn version that flows into the SDK. Those are likely to be different.

Does it makes sense to simply remove RoslynPackageVersion altogether. Add individual dependencies to eng/Version.Details.xml for each of the places where it was used, and then have them all aligned. Therefore it will be very obvious if the toolset version and the roslyn surface area need to diverge, and source build will properly override them.

333fred · 2023-03-23T18:06:30Z

I don't think we can just remove RoslynPackageVersion altogether; I would be concerned about unintentionally introducing instability into the IDE tests by doing so. I'm going to start a teams thread on this.

mmitche · 2023-03-23T18:11:18Z

I don't think we can just remove RoslynPackageVersion altogether; I would be concerned about unintentionally introducing instability into the IDE tests by doing so. I'm going to start a teams thread on this.

Okay sounds good. We should figure out what the desired behavior actually is, and how it may differ from what we have today in the various scenarios:

VS
SDK
Source-built SDK

If special properties are kept, they should be named well (e.g. RoslynSurfaceAreaVersion?), and we should add comments as to the expected behavior so that we don't have to deconstruct this again.

MichaelSimons · 2023-03-28T17:03:50Z

eng/SourceBuildPrebuiltBaseline.xml

+    <!-- Ignoring the following prebuilts. We do not have SBRP packages for
+         7.0 targeting packs and System.Text.Encoding.CodePages.6.0.0 package.
+         https://github.com/dotnet/source-build/issues/3341 -->
+    <UsagePattern IdentityGlob="Microsoft.AspNetCore.App.Ref/7.0.2" />


The reason for the two 7.0 targetting packs should be tracked with #8293. We do not want these to be solved with SBRP.

The reason for the two 7.0 targetting packs should be tracked with #8293. We do not want these to be solved with SBRP.

Updated with 66c7617

Added a reference to reasons for net7.0 targeting and acreference to new tracking issue for net7.0 targeting removal.

MichaelSimons · 2023-03-28T17:04:29Z

eng/SourceBuildPrebuiltBaseline.xml

+         https://github.com/dotnet/source-build/issues/3341 -->
+    <UsagePattern IdentityGlob="Microsoft.AspNetCore.App.Ref/7.0.2" />
+    <UsagePattern IdentityGlob="Microsoft.NETCore.App.Ref/7.0.2" />
+    <UsagePattern IdentityGlob="System.Text.Encoding.CodePages/6.0.0" />


Any reason this can't be added to SBRP right away before this is PR is merged in?

Any reason this can't be added to SBRP right away before this is PR is merged in?

Good idea - I'll add System.Text.Encoding.CodePages/6.0.0 sbrp package and update the comment to reference the other issue for 7.0 targeting packs.

Will update this file after SBRP PR is merged - dotnet/source-build-reference-packages#591

MichaelSimons · 2023-03-29T15:55:03Z

eng/Version.Details.xml

      <Uri>https://dev.azure.com/dnceng/internal/_git/dotnet-runtime</Uri>
      <Sha>839cdfb0ecca5e0be3dbccd926e7651ef50fdf10</Sha>
    </Dependency>
+    <Dependency Name="Microsoft.SourceBuild.Intermediate.source-build-reference-packages" Version="8.0.0-alpha.1.23159.2">


Have darc subscriptions been created for this and the new roslyn dependency?

Have darc subscriptions been created for this and the new roslyn dependency?

No, as I've noticed in some other per-repo prebuilt work, that subscriptions were created after PRs were merged. Perhaps it's irrelevant as it won't kick-in until these dependencies show up.

Do we also need coherency attributes for these new dependencies?

We do not. I also don't think we should create it for roslyn, unless it's set to 'none'. They try to match the roslyn that exists in VS.

My wording choice was poor. I was really asking if you were intending to define one. It feels like an SBRP subscription would be valuable.

Yeah, we should create one for SBRP.

I'm going to create a subscription for SBRP - should it be a daily or weekly subscription? I presume we don't want it to be manual.

@mmitche @MichaelSimons

NikolaMilosavljevic · 2023-04-10T15:01:46Z

@333fred @mmitche there were some initial concerns with direction of this work and some of the changes. Was everything addressed?

333fred · 2023-04-11T22:16:07Z

eng/Versions.props

    <MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>
    <MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>
-    <MicrosoftCodeAnalysisCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCommonPackageVersion>
-    <MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
+    <!-- Microsoft.CodeAnalysis.Common and Microsoft.CodeAnalysis.CSharp packages are consumed in source-build.
+         Package version has to match roslyn repo reference as specified in MicrosoftNetCompilersToolsetVersion -->
+    <MicrosoftCodeAnalysisCommonPackageVersion>$(MicrosoftNetCompilersToolsetVersion)</MicrosoftCodeAnalysisCommonPackageVersion>
+    <MicrosoftCodeAnalysisCSharpPackageVersion>$(MicrosoftNetCompilersToolsetVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
    <MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>
    <MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>
-    <MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
    <MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>
    <MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>
    <MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>


These all need to be the same version. The likelihood is really that we can entirely remove MicrosoftNetCompilersToolsetVersion and just make everything RoslynPackageVersion, and then update from source-build as needed. I'm still not super comfortable with that, but I think that if we move this version to being auto-updated by darc on a regular cadence that would ameliorate much of my concern about shipping a different product in source-build and everywhere else.

These all need to be the same version. The likelihood is really that we can entirely remove MicrosoftNetCompilersToolsetVersion and just make everything RoslynPackageVersion, and then update from source-build as needed. I'm still not super comfortable with that, but I think that if we move this version to being auto-updated by darc on a regular cadence that would ameliorate much of my concern about shipping a different product in source-build and everywhere else.

Source-build does not know about repo-specific meta properties like RoslynPackageVersion. Source-build needs to update versions of all packages consumed during-source build, to ensure that versions are correct and all dependent packages are available in offline package cache.

@mmitche is there anything we haven't tried to reconcile the differing requirements by razor's regular- and source- builds? We could set some of these properties differently, only in source-build, i.e. MicrosoftCodeAnalysisCommonPackageVersion and MicrosoftCodeAnalysisCSharpPackageVersion.

Source-build does not know about repo-specific meta properties like RoslynPackageVersion.

Sure, but it all needs to be the same version. There cannot be differing input versions or we're going to run into build problems.

Right, agreed. So I think you basically want to:

Remove RoslynPackageVersion, since it can't be updated by Maestro. Today this is updated manually.

Instead, use the properties that correspond to all the individual packages, and simply set their versions to be all identical. All of these dependencies should go into Version.Details.xml, or else source build will not properly override them with PVP flow.

Then, @333fred and his team decide on the build of roslyn that gets used in this repo. An update just sets all the package versions. That could either be done via darc update-dependencies manually, or via regular updates from roslyn through Maestro.

So, you get the same behavior today you have with RoslynPackageVersion, a predictable version. It just also gets used to compile the repo via MicrosoftNETCompilersToolsetPackageVersion.

Thoughts?

That sounds good. We've been talking about having things flow through Maestro (to eliminate the problem of source-build building a product we never test), but that setup will probably wait until after I'm back from vacation. For right now, the version being used in RoslynPackageVersion should work.

Pushed the changes to address this: 647f22f. I think it should be ok now.

Code-check is failing - will address it soon. Here are the errors:

2023-04-14T17:31:15.1977631Z error : Missing version variable 'MicrosoftSourceBuildIntermediatesourcebuildreferencepackagesPackageVersion' in the 'Automated' property group in D:\a\_work\1\s/eng/Versions.props 2023-04-14T17:31:15.1982203Z error : Missing version variable 'MicrosoftNetCompilersToolsetPackageVersion' in the 'Automated' property group in D:\a\_work\1\s/eng/Versions.props 2023-04-14T17:31:15.1986576Z error : Missing version variable 'MicrosoftCommonLanguageServerProtocolFrameworkPackageVersion' in the 'Automated' property group in D:\a\_work\1\s/eng/Versions.props 2023-04-14T17:31:15.1991069Z error : Missing version variable 'MicrosoftSourceLinkGitHubPackageVersion' in the 'Automated' property group in D:\a\_work\1\s/eng/Versions.props 2023-04-14T17:31:15.1995497Z error : Missing version variable 'MicrosoftDotNetXliffTasksPackageVersion' in the 'Automated' property group in D:\a\_work\1\s/eng/Versions.props 2023-04-14T17:31:15.2000084Z error : Version variable 'MicrosoftNetCompilersToolsetVersion' does not have a matching entry in Version.Details.xml. See https://github.com/dotnet/aspnetcore/blob/main/docs/ReferenceResolution.md for instructions on how to add a new dependency.

Code-check is clean now: 1f8ba5e

@333fred @mmitche I implemented the changes as discussed above. Can you take another look and approve?

333fred

@dotnet/razor-tooling for a look at this as well.

davidwengier

Changes look okay. Can someone summarize where we are for Roslyn dependencies here now?

Are we allowed to manually bump the version of Roslyn being used, or would that break source build?
If no, are we now getting automated Roslyn bumps through arcade?

NikolaMilosavljevic · 2023-04-25T00:36:05Z

Changes look okay. Can someone summarize where we are for Roslyn dependencies here now?

Are we allowed to manually bump the version of Roslyn being used, or would that break source build?

If no, are we now getting automated Roslyn bumps through arcade?

Full, product, source-build would set it's own versions for all packages - it would use live versions of all packages, including roslyn. Source-build leg in razor repo would use packages that are specified in Versions.props file.

You can update versions of all Roslyn packages either manually or automatically, by triggering Maestro subscription. @mmitche I presume there is a way to trigger subscription for one repo only, with a specific version number, is that correct? Or, does Maestro always updates to latest?

Either way, manual update is always possible, you'd simply update package versions in Version.Details.xml and Versions.props.

NikolaMilosavljevic · 2023-04-25T00:39:30Z

I've resolved the merge conflict - there is a mismatch in versions of new dependencies - working on updating those.

Once this PR is merged, there won't be similar issues due to CoherentParentDependency tags.

NikolaMilosavljevic · 2023-04-25T01:36:39Z

Checks are hitting some GitHub access issues... Will retry later.

NikolaMilosavljevic · 2023-04-25T06:38:48Z

/azp run

azure-pipelines · 2023-04-25T06:38:53Z

Commenter does not have sufficient privileges for PR 8492 in repo dotnet/razor

davidwengier · 2023-04-25T07:02:27Z

/azp run

azure-pipelines · 2023-04-25T07:02:40Z

Azure Pipelines successfully started running 2 pipeline(s).

davidwengier · 2023-04-25T10:57:11Z

The unit test failure should be fixed by merging in main. ~~Looks like there is one real failure though~~ nvm, its a conflict from an arcade update.

NikolaMilosavljevic · 2023-04-25T17:01:50Z

The unit test failure should be fixed by merging in main. ~~Looks like there is one real failure though~~ nvm, its a conflict from an arcade update.

I'll resolve the merge conflict and any fallout issues, likely resulting from lack of coherency in razor dependencies - this PR is adding the coherency.

NikolaMilosavljevic · 2023-04-25T17:27:30Z

The failures seem related to some access or permission issues - we'll need to request a rerun a bit later.

NikolaMilosavljevic · 2023-04-25T21:42:33Z

The unit test failure should be fixed by merging in main. ~~Looks like there is one real failure though~~ nvm, its a conflict from an arcade update.

One of the tests timed out - is it possible to rerun that check?

Enable source-build pre-built detection

fdd11bd

NikolaMilosavljevic requested review from a team as code owners March 22, 2023 20:52

333fred reviewed Mar 22, 2023

View reviewed changes

NikolaMilosavljevic commented Mar 22, 2023

View reviewed changes

mmitche reviewed Mar 22, 2023

View reviewed changes

NikolaMilosavljevic added 2 commits March 22, 2023 21:17

Update comment

f765403

Update dependency and automatic version updates

049cc5d

mmitche reviewed Mar 22, 2023

View reviewed changes

jjonescz reviewed Mar 23, 2023

View reviewed changes

eng/SourceBuildPrebuiltBaseline.xml Outdated Show resolved Hide resolved

Update eng/SourceBuildPrebuiltBaseline.xml

a49bace

Co-authored-by: Jan Jones <[email protected]>

mmitche approved these changes Mar 23, 2023

View reviewed changes

Allow 2 roslyn versions while pinning 2 packages used in source-build

702da69

mmitche reviewed Mar 23, 2023

View reviewed changes

MichaelSimons reviewed Mar 28, 2023

View reviewed changes

This was referenced Mar 28, 2023

Add sbrp package for System.Text.Encoding.CodePages 6.0.0 dotnet/source-build-reference-packages#591

Merged

Remove net7.0 targeting #8531

Closed

Update comment in SourceBuildPrebuiltBaseline.xml

66c7617

MichaelSimons reviewed Mar 29, 2023

View reviewed changes

MichaelSimons approved these changes Mar 29, 2023

View reviewed changes

333fred reviewed Apr 11, 2023

View reviewed changes

NikolaMilosavljevic added 3 commits April 14, 2023 08:14

Merge branch 'main' into prebuilts

5d51c69

Add explicit package dependencies

647f22f

Address code-check issues

1f8ba5e

333fred approved these changes Apr 24, 2023

View reviewed changes

Merge branch 'main' into prebuilts

4e9c370

davidwengier approved these changes Apr 25, 2023

View reviewed changes

Update dependencies

f3e6e24

Update package versions

5ecabe1

NikolaMilosavljevic added 2 commits April 25, 2023 10:02

Merge branch 'main' into prebuilts

f898e50

Fix coherency versions

7ab376a

NikolaMilosavljevic closed this Apr 25, 2023

NikolaMilosavljevic reopened this Apr 25, 2023

davidwengier merged commit be0633b into dotnet:main Apr 25, 2023

allisonchou mentioned this pull request Apr 27, 2023

[Automated] PRs inserted in VS build main-33627.185 #8649

Closed

maryamariyan mentioned this pull request Apr 28, 2023

Upgrading roslyn bits causing version downgrades, needs further investigation #8652

Closed

NikolaMilosavljevic mentioned this pull request May 12, 2023

Enable prebuilt detection dotnet/fsharp#15209

Merged

	<MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessRazorPackageVersion>
	<MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisExternalAccessOmniSharpCSharpPackageVersion>
	<MicrosoftCodeAnalysisCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCommonPackageVersion>
	<MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
	<MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpEditorFeaturesPackageVersion>
	<MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpFeaturesPackageVersion>
	<MicrosoftCodeAnalysisCSharpPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpPackageVersion>
	<MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisCSharpWorkspacesPackageVersion>
	<MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesCommonPackageVersion>
	<MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisEditorFeaturesTextPackageVersion>
	<MicrosoftCodeAnalysisRemoteServiceHubPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisRemoteServiceHubPackageVersion>
	<MicrosoftCodeAnalysisVisualBasicWorkspacesPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisVisualBasicWorkspacesPackageVersion>
	<MicrosoftCodeAnalysisWorkspacesCommonPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisWorkspacesCommonPackageVersion>
	<MicrosoftCodeAnalysisWorkspacesMSBuildPackageVersion>$(RoslynPackageVersion)</MicrosoftCodeAnalysisWorkspacesMSBuildPackageVersion>

Enable source-build pre-built detection #8492

Enable source-build pre-built detection #8492

Uh oh!

Conversation

NikolaMilosavljevic commented Mar 22, 2023

Summary of the changes

Uh oh!

NikolaMilosavljevic commented Mar 22, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NikolaMilosavljevic Mar 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NikolaMilosavljevic Mar 23, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mmitche commented Mar 23, 2023

Uh oh!

333fred commented Mar 23, 2023

Uh oh!

mmitche commented Mar 23, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NikolaMilosavljevic Mar 22, 2023 •

edited

Loading

NikolaMilosavljevic Mar 23, 2023 •

edited

Loading

NikolaMilosavljevic Apr 10, 2023 •

edited

Loading