I faced an interesting challenge while upgrading to the latest dotnet CLI. We've built an application a while ago in vNext beta4. During the course of the application we migrated up to beta8 and now it was time to upgrade to the latest .NET Framework and to use the latest CLI. Enough of background.
Once all the projects were migrated and running we started seeing some weird issues being raised in the build server (TeamCity) even though it was running fine locally. It took me a while to find out what the issue was.
Any time I ran the command
dotnet build locally it would just work while running the same in the build server was failing. So I started digging a bit deeper and got to the
dotnet restore command. Anytime I ran it locally it would come back with the message Nothing to do. None of the projects specified contain packages to restore. when obviously there was still something to be restored because the original error message was about some dependency not being loaded.
Why was the command running fine locally then? Since I'm running Visual Studio on my dev machine, it handles all the dependencies and downloads them for me, and when checking my
csproj file I'd see the reference to the DLLs
<Reference Include="EntityFramework"> <HintPath>..\..\packages\EntityFramework.6.1.3\lib\net45\EntityFramework.dll</HintPath> <Private>True</Private> </Reference>
So what I tried next was renaming my
packages folder and trying to run
dotnet restore and
dotnet build again and voilà. I could replicate the exact same issue I was getting in my build server.
After a couple of hours and a lot more digging I landed on JetBrains' GitHub stating:
.NET CLI decided that dotnet restore should support restore only for new csproj files, so packages.config will be ignored by design
Where in my case I'm using the dotnet CLI with an old
And as a workaround, I had to add a new step to my build process to run
nuget restore and not rely on
dotnet restore anymore at least for this project.
Hope it helps.