Home: NU5012, nuget.exe pack cannot find built assemblies

[ghost]

What is always stupid exception?

Error NU5012: Unable to find '**.dll'. Make sure the project has been built.

I already built Release dll and it doesn't see my library. I feel mad because nuget steals my time much.
Please stop forcing my time!

<?xml version="1.0"?>
<package  xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>MonoGame.Framework.Gtk3</id>
    <version>0.1</version>
    <title>MonoGame Framework Control for Gtk Sharp 3</title>
    <authors>Jens Eckervogt</authors>
    <owners>Jens Eckervogt</owners>
    <licenseUrl>https://github.com/sourceskyboxer/MonoGame.Framework.Gtk3</licenseUrl>
    <projectUrl>https://github.com/sourceskyboxer/MonoGame.Framework.Gtk3</projectUrl>
    <iconUrl>https://i.imgur.com/nC1iu3N.png</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>MonoGame's Editor Environment for Gtk Sharp 3.22x.</description>
    <releaseNotes>Initial release!</releaseNotes>
    <copyright>2018, SourceSkyBoxer from Germany</copyright>
    <tags>MonoGame, Gtk-Sharp</tags>
    <dependencies>
      <dependency id="gtk-sharp-3" version="[3.22.6.4]" />
    </dependencies>
    <summary></summary>
  </metadata>
  <files>
    <file src="bin\Release\MonoGame.Framework.Gtk3.dll" target="lib" />
  </files>
</package>

And I want type my command:

1. nuget.exe config -Set repositoryPath=C:\Users\SSB\Downloads\MonoGame.Framework.Gtk-master\MonoGame.Framework.Gtk3-master\MonoGame.Framework.Gtk3
2. nuget.exe pack -IncludeReferencedProjects -properties Configuration=Release MonoGame.Framework.Gtk3.csproj
3. Throws error: Error NU5012: Unable to find 'MonoGame.Framework.Gtk3.dll'. Make sure the project has been built

But hello I already built in release version:
here my sources

next bin directory

1. Release directory here it is proof "MonoGame.Framework.Gtk3.dll"
   

Why is nuget always lying to me if I have already built existing dlls?

I already downloaded latest version of nuget.exe

It seems like faking and lying me! Grr I feel mad because nuget steals time.

Please tell me! I am new for nuget I already read step to step. but for me doesn't work

[StingyJack]

Try setting Platform=Any CPU (or which ever platform you use) in the -properties list of your nuget.exe command.

[rrelyea]

@mishra14 - where is NU5012 coming from. is that in your latest batch of error investigations?

[ghost]

Hello @StingyJack and @rrelyea It is very latest version of nuget and It always like common not found or warning. I already tried tried I want pack into nupkg than it happens always if I make test from nuget server and I download nuget server from my nuget package than it shows nothing where is assembly.. How do I fix? Thanks!

[StingyJack]

@sourceskyboxer - When you build a solution in VS or MSBuild, you usually have to specify both the Target Platform (x86, x64, Any CPU, Mixed Platforms etc) and the Build Configuration (Release, Debug, etc.). Nuget.exe also requires this same information so that it can locate the correct build output path.

Your command line

nuget.exe pack -IncludeReferencedProjects -properties Configuration=Release MonoGame.Framework.Gtk3.csproj

.. doesnt specify the Platform (more below) and doesnt have the properties at the end of the arg list. Also If you went to the trouble of making a nuspec and setting the <files> , you should just point nuget.exe at the nuspec and not the csproj file (also more below).

Your command should probably be something like this...

nuget.exe pack MonoGame.Framework.Gtk3.nuspec -properties Configuration=Release;Platform='AnyCPU' 

Here is the CLI argument ref

---

RE: Platform
If you look at your csproj file, it will look something like this (abbreviated)

<PropertyGroup>
    <!-- These are the defaults, but nuget doesn't always seem to read these correctly -->
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{8C8209BD-3F55-4EF0-9006-8DD4DC344DC9}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <OutputPath>bin\Debug\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <OutputPath>bin\Release\</OutputPath>
  </PropertyGroup>

Note the property group condition is looking for both Configuration and Platform. If you don't specify both values, nuget may not be able to determine what output path to use.

---

RE: Nuspec
The docs are/were totally unclear about when to use a proj file and when to use a nuspec and the ramifications of choosing each. I was very frustrated with this inconsistent behavior between the two for _months_ until I just stopped trying to use the proj file and went nuspec only.

