Open danmoseley opened 7 months ago
Just yesterday we merged a PR to update the SDK (#9282) and running locally I don't see the MSBuild issue, I suspect because dotnet/aspire is pinned to SDK 8.0.200 and until yesterday, the NuGet updater was on 8.0.100, but is now 8.0.202.
I'll keep this issue open because there are some errors in the log that I want to dig into a bit.
Installing SDKs on demand would be a long-term solution to this issue. See https://github.com/dependabot/dependabot-core/issues/9286
Looking at the current failures in dotnet/aspire I'm seeing repeated variations of this:
updater | Updating project [/home/dependabot/dependabot-updater/repo/src/Aspire.Hosting.Azure/Aspire.Hosting.Azure.csproj]
updater | Running for SDK-style project
updater | Package [Azure.ResourceManager.Authorization] Does not exist as a dependency in [/home/dependabot/dependabot-updater/repo/src/Aspire.Hosting.Azure/Aspire.Hosting.Azure.csproj].
This is obviously incorrect as that dependency is specified here and the package version is specified here and we should be able to navigate to that, but something is going weird.
Digging some more, the update can't be processed because we can't resolve the TFM value of $(NetCurrent)
because it's coming from the Arcade SDK and we don't currently navigate through SDK imports. I'll start working on the Ruby side of things to not report a .csproj
as relevant if we can't parse a TFM from it.
Any extra proactive logging you can sprinkle as you go along @brettfo might be good, just because the logs so often have not given either of us enough info to guess at the problems as each one popped up. Seems to me it's fine if these logs are quite verbose as there's no reason to look at them unless something broke,
I'm working on PR #9347 now that'll add a warning to the log if a TFM can't be found so we can dig in more. The warning looks like this:
Excluding project file '/path/to/project.csproj' due to unresolvable target framework
How well does it work on dotnet/aspire with your #9347 changes applied? Does it work, or looks like we get to next layer to peel off?
another example using latest dependabot (today)
updater | Unhandled exception: System.TypeInitializationException: The type initializer for 'NuGetUpdater.Core.MSBuildHelper' threw an exception.
updater | ---> System.InvalidOperationException: Failed to find all versions of .NET Core MSBuild. Call to hostfxr_resolve_sdk2. There may be more details in stderr.
this can be reproed by cloning https://github.com/danmoseley/performance/commit/c717365379c4f1da6cd1c745b965301bd894374a
Just putting it here in case it's helpful. (It might be good if ...due to unresolvable target framework
included the value it got, blank or not)
[edit] this may be because it's using 9.0
@danmoseley The MSBuild/SDK resolution was improved last week, are you still seeing this issue in the aspire repo? If not I'd like to close this issue so I can focus on the other ones.
Is there an existing issue for this?
Package ecosystem
nuget
Package manager version
No response
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
@brettfo this is the main repo we're having trouble getting working even after your changes/workarounds. Could you please just fork it and try running dependabot yourself on main?
https://github.com/dotnet/aspire
That seems like it will be much more efficient for everyone.
For example, as of your last change, I now have new errors like
I've spent a number of hours over the last 2-3 months trying to hackaround things but without being able to run dependabot locally or being familiar with its code it's not super useful and just gets me to another error.
Would that be possible?
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response