-
Notifications
You must be signed in to change notification settings - Fork 347
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
Strange build error when calling "pack" target #4337
Comments
/cc @RussKie |
The errors are reported in the public CI pipeline but the errors don't break builds. The internal builds are actually failing because of these errors (e.g. https://dev.azure.com/dnceng/internal/_build/results?buildId=424371) |
Those are warnings that are getting elevated to errors in the build likely. https://docs.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu5128 The warnings are something that was added in 3.0.100, and ideally should be addressed. I'd recommend you analyze the warnings, I'd be happy to chat through any issues if necessary. fyi @zivkan |
@nkolev92 Can we keep the chat in this issue just so it's documented, in case other teams run into this? We have two csproj files that generated packages. They are both under https://github.com/dotnet/winforms/tree/master/pkg. I looked at the warnings, but I'm not sure what actions to take here. The lib and ref folders inside the packages have not changed, and the nuspec is created for us by the -pack target. The nuspec for one of the packages looks like this:
I assume the warnings are saying we need to have all the dll's that are in our package also in the dependencies section of the nuspec, but I'm not sure how to change the csproj to achieve that. Could use some assistance on this :) |
Do we understand the reason that these errors started showing up just now? |
Haven't looked into this yet (doing on-call stuff for the team week), but these warnings were added in 3.0. Earlier versions did not have these warnings. |
I see in https://github.com/dotnet/winforms/blob/master/pkg/Microsoft.Private.Winforms/Microsoft.Private.Winforms.csproj that most of the packaging there is custom. Related: NuGet/Home#8684 |
Sure, the package in the latest build can be found at https://dnceng.visualstudio.com/internal/_build/results?buildId=427115&view=results, in the PackageArtifacts build artifact. The structure looks like this: And the generated nuspec looks like this:
|
We've been building this package the same way for a while now, I assume we can safely suppress these warnings, but I wanted to be sure. |
Ideally you shouldn't need to. The warnings are usually added to help customers avoid some pitfalls. Given your package and nuspec, I wouldn't expect either warning to be raised. 5131 has this bug: NuGet/Home#8684. 5128 shouldn't ideally be raised. I'd suggest suppressing NU5131 until the bug is fixed. |
I got latest master from the winforms repo and ran .\build.cmd -pack and I see both 5131 and 5128. My output is below. Since this is causing our builds to fail, I think we need to suppress both for now until we figure out what the issue is?
|
Sorry, the 5128 warnings are on the other package we generate. The package contents are this: And the nuspec looks like this:
|
Ah, that makes a lot more sense. That one definitely not "legal" according to the rule. Shouldn't that package contain a template package type? See PackageTypes in https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets. The name is "Template". |
Thanks :) I took a look at the nuspec for AspNetCore.Blazor.Templates (since they don't generate theirs), and I do see the package types defined:
But I'm not sure how to map this to our packable csproj. I've tried adding |
Spoke with Nikolche offline, going to suppress these warnings to unblock our builds. Nuget team is going to look into these warnings in more detail. |
@JohnTortugo feel free to close this out |
Thanks @AdamYoblick - closing for @JohnTortugo as he's OOF. |
Reported by @AdamYoblick by e-mail:
The text was updated successfully, but these errors were encountered: