CLI attempts NuGet Restore instead of using provided DLL path

Background

I have not published my tooling project to NuGet yet. I plan to today, but I have a curious message, error, or warning, that is happening at the moment.

I uniquely renamed my project output such that it no longer conflicts with existing NuGet packages. I am finding this kind of error during the build. I think that the local path is being used, but the error in the meantime is curious. I’m not sure there is anything else I can do with that from my end, when the build resolves, the asset is there, so to speak.

Error / NU1101 / Unable to find package dotnet-mytool. No packages exist with this id in source(s): ... / MyTool.Integration.Tests / path\to\MyTool.Integration.Tests\MyTool.Integration.Tests.csproj

That being said on the one hand, I’m not sure my targets do not need a bit of fine tuning. There is one in particular depending on some curious Microsoft Build targets, which are triggered at odd times when the asset might not be there, i.e. preparatory phases when the build outputs might not otherwise be there, for instance.

So, really, I’m just curious, if we provide a full path to the DLL assets, isn’t that sufficient to preclude this sort of condition? The default position, then, would be to ask for a NuGet Restore, for example.

Environment data

Attached.

dotnet-info.txt

[mwpowellhtx]

@peterhuene May have just identified an actual typo in my dependencies.

[peterhuene]

Try using dotnet exec <path_to_dll> .... This command will only execute the target assembly and will not invoke the .NET Core SDK at all (and thus the fallback logic in the SDK). If the assembly is not found, the command will immediately fail.