Motivation
I'm trying to track down an exception thrown by .NET Framework when opening connection to Access mdb database file. I'm not opening the database connection directly but rather use one of DevExpress Xpo facilities (XpoDefault.GetDataLayer(...) to be precise) which internally attempts to create connection to provided mdb database file. That attempt fails somewhere deep in .NET Framework code and exception is thrown.
Exception has System.Data.OleDb.OleDbException type and is very vague about the problem source. Message says "Unspecified error". ErrorCode is -2147467259 (NativeCode is 0). There is to little information to find out why database connection cannot be created. I thought that maybe going deeper into .NET Framework code would reveal something important about the failure.
Problem
Source files mismatch when stepping into .NET Framework internals. Inconsistent execution flow.
Description
My application is targeting .NET Framework 4.6.1 x86 platform and built in Debug (Release does not change anything). Visual Studio Enterprise 2019 v16.6.3 is the IDE I work with. Of course I've read all I could about debugging into .NET Framework first but it did not help to solve my problem.
What I have done so far? I have successfully download DevExpres PDBs and sources. No problem with that - I can follow execution down into DevExpress internals (which IMHO confirms that overall debugging setup is rather correct). It also seems that .NET Framework PDBs are correctly loaded from Microsoft servers during debugging. I think that Visual Studio Debugging settings are also fine (as far as I'm aware).
All goes well until I need to step into OleDbConnection.cs file which gives the following message:
The problem is that I have all .NET sources available from https://referencesource.microsoft.com. All (including updates) from version 4.5.1 up to latest 4.8.
No matter which one I choose - I'm always getting same message about not matching source file version. When I ignore the message and decide to use the source file anyway, it shortly turns out that inconsistency is real. Instead of tracking the source code execution I'm stepping over comments or execution flow simply does not make sense and clearly the presented source code is not in sync with what is going on.
Ok, that's it. I could not get any farther. Am I doing something wrong? Where to look for .NET Framework sources which would match the executing modules and allow to discover origins of the exception I'm getting?
Update #tgolisch
Code which gives an exception:
Session Session;
ReflectionDictionary reflectionDictionary;
string connectionString;
...
Session = new Session(XpoDefault.GetDataLayer(connectionString, reflectionDictionary, AutoCreateOption.SchemaOnly));
Connection string used in XpoDefault.GetDataLayer(...) call:
"Provider=Microsoft.Jet.OLEDB.4.0;Password=;User ID=Admin;Data Source=C:\\Svn\\trunk\\Apps\\bin\\Debug\\DbFile.mdb;Mode=Share Deny None;"
XopDefault.GetDataLayer(...) is the call which fails and throws exception.
Update #Perry Qian-MSFT
I did exactly what you suggested with no success. There was no improvement at all. However, I have made a fair progress after disabling optimizations of system assemblies as described here. With optimization turned off, tracking of .NET Framework internals becomes feasible. No more random jumping or stepping over comment lines.
However, it is not a full success yet, because I'm still getting messages about mismatch between executing modules and the source code file versions.
I have also noticed that even though my app has .NET Framework 4.6.1 as a target it still uses version 4.8 of system modules during execution:
That suggests I should use .NET Framework 4.8 sources when stepping into framework internals. But wait - I have tried all sources I could get with the same mismatch problem.
What can also be seen is that there is more than one version of system assemblies being run with the app - 4.8.4110.0 and 4.8.3761.0, which suggests that different sources might have been used to build them.
Yet still, no matter which sources I take there is always a message about source mismatch at some point.
Considering that assembly optimization problem has been resolved, which framework sources should I use now to have them in sync with running modules?
Source files mismatch when stepping into .NET Framework code
Please reconnect your DB Access database to refresh your database in case there are some build errors in the db layer.
Besides, please follow these suggestions to troubleshoot your strange issue:
1) Tools-->Import and Export Settings-->Reset all settings-->..General to reset all debugging settings.
2) then, close VS, delete .vs hidden folder under solution folder, bin and obj folder.
Related
I wanted to be able to step through/debug the source code of the .Net Core framework, since it is open source now and everything.
So I followed some answer on here, or something, but I've forgotten exactly what I did.
The problem is that the loading of the symbols took forever each time I started debugging and, worse, Visual Studio would no longer break on most exceptions and whenever there was some issue it would break but show me the exception in some esoteric class or file that I, presume, is part of .Net Core even though I know the actual exception is being thrown in my own code.
So, now I want to fix that and have the symbols loaded once and then used from the cache and VS breaking on exceptions like it should normally.
Failing that I'd like to undo whatever I did but, like I said, don't remember exactly what I did. Here's what I think I did:
Go to Tools -> Options -> Debugging -> General and check the following options:
Enable .Net Framework source stepping
Enable source server support
and unchecked:
Require source files to exactly match the original version.
I also have both "Microsoft Symbol Servers" and "Nuget.org Symbol Servers" in my "Symbols" section and the option "Load all modules, unless excluded" selected.
So, how can I still step through .Net Core source and have VS behave like normal with exceptions and not load symbols for 5 minutes every time I start debugging
-OR-
How do I undo any options to have everything like before?
System.BadImageFormatException: 'Could not load file or assembly 'mongocrypt' or one of its dependencies. The module was expected to contain an assembly manifest.'
I have a project that runs Hangfire 1.7.5 with MongoDB 2.9.1.0. This project is used as a backend engine to perform various types of work.
In order to create endpoints for outside systems to call this engine, we have another project that uses the same versions of Hangfire and MongoDB to connect and pass in the jobs for processing.
I upgraded Hangfire and Mongo to the latest versions, 1.7.9 and 2.10.1.0 respectively in all the projects that were using these dlls. Using Visual Studio, when I run the web projects, I keep getting the above mentioned error. I get these like 4 to 5 times before the ASP.Net site loads up and allows me to access anything I need, including the data that is accessed via MongoDB. Just an inconvenience but still an exception when loading project.
I know that architecture of the CPUs might cause the System.BadImageFormatException but nothing in that sense has been changed. I am running everything on .net 4.6.1 and everything continues to run on AnyCPU configuration. If I change all these projects to x64 or x86, one or the other thing stops working. mongocrypt error continues to occur regardless of the CPU architecture.
I cant find anything on google or SO regarding mongocrypt. Any ideas?
Same thing happened to us.
It appears that in v2.10.0 a new dependency library was introduced libmongocrypt
that causes this error.
Try to go back to v2.9.3 to workaround this issue until it is fixed by mongodb programmers.
mongodblibmongocryptc#
I've tried placing the basic dll's into unity's assets folder - Result: "blah blah will cause Unity to Crash Error."
I've tried Manually adding references - Result: Unity refreshes its references anytime the editor refreshes, so worthless.
I've tried Installing using NuGet - Result: Closest to success as it handles all the dependencies and whatnot but I get: Assets/Scripts/Developing/TalkToDB.cs(3,7): error CS0246: The type or namespace name `MySql' could not be found. Are you missing an assembly reference?
Is it some kind of a combination of "Use NuGet then copy the dll into the Assets?" or something redundant like that? cause that's about the best guess I've got.
Also, I've tried a couple older versions of the NuGet package to no avail.
As well, MySql.Data is listed under the References of "Assembly-CSharp"
And my Unity is set to 4.X framework Using Unity's latest 2018.2.5f1 (64bit)
(I really hope that I don't have to ditch 4.x for this to work... I'll miss initializing values to properties..)
Fortunately I came across this:
How to get MySql Connector/Net Working with Unity 2017
And Regarding Security concerns. My Key is none of my sessions should ever be persistent from .NET - There will be advanced PHP scripts for altering of data and anything regarding elevated permissions.
Reference: Why you shouldn’t connect your mobile application to a database
Beyond this,
Exceptions to the rule.
"Some database vendors may have provided drivers to connect to remote databases, but as yet I’m not aware of any.
Other exceptions include ODBC connectivity. For example, I’ve heard of developers being able to (or at least trying to) connect to MySQL databases using JDBC when developing applications in Java. This is not actually quite the same as connecting directly using a binary driver, however, it comes close..."
- 2
This is exactly what I will be doing, using the MySql Connector to talk to MySql drivers (which I'm too tired at the moment to recall the name of(maybe it's based on ODBC? I can't remember. Thus Google. Lol))
So all in all, using the link provided at the top, Unity 2018 can be compatible with the latest (as of this post) MySql Connector(s).
Any Assets folder must contain: System.Data.dll & MySql.Data.dll (that's it)
No NuGet required.
However the error message: "Loading script assembly 'Assets/Plugins/MySql/System.Data.dll' failed!"
And as of yet, it is apparently not able to reference connectionString from an app.config like your normal C# outside of Unity would be able to.
This being said, I'm working on finding either Unity's implementation of the app.config, or an equivalent alternative.
UPDATE:
Aside from a couple annoying dll loading errors in Unity that don't influence anything - other than annoying me and wasting a couple bytes of RAM for a second (lol, y'kno.);
All works well and I remember the reason I am not concerned about connecting my application directly to my Database is because the ONLY permissions the users will have is the Execute permission so all procedures will be stored on the server (via Stored Procedures) and thus protecting the database against any potential attacks even if cough coughwhencough ahem, a user decides to "de-compile" (is that even a word...? heh) my application.
Final Update:
As I posted here;
It took me a week to finally figure it out...
You need to use:
I18N.dll
I18N.West.dll
I18N.*.dll (Optional, they are region specific)
System.Data.dll
from C:\Program Files\Unity\Editor\Data\Mono\lib\mono\2.0
NOT the BleedingEdge path. Then it will work without errors [And in Builds]...
confirmed in the latest Unity 2018.2.14f1
Place into the Assets folder - Also the project needs to be set to .Net 4.0
I'm experiencing a lot of problems with Entity Framework 6.0.1 in the VS2013 Ultimate debugger when debugging into unit tests against code that's hitting a live SQL Server.
Variables that contain entities can't be viewed in the debugger. For example, if I execute a LINQ query against my DbContext and refresh the results view to actually execute the query, the Results value is "children could not be evaluated". If I ToArray() it, so now the variable is an array of entities instead of an IQueryable, each result in the array is "Could not evaluate expression". If I store a single entity value from that array to a variable and try to view it, I get "The runtime has refused to evaluate the expression at this time."
Frequently, F10'ing through a line that involves access to an entity property causes Visual Studio to crash.
This doesn't happen if I'm running the test against a mocked-up fake DbSet.
Is this a known issue? Is there a way to fix this?
I am having a similar problem and although I'm yet to understand why, turning Options -> Debugging -> General -> Use Managed Compatibility Mode - On, allowed me to continue debugging as normal.
I found this option via this blog post.
Shortly after installing VS2013, I also encountered the error
"Could not evaluate expression"
for numerous variables while debugging an older VS2012 solution (none of the code involved the entity framework).
The fix that worked was deleting the two Solution User Options (*.suo) files associated with the solution file. For example, for MySolution.sln, the two corresponding files were:
MySolution.v11.suo (VS2012 version)
MySolution.v12.suo (VS2013 version)
It seems that the v12 version might have been corrupted when it was initially created using the settings from the v11 version. Hence, deleting both of them allowed for a new clean .suo file to be created for VS2013 and the problem went away.
(Note, the .suo files are marked as hidden on Windows 7 so you might not easily see them in Windows Explorer without either changing the settings to show them or using the command line to view them.)
There may be a problem regarding debugging if there are any entity with Virtual entities inside.
We had this problem when trying to debug at entities inside Ef scope.
Entity Framework then try to catch the state of the virtial entities.
We got a better result while viewing the entities outside db scope.
This way EF is not involved while watching the entities values.
Visual Studio 2013 Update 2 promises to fix this error, found in the comments at:
http://weblog.west-wind.com/posts/2013/Nov/21/Visual-Studio-2013-Could-not-evaluate-Expression-Debugger-Abnormality
I just wanted to add my voice to the crowd here.
I am developing a UWP app, not using the Entity Framework, and experienced a similar issue where the runtime "refused to evaluate the expression".
I was using Microsoft Visual Studio Enterprise 2015 Update 2 and the solution for me was for me to update to Update 3.
A user of my program has reported an inability to startup the application. I am not yet done troubleshooting, but I'm simply baffled.
Logging still works, so I used logging statements and was able to narrow down the crash to a single line in a user control's InitializeComponent:
this.HorizontalBox.Image =
((System.Drawing.Image)(resources.GetObject("HorizontalBox.Image")));
Here are the relevant clues from his end:
64 bit Windows 7
Correct .NET Framework (4.0 Client Profile)
No visual elements ever show, and no error dialogs. It is a silent shutdown when starting.
Logging works, but there were no logged errors.
He has uninstalled and reinstalled the .NET 4.0 Client Profile framework.
He doesn't have any Visual Studio or other development tools mucking with stuff.
I have spent a week or so eliminating theories and I'm becoming confused and desperate. Here are relevant details and things I have found:
I am targeting x86 explicitly.
The logging which failed to log any exception is set up to catch and log any unhandled exceptions and thread abort exceptions.
Whatever is killing the application also prevents the final "shutting down" logging message in the program's basic entry point.
I had read that certain icon (.ICO) file formats don't work in Windows XP. A far fetched theory, since this is Windows 7. This is the one and only case of ICO files in the project, so I was suspicious and switched it to PNG. No difference. I since figure that the image is failing merely because it is the first image loaded from a resource.
I had read that the Form_Load event may swallow exceptions (and only when debugging). Also, InitializeComponent() is in the constructor, so the theory was shaky. Nonetheless, I wrapped the call to InitializeComponent() in a try/catch, but the catch and its associated logging never get called.
I have seen posts about resource compilation problems between x86 and x64, but nothing relevant to runtime issues. (See this post)
I assumed there must be something wrong unique with the program showing issues, so I made a WindowsFormsApplication1 test application with nothing more than a single image embedded in the associated resource file. This also fails to load in the same way. This test application was also targeting x86.
It works fine on other x86 and x64 machines!
What could possibly be going on his machine? Why is exception handling failing me? This problem is crazy!
Edit: More Details, and I'm still baffled!
I have since sent the test application (a single form with a single image on it) built as x86, x64, and "Any Cpu". The x64 and "Any Cpu" applications both work.
Some questions spring to mind. Have you got a similar build machine with which to test - this may help to identify if it is the build/program integration or some possible issue with his build (i.e. a windows problem/virus/etc).
Has he installed to the default folder or did he do a customised install?
Has he tried a full uninstall / reinstall of your app? (I note you said the runtime was refreshed) - possibly to a different folder to make sure.
Can you recreate on a similar build (OS version) with VS installed to do a code walkthrough in the debugger - stack trace and output buffer may help identify - so may disasembly - and can set it to stop at all exceptions?
Unfortunatly unhandled exceptions can not always be caught in C# (especially post 2.0) - so a debugger of WinDBG may be your only option in the end (yuk!).
Can I suggest something though first...Just a thought:
Before the line that fails, as a test, output something like this:
var obj = resources.GetObject("HorizontalBox.Image");
Console.WriteLine("Obj = " + (obj is Bitmap));
Because I have a feel that the failure is happening when trying to marshal the resource into the Bitmap Type and getting a memory exception (maybe something corrupt with the image stride/pixel format etc or maybe something on the culprit machine is making the image file look like a non image file).