MSB3268: The primary reference could not be resolved - Team City
...because it has an indirect dependency on the framework assembly "System.Data.Common, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.6.1". To resolve this problem, either remove the reference "something.dll" or retarget your application to a framework version which contains "System.Data.Common, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Well that is a mouthful and an error that occured on our Team City build server but NOT on our local machines. It is always a bit of a pig to try and find out what is different between the two but first to find out about this missing reference.
1) The error was raised from a .Net web site that was pulling in something.dll from another project in the same library. Unfortunately, this library referenced a few other solution projects so to track down the culprit, I had to find out which of the dependencies was the first to fail, since that was probably the culprit.
2) The dependency was something like Site -> A ->B ->C and C was copied OK but A and B were not so I decided that it was most likely that B was the problem.
3) Opening B from my local machine in ILSpy, I used the "Load Dependencies" feature to find these missing libraries (System.Data.Common and a few others) and lo and behold, we were referencing DnsClient 1.2 from NuGet which has a dependency on a net standard library System.Buffers >= 4.4.0 We had installed the DnsClient so it had automatically pulled System.Buffers 4.4.0 and it all built OK locally.
4) It turns out that System.Buffers is actually a netstandard library and version 4.4.0 doesn't directly support Net Framework 4.6.1. Of course you can have netstandard support but that involves upgrading the library (and all its descendents) to net 4.7.2 (recommended) and also to change the package management method from the net framework style to the net core style. A lot of work and redeployment we didn't want.
5) Looking at System.Buffers 4.5.0, we noticed that it actually mentioned Net framework 4.5 with no further dependencies, which I think is poor behaviour from MS since they have made a major change in a minor version.
6) Installing a dependent library can be tricky because I was concerned that if I just did an in-place upgrade of System.Buffers in nuget, it might not correctly reload the target framework as a reinstall would do but I couldn't reinstall it since DnsClient relied on it. What I did was uninstall both, install System.Buffers first and then install DnsClient. Not sure if I needed to do that but it worked.
Then push back up to the build server and it was all fine!
It is not obvious what was happening and I still don't know why Visual Studio was behaving itself whereas msbuild wasn't but Nuget publishers need to be much more careful about what versions they support and nuget should really refuse to install netstandard dependencies on .Net 4.6.1 rather than pretend its OK when it isn't.
I think another way is to add the netstandard nuget package to the library but that potentially brings in various additional things that we don't actually need.
Well that is a mouthful and an error that occured on our Team City build server but NOT on our local machines. It is always a bit of a pig to try and find out what is different between the two but first to find out about this missing reference.
1) The error was raised from a .Net web site that was pulling in something.dll from another project in the same library. Unfortunately, this library referenced a few other solution projects so to track down the culprit, I had to find out which of the dependencies was the first to fail, since that was probably the culprit.
2) The dependency was something like Site -> A ->B ->C and C was copied OK but A and B were not so I decided that it was most likely that B was the problem.
3) Opening B from my local machine in ILSpy, I used the "Load Dependencies" feature to find these missing libraries (System.Data.Common and a few others) and lo and behold, we were referencing DnsClient 1.2 from NuGet which has a dependency on a net standard library System.Buffers >= 4.4.0 We had installed the DnsClient so it had automatically pulled System.Buffers 4.4.0 and it all built OK locally.
4) It turns out that System.Buffers is actually a netstandard library and version 4.4.0 doesn't directly support Net Framework 4.6.1. Of course you can have netstandard support but that involves upgrading the library (and all its descendents) to net 4.7.2 (recommended) and also to change the package management method from the net framework style to the net core style. A lot of work and redeployment we didn't want.
5) Looking at System.Buffers 4.5.0, we noticed that it actually mentioned Net framework 4.5 with no further dependencies, which I think is poor behaviour from MS since they have made a major change in a minor version.
6) Installing a dependent library can be tricky because I was concerned that if I just did an in-place upgrade of System.Buffers in nuget, it might not correctly reload the target framework as a reinstall would do but I couldn't reinstall it since DnsClient relied on it. What I did was uninstall both, install System.Buffers first and then install DnsClient. Not sure if I needed to do that but it worked.
Then push back up to the build server and it was all fine!
It is not obvious what was happening and I still don't know why Visual Studio was behaving itself whereas msbuild wasn't but Nuget publishers need to be much more careful about what versions they support and nuget should really refuse to install netstandard dependencies on .Net 4.6.1 rather than pretend its OK when it isn't.
I think another way is to add the netstandard nuget package to the library but that potentially brings in various additional things that we don't actually need.