-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Update the dotnet SDK to 3.0.100-preview6-011681 (latest) #37340
Conversation
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.
Did you check that this had the fix we want? You should be able to see the feeds missing from Microsoft.NETCoreSdk.BundledVersions.props.
Yes that version contains the fix, I just checked. |
@ericstj can you please take a look at the failures? This seems to be your area of expertise:
|
Sigh another breaking Nuget change: they added members to a public interface... NuGet/NuGet.Client@32d984b#diff-80bb91cd6c8952511294d414a7e387b4 |
Looks like NuGet fixed the bug that caused me to implement that interface, so I can delete my implementation. NuGet/Home#4717 |
One of the few occasions when a breaking change makes you happy 😁 |
Nope, looks like that wasn't actually fixed. |
(Reading more, sounds like it won't be compatible due to that NuGet breaking change though. 😕 Edit: Oh, now I see dotnet/arcade#2664, maybe it is fine.) |
a535eec
to
68e86bc
Compare
@tmat seems like your change dotnet/arcade@c4bb6c1 is causing the build failures. Any idea how to fix? cc @ericstj |
@ViktorHofer The problem seems to be that CoreFX pkgproj files do not import common targets. The fix would be to import common targets or to at least import
|
@ericstj can you please take a look at this as pkgproj is also your area-of-expertise :) |
Pkgproj isn’t the only place that uses version and doesn’t import common.targets. @tmat please consider a general fix for this regression. You should be able to detect if a project is using common props/targets and decide to import the version targets as was done before. |
Sure, I can work around for now. But I think we should require all projects to import common targets. If they don't things like Directory.Build.props etc. won't work. |
68e86bc
to
f01f14a
Compare
f2c378a
to
086d321
Compare
Can you elaborate? I didn't see any mention here. I was actually waiting to merge dotnet/arcade#2672 so that I wouldn't slow down this PR. Copying the error from the all configurations leg:
This is the SDK breaking itself. It looks like it is failing because of Package ID on framework references. /cc @dsplaisted |
ApiCompat complained that Abstract members in the implementation aren't in the contract. I checked them and they were internal abstract ones. Does that maybe ring any bells? Unfortunately I didn't copy the log and force pushed over it. If you need the precise error message I recommend to run corefx locally against the most recent version of ApiCompat. |
OK, produced the ApiCompat errors:
|
The problem is evaluation order. Lines 17 to 25 in c390ce7
GenerateSource==true . I would recommend moving this item group to a props earlier in the project evaluation, such as putting it in Directory.Build.props.
|
Are you sure it is after? corefx/Directory.Build.targets Lines 125 to 138 in 10a014e
|
Oh, you're right, this isn't in the NuGet targets, its in sdk targets: corefx/Directory.Build.targets Line 18 in 10a014e
@natemcmaster's suggestion is a good one since it will fix our design time builds when folks modify resx files. We can move the Resources.targets above the SDK.targets import. We shouldn't move into props since we have properties that can be set by projects: Lines 6 to 9 in 10a014e
|
@Anipik it looks like your change around internal abstract members is flagging a few other types that have the same problem. |
The following types should get an internal constructor, today they have protected constructors:
This one needs a closer look, since it was just added within the last couple months.
@sywhang was it your intent that this new type be an internal only abstraction? If not then you should make this member protected. If you wanted this to be an an internal abstraction then you should make the constructor internal and not public. |
@ericstj I will throw up a pr to fix the first 2 atleast |
@Anipik would be great if you could also baseline the third one in your PR so that I don't have to touch that here. |
@ViktorHofer sure |
The package testing was failing because as the SDK probed up the path it found the nuspec we happened to copy here: corefx/pkg/test/testPackages.proj Lines 55 to 57 in 5518ab9
We should instead do this: <TestSupportFiles Include="$(PackagingTaskDir)..\..\**\*.*" Exclude="$(PackagingTaskDir)..\..\*.*">
<DestinationFolder>$(TestToolsDir)%(RecursiveDir)</DestinationFolder>
</TestSupportFiles> So that we don't unintentionally copy the root nupkg/nuspec from the package directory. |
cac646f
to
81c8d18
Compare
@@ -15,6 +15,7 @@ | |||
<StrongNameKeyId Condition="'$(IsTestProject)' == 'true'">$(TestStrongNameKeyId)</StrongNameKeyId> | |||
</PropertyGroup> | |||
|
|||
<Import Project="$(RepositoryEngineeringDir)Resources.targets" /> |
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.
@natemcmaster it is unfortunate that the Arcade change now relies on the importing order. Is there a way to fix this?
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.
In this particular case, it's tricky. To make Visual Studio editing of .resx files work well, we need to set metadata on an item during static evaluation. There is no perfect solution for import ordering when it comes to static evaluation.
Package testing was failing because the SDK probed up the directory structure for the locally copied CLI and found our package nupkg/nuspec.
81c8d18
to
0375997
Compare
@ericstj I can submit a fix to make the DiagnosticsCounter constructor to internal - should I push it directly to this branch, or submit a separate PR? |
A separate PR pls. |
@sywhang I can make the change in the pr where I am making the other changes |
Thanks @Anipik . |
Thanks all for helping! 👍 |
…0.100-preview6 Update the dotnet SDK to 3.0.100-preview6-011681 (latest) Commit migrated from dotnet/corefx@0757f65
As discussed here: dotnet/arcade#2654