Build number Mismatch : Problem with Sybase ASE version

Question

I have a C# Console application which references Sybase.Data.AseClient.

• dev machine has version 1.15.325 version of dll
• UAT has version 1.12.XYXZ
• Prod has version 1.15.115

I get the below exception on a machine similar to prod

---

ERROR 2010-11-11 18:18:23,562 15546ms FxSpotRateServer Main - Error System.TypeInitializationException: The type initializer for 'Sybase.Data.AseClient.AseConnection' threw an exception. ---> Sybase.Data.AseClient.AseException: Build number Mismatch - sybdrvado115a.dll. Expecting build number greater than or equal to '325'. Loaded build number 152. at Sybase.Data.AseClient.AseConnection.CheckVersion() at Sybase.Data.AseClient.AseConnection..cctor() --- End of inner exception stack trace --- at Sybase.Data.AseClient.AseConnection..ctor(String connectionString) at Applicationname.ClassName.GetAseConnectionString(String connectionString) in -------------------------------------------------------------------------------------------

I am thinking of doing having a runtime binding configured in my app.config and do this redirection on runtime.

Is there some other way/patterns to dynamically plug in these versions?
Is my approach clean and suggested?

Answer 1

This is not a problem you can fix with a .config file. It is finding an old version of the unmanaged code that actually does the heavy lifting. The name is in the error message, sybdrvado115a.dll. I'd look in c:\windows\system32 first.

You are going to have to update the Sybase provider on that machine to get past this exception. Or find an old version of the managed wrapper somewhere. Upgrading, and getting all machines up to date, is definitely the better solution.

Answer 2

By default, .NET binds to the version of an assembly it was built with under the assumption that it's been tested with that version. By adding a runtime binding configuration, you're telling .NET that you've verified that everything works with the alternate versions. You've basically told .NET, "Trust me. I know what I'm doing." This sounds like the most reasonable approach for your situation. (There are more complex situations whereby you can dynamically load DLLs in code without consideration for assembly version, but that is more for plug-ins or other situations where you don't know the assembly upfront.)

Answer 3

I decided to go with making the DEV machine same as UAT , thus downgrading the version of Sybase Provider I have on DEV machine . UAT and PROD are made same by systems people . I think it better than runtime assembly loads as we will have the transparent DEV environment where people would only use the features that they can run in UAT and PROD. Even though I was doing nothing which could not be down with a lower version of Sybase providers it is safe to have all the environments consistent.

Thanks to every one.