If you want to specify the <files> that are included in the package and have easier control over most aspects of the nupkg generation, then run nuget pack against the nuspec. This means you have to maintain the nuspec a bit more, as things like IncludeReferenedProjects are kind of pointless to use, but in my opinion* its actually less work than letting nuget.exe make even a few wrong decisions and having to troubleshoot them.

If you want to try the "easy" route, don't specify <files> in the nuspec as it will just create warnings, and use the command

nuget.exe pack MonoGame.Framework.Gtk3.csproj -IncludeReferencedProjects -properties Configuration=Release;Platform='AnyCPU' 

• _This opinion is based on authoring about 100 private packages over the last year or two, and helping others that I work with learn how to make them_

[nkolev92]

Thanks for the write-up @StingyJack

Basically run pack with the same argument that you build with.

@sourceskyboxer

Does @StingyJack's explanation address your problems? :)

[ghost]

Thanks for replying! I am sorry I am very busy to develop my C# applications. My god I am always busy. I am sorry for late answer! I am here now. Yes @StingyJack thanks I will care your solution.

Thanks!

[nkolev92]

@ghost

Did the above suggestion help solve your problem?
Are you still facing any issues?

[nkolev92]

Closing this as stale, since the customer has not responded.

Please open a new issue if you are still having problems.

[tg73]

I've worked quite extensively with nuget pack. Perhaps I'm mistaken, but there appears to be a gap in the capabilities of pack-from-project: the ability to pack from a project in the context of a particular solution configuration.

Even in the comments in this thread, there seems to be a conflation of solution configuration and project configuration and platform. A solution configuration specifies, independently for each project, the configuration and platform for each project. It is quite possible to have a mixture of platforms selected for different projects in a given solution configuration. I work with several solutions with solution configurations that specify that some projects should build as AnyCPU, and some as x86. When you invoke msbuild.exe on a solution (a .sln file, not a .csproj, for example), when you specify /p:Configuration=Release, you are specifying the name of a solution configuration, not a project configuration.

When building a solution, msbuild generates a metaproject which defines, among other things, an XML property called CurrentSolutionConfigurationContents. The OOTB AssignProjectConfiguration target in Microsoft.Common.CurrentVersion.targets uses this property to help ensure that each project is built with the project configuration and platform specified in the solution configuration.

From my testing, it would appear that you _can_ get nuget pack to work with heterogeneous project configurations and/or platforms, but it's not easy. In outline, if you are invoking nuget pack from a custom build target as part of your build, when building as a solution, you can pass the global properties that are generated by the solution metaproject through to nuget pack, and you'll get solution-like build behaviour. Ideally, nuget pack would support this scenario more natively, for example by accepting in addition to the project file argument, a solution file argument.

The other frequent gotcha where nuget complains about not being able to find files is with imperfect paths - such as obj\\debug - msbuild copes perfectly well with the double slash, but nuget does not. This is covered by other issues.

[StingyJack]

Even in the comments in this thread, there seems to be a conflation of solution configuration and project configuration

@tg73 - the OP's problem was _omission_ of the configuration parameter value. Csproj based packing and nuspec based packing that uses $configuration$ needs this value to pack correctly. Perhaps that is the gap you mean?

[StingyJack]

It is quite possible to have a mixture of platforms selected for different projects in a given solution configuration

This is a real pain to deal with, especially when VS decides to add a configuration to 150 projects in a solution without asking.

[jsobell]

Just as a follow-on to this, try adding -Build to your nuget command when you get this error and it may display the reason your packaging is failing. This tells nuget to try and build the project based on _it's_ interpretation of paths and dependencies, rather than the msbuild ones

[miniGweek]

Try setting Platform=Any CPU (or which ever platform you use) in the -properties list of your nuget.exe command.

This is GOLDEN !!
just an edit :
the command should look like
nuget.exe pack D:\a\1\s\yourproject.csproj -NonInteractive -OutputDirectory D:\a\1\s\output\ -Properties "Configuration=release;Platform=AnyCPU" -version 1.0.22 -Verbosity Detailed

[StingyJack]

@nkolev92 - QQ related to this - why does the docs page for the pack cli list many of these args as optional? Pack doesnt seem to work for any scenario I've ever given it without having the Config, Platform, and OutputDir

[nkolev92]

@StingyJack

I don't really have concrete context on that unfortunately.

