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?
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.
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.)
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.
Related
I'm working on upgrading an application from .NET 3.5 to .NET 4.0, eventually 4.6, which is currently crashing during the install process. I changed a lot when re-syntaxing the old Managed C++ code into C++/CLI, but ~95% of the other C# files haven't been touched, other than the .NET settings. The code has also moved from VS 2010 to VS 2015, and the target machine has moved from 32-bit Windows 7 to 64-bit Windows 10.
Running my new installer on the target machine produces the following error box:
Error 1001: An exception has occurred during the Commit phase of the installation.
This exception will be ignored and the installation will continue.
--> Ambiguous Match Found.
The past couple Error 1001's have been regarding differences in the .NET versions, and required changes to the code. The messages were also more specific about which files were in question.
I was able to get logfiles for both the working and new version. They have similarities, but one line that stands out that's not present in the older log is:
MSI (s) (6C:A4) [11:17:04:754]: WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\FOLDER' folder had been blocked
by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
I'm wondering if this is related or not, a good number of these lines appear and then the logs look different from there. I'm not even positive if the issue is with the code, or something like a setup problem with the installer projects. Does anyone have any ideas on where to look from here?
Error 1001 is nearly always the downstream result of a custom action failure, so it's going to be a code failure, load failure, something like that. Either way it requires debugging the code path or loading of your code. These managed code custom actions are not loaded in the "normal" way. They are instantiated using reflection, some version of the runtime will be loaded, and some things like automatic loading of config files won't work. In an Everyone install they run with the System account. These all have downstream effects that can cause failures of code that works in a normal user loading environment (which being a Dll called by msiexec.exe is not).
The dual folders entry isn't related. You haven't posted the architecture of your setup project, but 32-bit setup projects can't install to the 64-bit ProgramFiles folder. With 64-bit setup projects you probably want to be using ProgramFiles64Folder, CommonFiles64Folder etc.
Edit: Ambiguous Match Found might be a reflection error related to locating installer class types.
I'm having a lot of trouble trying to track down the cause of this error message. I have a large Visual Studio 2010 solution which compiles without error on my local machine but on the build server, msbuild fails on one of the projects with the error:
fatal error CS0002: Unable to load message string from resources
Here's the red error section at the end:
Build FAILED.
"C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj" (default target) (9) ->
(CoreCompile target) ->
CSC : fatal error CS0002: Unable to load message string from resources. [C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj]
0 Warning(s)
1 Error(s)
The entire msbuild output from the build server is here: http://pastie.org/3660842
What does the error generally refer to, that would cause it to build locally but not on the build server?
UPDATE
I have just run msbuild /version on both machines and it turns out the .net framework versions are very slightly different. Local machine is 4.0.30319.488 and build server is 4.0.30319.1. I'm about to run windows update on the server to allow it to install some updates, as several seem to be .net framework-related, so I'll see if that makes a difference.
UPDATE
Installing the updates didn't help. Just remembered I copied up csc.exe from the async preview a little while ago in order to facilitate async compilation (the actual async preview had failed to install on the server due to visual studio not being there, but installing visual studio team viewer seems to have fixed that, so i've just run the proper async ctp3 installer to see if that makes a difference.
CS0002 is not documented. Interpreting the error message, I'd say that the compiler is trying to show you a compile error message but fails when it tries to retrieve the message text. Slightly odd is that it doesn't actually have a string table in its resources, not sure where it comes from.
Well, something is pretty borken. Your idea to update the .NET framework version is solid, that will update csc.exe as well. Ought to be good enough to fix any damage.
This is often a problem with the Entity Framework designer's handling of your connection strings. In your app.config file, make sure the assembly and resource names are what they're supposed to be.
Here's the format for that particular part of the connection string:
Metadata= res://<assemblyFullName>/<resourceName>
Ok based on my own experience of trying to solve the problem, as well as Hans's answer and a few other discussions I dug up while Googling, I'm guessing that the only way to make this error occur is to have an issue with current state of one's .Net framework installation. Essentially, a mismatch between the compiler and some other resource it uses means when the compiler hits an error, it tries to pull the error message from the referenced resource, but because the resource doesn't match the compiler build, the error message is unavailable and instead the compiler reports that it can't load the message (and thus can't effectively display the correct error message).
Hence the fix is to repair the .Net framework installation, which can be done by reinstalling it, running a repair on it, or installing a newer version (which in my case was the async ctp, which while not a full .net framework version upgrade, was enough to correct any mismatched resource references used by the compiler).
I have a .NET CF 1.1 application that has been running perfectly fine for years. Occasionally, I get a help desk ticket with the following error message (generic):
Method not found:
MethodName
AssemblyNamespace.Class
The DLL is there, and it's the same version as my other devices. What could change that would make it not find the method. Does this error imply that the assembly was loaded, or did it break before that even happened?
Does it matter how I added the reference in Visual Studio (2003, btw)? I have Copy Local set to true, and therefore I made the assumption that it needs to be in the same directory as my executable.
Any help you can offer is appreciated. Thanks.
EDIT: I believe this DLL is also in the windows directory of the device, possibly a different version. It contains a lot of hardware specific functions (i.e. backlight, keyboard state, etc.)
No it does not matter how you add the reference in Visual studio 2003. (100% sure)
Now for the not so sure : I think that someone else has the same assembly in the GAC of the phone. So the GAC assembly gets called rather than the one you deployed and that version of the assembly lacks the requested function.
Depends on how you reference the file in your code. You could be relying on the current working directory which depending on how the app is launched or what they do after, it might not be what you expect it to be.
Sometimes .NetCf throws this exception when the device is running out of memory, instead of the expected "Out of Memory" exception. I have observed this behaviour more often when loading native dlls using P/Invoke than loading pure netcf dlls.
I am trying to use Microsoft.Jet.OLEDB driver to connect to an access database from my C# application. When I try to open a connection, I get an error: "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine." This is because the driver is only supported on 32 bit machines.
My solution was to change the platform target of the project that references it to x86. If I try to change all of my projects to x86 I get major build problems, so I am leaving them all on 'Any CPU'
Problem now is when I start up in VS, it tells me: "Could not load file or assembly 'MyProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."
I've tried about every configuration I can think of and I just can't quite get it to work. Any tips?
You'll have to switch the whole thing to x86. As you've found, there isn't an x64 driver for Access.
Your other code, if compiled x64, can't use x86 assemblies. You might want to review this question: Can an x64 application use x86 assemblies - and vice versa?
UPDATE
Interestingly, I found the Access Database Engine x64 from MS. You might try to grab that and see if it will work for you. You might also check out this discussion on MSDN.
You do have to switch to 32-bit to use Jet. (Edit: unless you use the new driver a couple of other posters have referenced).
If any one of your projects is using image lists, there is a bug that will cause errors when switching from 64-bit to 32-bit. As I recall you either have to rebuild the image lists from scratch or drop them and use something else instead.
You can find more info here and here.
When i try to deploy mapped table into database with GenerateSchema..i get the exception:
NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.SQLiteDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> NHibernate.HibernateException: The IDbCommand and IDbConnection implementation in the assembly SQLite.NET could not be found. Ensure that the assembly SQLite.NET is located in the application directory or in the Global Assembly Cache. If the assembly is in the GAC, use element in the application configuration file to specify the full name of the assembly..
I tried to solve this with NHibernate.Driver.SQLiteDriver -> NHibernate.Driver.SQLite20Driver..but did not worked..I added all references for NHibernate, Sqlite..Linfu...
Has anyone idea for solution??
A stab in the dark:
The one thing that always catches me out with SQLite is that it's a mixed assembly; it contains both managed and native code and targets one configuration (typically x86). If you're working on a 64 bit operating system and using the x86 version, then you may be having problems with bitness. Unfortunately, this doesn't produce a useful error message.
Try setting your project to build using x86 and see if that helps. Also, make sure you've got the correct version of SQLite. Some versions ('managed only') don't work out of the box. I use this version (unzip and then use the "System.Data.SQLite.DLL" file from the root directory).
I've run into these problems in the past and it took a bit of trial and error to get it working.