Remove EFCore.Analyzers.nuspec and use MSBuild packaging

[Copilot]

Plan: Remove EFCore.Analyzers.nuspec and use MSBuild packaging

• Understand current packaging setup with nuspec file
• Update EFCore.Analyzers.csproj to package analyzers using MSBuild properties
  • Configure proper MSBuild items to place analyzer DLL in analyzers/dotnet/cs/ path
  • Configure proper MSBuild items to place PDB files in analyzers/dotnet/cs/ path
  • Configure PackageReadme to include PACKAGE.md in docs folder with forward slashes
  • Set up dependencies correctly (netstandard2.0 with no dependencies via SuppressDependenciesWhenPacking)
  • Ensure PackageIcon is properly included (handled by Arcade SDK)
  • Add OverridePackageReadme target to set PackageReadmeFile property
• Remove the nuspec file reference from csproj
• Delete the EFCore.Analyzers.nuspec file
• Build the package and verify contents match expected structure
• Run tests to ensure no regressions (90 tests passed)
• Address code review feedback
  • Uncomment DevelopmentDependency and SuppressDependenciesWhenPacking properties
  • Add PackageReadmeFile property via OverridePackageReadme target

Summary

Successfully eliminated the EFCore.Analyzers.nuspec file and configured MSBuild packaging. The generated package now has:

• Forward slashes in readme path (docs/PACKAGE.md instead of docs\PACKAGE.md)
• DevelopmentDependency set to true
• No dependencies listed (SuppressDependenciesWhenPacking)
• Analyzer DLL and PDB in correct location
• All tests passing

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[roji]

Verified that the nupkg produced by dotnet pack contains the same nuspec and the same files under analyzers and docs.

[Copilot]

Pull request overview

This PR addresses an issue where BaGet server rejected the Microsoft.EntityFrameworkCore.Analyzers package due to backslash path separators in the nuspec file. The solution eliminates the hand-authored nuspec file and migrates to MSBuild-based packaging, which uses forward slashes consistently.

Key Changes:

• Removed the manually authored EFCore.Analyzers.nuspec file
• Migrated all packaging configuration to EFCore.Analyzers.csproj using MSBuild properties and <None> items
• Changed path separators from backslashes to forward slashes for package paths

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/EFCore.Analyzers/EFCore.Analyzers.nuspec	Removed hand-authored nuspec file that contained backslash path separators causing BaGet rejection
src/EFCore.Analyzers/EFCore.Analyzers.csproj	Added MSBuild packaging configuration including analyzer DLL/PDB packaging and readme file, with forward slash paths; includes commented-out analyzer-specific properties

[AndriySvyryd]

The .pdb shouldn't be included in the main package, only in the symbols one

[roji]

Thanks, good catch.

Getting around this proved remarkably difficult: when copying files into the package manually, it doesn't seem possible to make a distinction between the main nupkg and the symbol nupkg. Take a look at the slightly hacky thing I came up with; if you think that's bad we can always keep the current nuspec-based way and just move the README.md to the standard base location (no more slashes needed).

BTW I'm a bit unsure what a PDB/symbol package is even good for, with analyzers. As this isn't a build dependency nobody is going to debug into it from an EF application (not sure it's possible to debug into an analyzer in general...). It feels like it may be fine to simply not have a symbol package/omit the PDB; it also feels maybe OK to just include the PDB in the main package too (it's just 16k).

Finally, I'm noticing that in general, we're still building the old/legacy symbol package format (symbols.nupkg) rather than the new snupkg. I suspect maybe with snupkg this is all simple and just works - I'm not sure if there's a plan to switch to the new format at some point.

[AndriySvyryd]

Getting around this proved remarkably difficult: when copying files into the package manually, it doesn't seem possible to make a distinction between the main nupkg and the symbol nupkg. Take a look at the slightly hacky thing I came up with; if you think that's bad we can always keep the current nuspec-based way and just move the README.md to the standard base location (no more slashes needed).

Looks good enough

BTW I'm a bit unsure what a PDB/symbol package is even good for, with analyzers. As this isn't a build dependency nobody is going to debug into it from an EF application (not sure it's possible to debug into an analyzer in general...). It feels like it may be fine to simply not have a symbol package/omit the PDB; it also feels maybe OK to just include the PDB in the main package too (it's just 16k).

Including symbols is a requirement even if their usage is implausible, I am not sure about where we stand on shipping them in the main package.

Finally, I'm noticing that in general, we're still building the old/legacy symbol package format (symbols.nupkg) rather than the new snupkg. I suspect maybe with snupkg this is all simple and just works - I'm not sure if there's a plan to switch to the new format at some point.

See dotnet/arcade#1959