In general though it's probably worth calling out the pack needs to be run with the same props as build.

[VerdonTrigance]

Try setting Platform=Any CPU (or which ever platform you use) in the -properties list of your nuget.exe command.

Hi. I have tried this as you told, but it didn't helped:

C:\hostedtoolcache\windows\NuGet\5.5.1\x64\nuget.exe pack d:\a\1\s\CommonUtilities\CommonUtilities\CommonUtilities.csproj -NonInteractive -OutputDirectory d:\a\1\a\NuGet -Properties "Configuration=Release;Platform='Any CPU'" -version 2.4.2433.20200506 -Verbosity Detailed
Error NU5012: Unable to find 'CommonUtilities.dll'. Make sure the project has been built.
NuGet Version: 5.5.1.6542
NuGet.Packaging.Core.PackagingException: Unable to find 'CommonUtilities.dll'. Make sure the project has been built.

[StingyJack]

@VerdonTrigance this is because a solution builds with "Platform=Any CPU", but a project builds with "Platform=AnyCPU". Remove the space in your platform value and it should work.

[VerdonTrigance]

@VerdonTrigance this is because a solution builds with "Platform=Any CPU", but a project builds with "Platform=AnyCPU". Remove the space in your platform value and it should work.

Nope, my project also 'Any CPU'

##[debug] MSBuildArguments: '/p:IsPackaging=true /p:platform="Any CPU" /p:configuration="Release" /p:VisualStudioVersion="16.0" /p:_MSDeployUserAgent="VSTS_2aead77d-3393-49cc-a0f9-3d96137a68e6_build_63_0"'

[StingyJack]

@VerdonTrigance if you did try changing it and it actually doesn't work, verify what your csproj has for build configurations.

[VerdonTrigance]

@VerdonTrigance if you did try changing it and it actually doesn't work, verify what your csproj has for build configurations.

I have checked .csproj file and fond 'AnyCPU' in there though the configuration manager UI was showing 'Any CPU'. Ok, forget trash GUI. I changed it like below:

    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Debug|Any CPU.Deploy.0 = Debug|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Release|Any CPU.Build.0 = Release|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Release|Any CPU.Deploy.0 = Release|Any CPU
    EndGlobalSection

<PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">Any CPU</Platform>
    <ProjectGuid>{5E9F2F91-8887-4700-A402-683619FA5F31}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>MyComp.CommonUtilities</RootNamespace>
    <AssemblyName>MyComp.CommonUtilities</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <TargetOfficeVersion>15.0</TargetOfficeVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>{C1CDDADD-2546-481F-9697-4EA41081F2FC};{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
    <SandboxedSolution>False</SandboxedSolution>
    <TargetFrameworkProfile />
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|Any CPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <UseVSHostingProcess>false</UseVSHostingProcess>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Any CPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <UseVSHostingProcess>false</UseVSHostingProcess>
  </PropertyGroup>

And still get strange error! Sigh

##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(777,5): Error : The OutputPath property is not set for project 'MyComp.CommonUtilities.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

Why there is 'AnyCPU' after all? I attached log from VSBuild task. There is no mention to 'AnyCPU' at all.
vsbuild_tmp.txt

PS: and even more, if I change everything back to AnyCPU I still get:

##[error]The nuget command failed with exit code(1) and error(Error NU5012: Unable to find 'MyComp.CommonUtilities.dll'. Make sure the project has been built.

[StingyJack]

The GUI is correct. When building a solution, use "Any CPU", when building a project use "AnyCPU". It's always a rude surprise when you first find this.

The OutputPath property is not set for project

This means that the configuration and platform argument set that is being given to msbuild or the pack command is not one that can be located in the csproj.

Take a moment to make sure you are using the correct variants of the platform for the things you are working with. Compare your csproj to a new csproj if you need to.

[VerdonTrigance]

The GUI is correct. When building a solution, use "Any CPU", when building a project use "AnyCPU". It's always a rude surprise when you first find this.

The OutputPath property is not set for project

This means that the configuration and platform argument set that is being given to msbuild or the pack command is not one that can be located in the csproj.

Take a moment to make sure you are using the correct variants of the platform for the things you are working with. Compare your csproj to a new csproj if you need to.

I fond that VS always change .sln file itself to "Any CPU" in it.

Anyway, why this error appears if I pass "Any CPU" everywhere?

##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(777,5): Error : The OutputPath property is not set for project 'MyComp.CommonUtilities.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

And something more. I can't (and don't want to) control configuration parameters for building solution and packaging nuget separately. If I pass "Any CPU" I expect from VSBuild task to build it and pack it from NuGet task. I'm not insterested in all of these inside tricks that they do.
This means I don't have to build anything again for NuGet pack task (doesn't matter if I pass "Any CPU" or "AnyCPU" if solution build successfully with it).

