Been having this issue again, it’s essentially making my application unusable, I publish it, some dependency doesn’t work, publish it again after somehow fixing it, another dependency doesn’t work, app just endlessly crashes for my users. This is getting frustrating.

I’ve just being bitten by the same issue. In my case, I was using the dotnet publish task in Azure DevOps with a path to the solution file .sln. I fixed by using the path to the main .csproj that references directly Newtonsoft.Json 13.0.0.1.

It helps if you can get from the main .csproj to any other .csproj by dependencies. In my case, the dependencies are pulled through a .dll using AutoFac.

@kickertw In fact I just published the specific project I was building, so instead of dotnet publish -o publish I did dotnet publish path/to/project -o publish. For me that was enough to avoid the dependency version clash. In my case it was Newtonsoft v.9 and v.10 that was being an issue.

I just had the same issue with 3.1.301 SDK on Linux. I upgraded a NuGet package and built the Release build using dotnet publish with PublishReadyToRun=true. The published application failed with a FileLoadException could not load assembly version for the updated NuGet package. Searching my project folders for the DLL, I found three copies in: bin\Release\netcoreapp3.1\linux-arm\publish - contains old version R2R obj\Release\netcoreapp3.1\linux-arm\R2R - contains old version R2R bin\Release\netcoreapp3.1\linux-arm - contains correct new version

If I delete the obj\Release folder and rebuild I get the correct version DLL and the application runs. So it appears that dotnet publish PublishReadyToRun=true does not correctly update the obj\Release\netcoreapp3.1\linux-arm\R2R folder when a NuGet package DLL version changes.

I hope this helps others who have this issue.

Any solution for this issue or workaround? Even i am facing the same!

Don’t use “-o” key

I have to use especially for my build pipeline, otherwise i have to a dirty workaround tircks to access the published folder. Though its not a difficult, but i just want to know if there will be a fix for this?

Another workaround i found/working for me in the same scenario is to make use of publish profiles to folder works! dotnet publish /p:PublishProfile=PublishPipelineProfile This is exporting all appropriate versions libs.

Details are on #15607

I did some digging into this since I had the same issue, and with some of the context here, I think I’ve figured out what’s going on. When you run dotnet publish on the solution level, what happens is that each project within the solution gets their own publish directory. When you redirect the output, there is now only a single output directory, so it just combines all the dll’s from all the publish directories into one, so there will only be one version available. If you check the project level publish directories, you will notice that the dll’s are different versions.

You can get around this by explicitly doing a dotnet publish on the specific project that you’re trying to publish rather than being ambiguous.

@blacksnake-rus Can you share the output of dotnet --info from a machine where this is failing?

I wasn’t able to repro this with a preview of the 3.1.100 SDK.

Can you try publishing without overriding the output folder and seeing if you still encounter the issue?

Thanks