We Keep Coding

Unable to load DLL 'SqlServerSpatial110.dll': Cannot find the specified module

I have a wpf c# desktop app that for the last few days has been throwing me this exception when it tries to save data to a sql server database that resides on a dedicated server.
Up until 5 days ago everything was working, and there have been no updates to the app.
The software runs on a Windows 64 bit PC.
Trying to add in the .config file this dependency :
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" />
<bindingRedirect oldVersion="1.0.0.0-11.0.0.0" newVersion="10.0.0.0"/>
</dependentAssembly>
did not give any more errors...
Do you have any idea what could be the cause?
Writing to the database is done with the Entity framework but the Microsoft.SqlServer.Types dll is never used.
Thanks

Could not load file or assembly Microsoft.Owin 3.0.0 to 3.0.1

Interesting dependency issue...
VS2015.3, .NET45 updating Microsoft.Owin from 3.0.0 to 3.0.1 (traced this update to be the problem - wanting to install https://www.nuget.org/packages/IdentityServer3.AccessTokenValidation/)
it works locally on IIS Express
but publish to Azure website: (am removing additional files at destination on azure publish straight from VS). restarted and deleted all files from azure webserver too.
web.config translation looks okay
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
Edit
Bruce Chen's answer pointed me in the direction of Kudu (Azure - Development Tools, Advanced Tools)
I downloaded the Owin dll, and it was the wrong version ie 3.0.0
To fix I cleared out all package artifacts from my solution
git clean -xfd (be careful)
Then rebuilt

I wasted a couple of hours on this too because the reference installed by nuget had version 3.0.0 despite the nuget package being labelled 3.0.1
Making the old version newer than the new version fixed my problem:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0"/>
</dependentAssembly>
*Edit: I think(but not certain) that the reason my version was still 3.0.0.0 was because the bin folder got caught in my repo and nuget didn't want to write over the dll

Could not load file or assembly 'Microsoft.Owin, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
In general, this means that the .NET Assembly loader could not find the assembly with specific version that was referenced. Please make sure this assembly with version 3.0.1.0 could be found in your Azure website and the version matches the definition in your web.config via KUDU or FTP client.
As you said, it works locally on IIS Express, please try to deploy your website content manually to Azure via KUDU or FTP client and find out whether it works or not.

It requires a new version instead of the one that you currently have.
If you are using Visual Studio right click the project --> Manage NuGet Packages --> Updates --> select the Owin nuget --> Click "Update".
As of today, the latest version is 4.0.0.
Hope it works out fine!

Just to comment here that I saw this type of error when I upgraded to 4.1.0.0 and my issue was on Web.config where I still had 4.0.1.0. So, what you have in .csproj should match what is in Web.config. Updating or reinstalling did nothing in my case until I synced up the version numbers.

In the NuGet Package Manager, check the version of Microsoft.Owin installed. Then update you project folder's web.config file, search for Microsoft.Owin in web.config and change "newVersion" to your NuGet Package Manager Version. This worked for me.

Microsoft.data.edm.dll being copied from "somewhere" on build in VS 2013

I am collaborating with another developer using VS2013 and VSO.
The solution runs fine on his machine but mine complains of:
"Could not load file or assembly 'Microsoft.Data.Edm' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
We've isolated this to the fact that 1 project within the solution is copying version 6.5.0 of this DLL into the bin folder upon build which is overwriting the 6.5.2 version required by other parts of the solution.
We aren't sure where it is finding this version of the DLL as it only happens on my build. We are using various nuget packages but all are up to date and identical between our machines.
Does VS pick up DLLs such as this from "standard locations" on the machine somwehere? I searched my hard drive and found various versions of the DLL going from 2.0 to 2.6.2. The most suspect of these seems to be:
C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Packages\Microsoft.Data.Edm.5.2.0\lib\net40
Is there anywhere I can tell VS not to get this DLL from some random location?
Thanks

Try to build it with detailed MSBuild information (Tools -> Options -> Projects and Solutions -> Build and Run) and then copy the output and search for Microsoft.Data.Edm.dll to find where it's copied and where does it come from.
To force the copy of the correct version, you can add an assembly redirect to the app.config file of the project (you may already have this section if you have used NuGet):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.2.0" newVersion="5.6.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
This will force the use of the correct version on compilation and will not try to get the other version from the GAC or the system PATH environment variable.

Use application with other version of dll without recompiling

I saw many threads about this problem but I couldnt find why my application doesnt work.
I want to use other version of Oracle.DataAccess library without recompling application.
I add to app.config lines:
<assemblyBinding>
<dependantAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342"/>
<bindingRedirect oldVersion="1.0.0.0 - 9.0.0.0" newVersion="10.2.0.100" />
</dependantAssembly>
</assemblyBinding>
If I good understand if I have version between 1.0.0.0 and 9.0.0.0 i force application to use version 10.2.0.100. But always when I change this versions application uses the same dll which was compiled.
My goal is just change dll in local application directory and force application to use this one

Upgrading dependent DLL without recompiling the whole application

We have windows service application which is using Aspose.Words.NET version 11.10.0 Now we have recently upgraded the Aspose.Words dll version latest 13.7.0
Since we have already deployed our windows service applications in multiple clients, we tried replacing the old Aspose.Words dll with latest its latest version. But when we restart the existing windows application it doesn't work with the replaced latest Aspose.Words dll.
We have resolved it by recompiling the whole windows application referencing the latest version of Aspose.Words dll. Are we required to recompile and redeploy our whole windows service application every time we upgrade the Aspose.Words dll?

Check this answer on SO too.
You need to update the config files of the desktop/web clients as follows.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<publisherPolicy apply="no" />
<assemblyIdentity name="Aspose.Words" publicKeyToken="716fcc553a201e56" />
<bindingRedirect oldVersion="11.0.0.0-13.6.0.0"
newVersion="13.7.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Please also note that there might be breaking changes in API which might lead to other errors. For example a method or property which existed in 11.0 is deleted in 13.7. The exception will be thrown when the client application calls the specific method/property. So, you must verify in development environment that the new version will not break your application. If it works, then you can just replace the old DLL with new version.
The config file is loaded at runtime, so you can update the config files where your applications are deployed.
I work for Aspose as a Developer Evangelist.