Document that package detection relies on project.assets.json from last restore

[Copilot]

Users reported packages defined in Directory.Build.props with conditional statements not appearing in output. The tool reads from project.assets.json generated by dotnet restore, but this wasn't documented.

Changes

• Added "Important Notes" section to README explaining package detection mechanism
• Clarified that only packages from the most recent restore are evaluated
• Documented that conditional package references require restoring with matching configuration
• Provided examples for analyzing multiple configurations:

# For Release configuration
dotnet restore -c Release
nuget-license -i MyProject.csproj -o JsonPretty -fo licenses-release.json

# For Debug configuration  
dotnet restore -c Debug
nuget-license -i MyProject.csproj -o JsonPretty -fo licenses-debug.json

The tool doesn't restore packages or evaluate MSBuild conditions—it reads the lock file from whatever restore last ran.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Not all packages in output</issue_title>
<issue_description>I have a project where I add some packages using a Directory.Build.props file in a directory, so all projects in that directory will automatically reference these packages. Such packages do not show up in the generated output.

In my case it can be two causes (I haven't had the time to check which is the actual cause):

• The packages are not found at alll, because the Directory.Build.props files are not scanned.
• The packages are not found, because they are added based on a certain condition.

For example, my Directory.Build.props contains the following lines:

    <ItemGroup Condition="('$(Configuration)' != 'Simulation') And ('$(Configuration)' != 'CompileSimulationModels')">
        <PackageReference Include="Pomelo.EntityFrameworkCore.MySql" />
    </ItemGroup>

and the Pomelo.EntityFrameworkCore.MySql package is not listed in the output.</issue_description>

<agent_instructions>Improve doecumentation to state that the packages evaluated will always be the ones that were used during the last package restore</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@sensslen @MarcelVersteeg thank you for your bug report. Are you able to create a minimal reproduction sample so that we can properly look into the issue? Feel free to dig into the code and figure out what is happening if you need a fix early. At this time I cannot promise any timeframe I'll be able to look into the issue. @sensslen @MarcelVersteeg can you check if https://github.com//pull/163 outputs anything? Currently nuget-license relies on the lock file generated by the nuget restore. So depending on the configuration you restore, I expect the license to be included or not... @sensslen @MarcelVersteeg nuget-license does not restore any package. It relies on you to do this before you run nuget-license. nuget-license will only attempt that you have not restored. @sensslen @MarcelVersteeg haver you been able to work around the issues? Do you have ideas on how to improve nuget-license to deal with these scenarios? @sensslen > I was not able to work around the issue. Since I have several different configurations in my splution, it takes a lot of cleaning and specific restoration of NuGet packages that might result in a correct license overview (not all packages are hard in all configurations). > > My take to overcome this is to be able to pass the configuration to the tool for which I want the license overview. The tool should not use the generated json, but instead parse the solution itself using the passed configuration and iterate the nuget packages in the projects directly. For this, you could use the Microsoft.Build NuGet package that provides an api to parse solutions and projects.

I see. Unfortunately I don't have that much time to spend on this currently. I recall it's all but easy to correctly identify the referenced packages because of transitive dependency resolution and because of version ranges. Feel free to look into ways to fix this issue. I bet the easiest solution would be to trigger a restore with the correct configuration just before reading the assets file...</comment_new>
<comment_new>@sensslen

At this moment I also don’t have time to look into it. I believe there are some packages that interact with NuGet itself (did not search for it right now, but I think I saw one once) that might help with the transitive references. At least there must be a way, as the .net toolkit also dies it :/

Exactly - that's why I opted not to re-invent the wheel and let .net determine what is used in which version - hence the usage of the lock file that is generated by a dotnet restore command. Maybe we can run dotnet restore with a specific configuration before validating....</comment_new>

• Fixes Not all packages in output #165

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud