Best practices for preferring local .nupkg

[MattKotsenas]

Best practices for preferring local .nupkg

[jeffkl]

If I decide to go with the source mapping route, is that something you'd possibly accept upstream, or is it too orthogonal to the goals of this project?

I'd accept a pull request that adds package source mapping to the generated NuGet.config

[jeffkl]

I think the hardest part is going to be how to handle versioning. NuGet packages are considered immutable so any package with the same ID and version regardless of source is considered the same. For locally built packages, its a good practice to use build labels and have a version like 1.0.0-g848393 where the label is the commit SHA. That way, the version changes for every commit and you can always rebuild it if needed. For uncommited local changes, things get a little trickier of course. Are you looking to test commited changes or uncommited changes?

If you know the version of the package and you know its unique per test run, then you could generate the projects on-the-fly and run tests. But if the packages aren't versioned in a way to make that possible, you'll need to use a clean global packages folder to ensure that an existing package isn't used. And if the version collides with something on an official feed, then package source mapping is the only option I can think of. If it was me, I'd just make sure that locally built packages are uniquely versioned so they would never collide with packages on feeds.

[MattKotsenas]

Hi Jeff! I'm hoping to put together small set of tools / patterns that devs on my team can use to test packages. As a result, I expect them to be testing uncommitted changes, and I know some projects today don't tag packages with the SHA. I can make that a requirement, but aiming to make it as foolproof as possible. Also, I believe I should be handling the immutability of packages already by using a PackageRepository so that the package cache is different every time (let me know if I'm misunderstanding).

If I decide to go with the source mapping route, is that something you'd possibly accept upstream, or is it too orthogonal to the goals of this project?

In either case, thanks both for the project and your guidance!

[jeffkl]

Are you wanting to test the entire package itself or just the library inside of the package? I have other repos that I test the functionality of the assemblies themselves and don't really test the package. The original design for MSBuildProjectCreator to have the ability to create packages was to test build logic that requires packages. If you're looking to test packages end-to-end, I think you'll just need to come up with a way to version the packages uniquely per test run and know the version so you can generate a project that references that version.

[MattKotsenas]

Good question! I'm generally not trying to test the lib/ stuff itself, nor an MSBuild task directly, as those already have decent unit test mechanisms already.

Thus far what I've been trying to test (and found value in testing) is the .props / .targets of a package as well as the dependencies of the package.

Here's a couple of tests I've found valuable in the past:

• Testing the path manipulation logic in a .props file to load the correct assembly for a UsingTask.
• Incremental build / clean bugs in Targets
• Missing Private dependencies for an MSBuild task
• Linking to the wrong version of Microsoft.Build.* packages for older SDKs

These are all more integration tests around dependency versions, package layout, etc. Thus my approach so far has been to build an actual package and restore it.

I think what I really want is to wire up the output of a ProjectReference in the test project as the input to a PackageFeed in this library, but I'm not sure if that's possible.

Let me know if this makes sense or not. I'll also try to find a couple of examples I can share of how I'm using things currently.

[jeffkl]

I originally created this library to make it easier to test MSBuildSdks. One example is that I created a custom template for Traversal which just imports the locally built Sdk.props/Sdk.targets:

https://github.com/microsoft/MSBuildSdks/blob/main/src/Traversal.UnitTests/CustomProjectCreatorTemplates.cs#L130

Then it can test if properties are set, ProjectReferences work, and targets perform differently based on configurations. I think it would better if your unit tests for the build logic run like this. The MSBuildSdks tests just have to ensure that the props/targets are in their output folders: https://github.com/microsoft/MSBuildSdks/blob/main/src/Traversal.UnitTests/Microsoft.Build.Traversal.UnitTests.csproj#L20

Basically the tests work as if they installed the package.

[MattKotsenas]

Thanks for the context! One thing about the sample you gave is that you're duplicating here logic from the package you're trying to test. In this particular case that logic is very trivial, but if you use a slightly more complicated example like this Yarn package: https://github.com/natemcmaster/Yarn.MSBuild/blob/27df58f0a6ccffa9b2c92123f7608c07466dbce9/src/Yarn.MSBuild/Yarn.MSBuild.nuspec#L25C1-L33C40

The unit test would need to:

1. Duplicate the layout of the package in the output folder, which duplicates the logic from the .nuspec or .csproj file
2. Duplicate NuGet's knowledge of importing the correct build/, buildTransitive/, etc. files from that layout

and a change to the package structure requires a corresponding change to the tests.

Do you have any examples of working with an SDK or props / targets that also uses an MSBuild task?

Thanks again for your help!

[MattKotsenas]

Resolving as fixed. Will re-open if I run into any additional issues!