UPD: heh! Even with

##[debug]buildProperties=Configuration=Release;Platform='AnyCPU'

with NuGet Pack task I still get error NU5012 - so nothing changes. Any ideas?

[StingyJack]

Anyway, why this error appears if I pass "Any CPU" everywhere?

Because csproj and other proj files do not understand "Any CPU". This is part of a csproj from a new class library project, and I have added comments before each section to help convey the idea.

<!-- This is the default property group. If you invoke the build for the project without specifying any configuration or platform to MSBuild, the configuration and platform used here will be what is used to build the project.  -->
<!--  For this project, the default configuration is "Debug" and the default platform is "AnyCPU"-->
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>8a3c29be-45d6-4622-8620-6e1b3fcc0148</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>ClassLibrary1</RootNamespace>
    <AssemblyName>ClassLibrary1</AssemblyName>
    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
  </PropertyGroup>
<!--  This is the project build settings to use when the configuration "Debug" and platform "AnyCPU" is directed to be used. -->
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
<!-- Note the output path here-->
    <OutputPath>bin\Debug\</OutputPath>
<!-- snip -->
  </PropertyGroup>
<!--  This is the project build settings to use when the configuration "Debug" and platform "AnyCPU" is directed to be used. -->
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
<!-- Note the output path here-->
    <OutputPath>bin\Release\</OutputPath>
<!-- snip -->
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System"/>
<!-- snip -->
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Class1.cs" />
<!-- snip -->
  </ItemGroup>

You are getting the error The OutputPath property is not set for project 'MyComp.CommonUtilities.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='AnyCPU' because you changed your csproj file to have "Any CPU" in the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... elements. This means that it cant locate a PropertyGroup Condition to match what you want, so it is telling you it cant find a required value (output path). Put it back to AnyCPU in your proj file and that error will go away.

And something more. I can't (and don't want to) control configuration parameters for building solution and packaging nuget separately. If I pass "Any CPU" I expect from VSBuild task to build it and pack it from NuGet task. I'm not insterested in all of these inside tricks that they do.
This means I don't have to build anything again for NuGet pack task (doesn't matter if I pass "Any CPU" or "AnyCPU" if solution build successfully with it). .... Any ideas?

Yes, I have one that will solve your problem; use a Nuspec file instead of the csproj and target that with the nuget pack task. Run nuget spec for your proj file and it will generate the file from template, and all you need to do usually is fill out a few properties and then specify the files you want to include and avoid letting the project system or nuget guess what the files are (it gets it wrong too often), or require any kind of msbuild. Packing a csproj always seems to be problematic. Here is an example for a simple service interfaces project that has a dependency on another private package.

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>MyCo.SomeService.Interface</id>
    <version>$version$</version>
    <title>MyCo.SomeService.Interface</title>
    <authors>MyCo</authors>
    <owners>MyCo</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>The services contracts for Some Service</description>
    <copyright>Copyright 2020</copyright>
    <tags>SomeService</tags>
    <dependencies>
      <group targetFramework="net461">
        <dependency id="MyCo.CompositeResults" version="1.0.0.3" />
      </group>
    </dependencies>
  </metadata>
  <files>
    <file src="bin\Release\MyCo.SomeService.Interface.*" target="lib\net461" />
  </files>
</package>

Side note: I am using a wildcard to make sure the PDB and XML files are included in the package (its handy) and the version is not named in source control anywhere and is using $version$. This is because I apply the currently executing build number to the package as well as all the assemblies being built at the beginning of a build.

[VerdonTrigance]

You are getting the error The OutputPath property is not set for project 'MyComp.CommonUtilities.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Release' Platform='AnyCPU' because you changed your csproj file to have "Any CPU" in the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' ... elements. This means that it cant locate a PropertyGroup Condition to match what you want, so it is telling you it cant find a required value (output path). Put it back to AnyCPU in your proj file and that error will go away.

Yes, I did as I told in previous Update:

##[debug]buildProperties=Configuration=Release;Platform='AnyCPU'

