DLL reference issue.

Question

I have an application that connects to SQL Server 2019 and handles merge replication for my main application. The properties in file explorer for the SQL Server 2019 ConnectionInfo.dll and other dll's says the file is version 15.0.0.0 however when I select the file in my references on my project in my application the reference says the version is 15.100.0.0 when I build my application and run the release I get errors saying the system can't find the 15.100.0.0 files. I don't get these errors when running in debug mode. Is anyone else having this issue? I have other applications for SQL Server2005-2017 that don't have this issue because the file properties and the references match. I have deleted the references and re-added them with the same result. What am I missing?

Answer 1

This is the tricky thing about .NET, there are multiple versions. A file version is used by installers to determine which file is "newer" when installing stuff. So v2.1 would be newer than v2.0. .NET doesn't care about file versions because assemblies (the deployment unit of .NET) don't even need files. Instead you have the assembly version. This is not something that Windows tracks but is instead part of the assembly metadata.

When referencing a .NET assembly the assembly version is used at runtime. If your code compiles against v1.2.3 of an assembly, and the assembly is strongly named, then at runtime it requires v1.2.3 (assembly version) as well otherwise it'll fail. To work around this you can use a binding redirect but that is is a different conversation. The file version is completely irrelevant here.

To make this a little easier most companies set the assembly, product and file versions (ignoring string versions here) to the same major.minor value. The patch version though varies. In general the file version will be the most correct (1.2.3.4) and is often bumped up each time it is built so installers work. product version is just for display and is irrelevant. Assembly version is generally the major.minor.0 or major.minor.patch (1.2.0 or 1.2.3) if you need to distinguish patch versions. This allows multiple versions to be installed in the GAC while not breaking existing code.

A final thing to note is that references in Solution Explorer come from the file system whereas the runtime uses the GAC and search paths. They are not necessarily the same thing. The correct approach to solving this problem is to use NuGet which handles dependencies more easily. So how did you add the reference to your project? If you used a file reference then it is probably wrong.

If you are just having a minor version issue then a simple binding redirect should work. I would look at the assembly metadata first, not visible in Windows explorer. This is what the CLR will use.