with NuGet Pack task I still get error NU5012 - so nothing changes. Any ideas?

Here is my csproj;

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{5E9F2F91-8887-4700-A402-683619FA5F31}</ProjectGuid>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>MyComp.CommonUtilities</RootNamespace>
    <AssemblyName>MyComp.CommonUtilities</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <TargetOfficeVersion>15.0</TargetOfficeVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>{C1CDDADD-2546-481F-9697-4EA41081F2FC};{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
    <SandboxedSolution>False</SandboxedSolution>
    <TargetFrameworkProfile />
    <ActiveDeploymentConfiguration>Default</ActiveDeploymentConfiguration>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <UseVSHostingProcess>false</UseVSHostingProcess>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <UseVSHostingProcess>false</UseVSHostingProcess>
  </PropertyGroup>
...  
</Project>

And sln is

GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Debug|Any CPU.Build.0 = Debug|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Release|Any CPU.ActiveCfg = Release|Any CPU
        {5E9F2F91-8887-4700-A402-683619FA5F31}.Release|Any CPU.Build.0 = Release|Any CPU
    EndGlobalSection

And build and NuGet tasks are

- task: VSBuild@1
      inputs:
        msbuildArgs: '/p:IsPackaging=true'
        clean: true
        solution: '$(Build.Repository.Name)\**\*.sln'
        platform: ${{ variables.platform }}
        configuration: ${{ variables.configuration }}

- task: NuGetCommand@2
      displayName: 'NuGet pack'
      condition: ne('${{ parameters.publish_nuget }}', '')
      inputs:
        command: pack
        buildProperties: Configuration=$(configuration);Platform='AnyCPU'
        packagesToPack: '${{ parameters.publish_nuget }}'
        packDestination: '$(Build.ArtifactStagingDirectory)\NuGet'
        versioningScheme: byBuildNumber

As you can see I pass Platform='AnyCPU' to NuGet pack where variables.platform is 'Any CPU' for building solution.
As a result I still get error

NuGet.Packaging.Core.PackagingException: Unable to find 'MyComp.CommonUtilities.dll'. Make sure the project has been built.

PS: just for mention. Previously on classic build (not yaml) on windows-2012 agent with NuGet 4.4.1 I didn't get such annoying error. Everything was fine. I don't understand the reason why everything crashed with NuGet 5+, but it definitely pissed me off.

[StingyJack]

@VerdonTrigance - I also have not (and probably will not) moved off of nuget 4.9 for any of the 50+ build pipelines I am responsible for. But more importantly to the problem you are having - I won't use a csproj as a pack target, because it gets so many things wrong (and it doesn't report that it's not able to do as instructed). This is a lesson learned after authoring hundreds of packages and being hit with odd bugs like this. It's also one that I have constantly have had to teach team members who fall into the "pack csproj trap" and have a package with missing or incorrect dependencies, wrong files, missing frameworks, etc. So, use a nuspec, and the problem should be resolved.

[VerdonTrigance]

@VerdonTrigance - I also have not (and probably will not) moved off of nuget 4.9 for any of the 50+ build pipelines I am responsible for. But more importantly to the problem you are having - I won't use a csproj as a pack target, because it gets so many things wrong (and it doesn't report that it's not able to do as instructed). This is a lesson learned after authoring hundreds of packages and being hit with odd bugs like this. It's also one that I have constantly have had to teach team members who fall into the "pack csproj trap" and have a package with missing or incorrect dependencies, wrong files, missing frameworks, etc. So, use a nuspec, and the problem should be resolved.

Finally I has been forced to move to .nuspec. All these damn bugs and missing assemblies pissed me off. It's not so comfortable as .csproj might be, but it (.csproj) doesn't.
I spent quite amount of time to understand how to use and pass $tokens$ (it has to be a string in quotas passed by -Properties), but everything else was simple.
Thank you for helping and...(redacted my management-please stay kind)

[StingyJack]

.(redacted my management-please stay kind)

@rrelyea - I suggest trying a format that wont stylistically blend into the users writing style so neatly.

[EDIT: Redacted by repo owner/maintainer - please stay kind]

I had to scratch my head for a bit trying to figure out what Verdon was saying and then realized he hadn't actually said it. Thank you for taking the high road not defacing then outright destroying the post as one of your colleagues has done to me for something I wouldnt even have considered offensive (pointing out some of their claims were factually incorrect)..