search

dynarithmic / twain_library-csharp_demo

C# demo project using the DTWAIN library
Apache License 2.0
1 stars 2 forks source link

Application crashing on newer versions of .Net framework #2

Closed martron1 closed 1 year ago

martron1 commented 1 year ago

I tried running the application using a .Net 4.6.2 Framework (since that is what the application I'm working with uses). When I try selecting a source the application simply crashes. I tried using both Any CPU and x86 configurations, and in both cases I get the same outcome.

The demo works perfectly using the default .Net Framework 2.0.

Do you have any suggestions on what to do to prevent it from crashing?

dynarithmic commented 1 year ago

I would suggest getting the full demo from the upcoming release found here.

1) Load the AllDemos solution, and build the CSharp_FullDemo project. 2) Make sure you are using version 5.3.0.4 of the DTWAIN libraries, and that this is the version that is being loaded when your application starts. 3) Change the Net framework to one more recent than 2.0 and rebuild.

I followed these steps (I am using Visual Studio 2019), and the demo ran without any issues. I chose 4.7.2, and the demo ran just fine.

More than likely, the current version (v5.3.0.3) will also run without issues on a more recent .NET framework, but since version 5.3.0.4 will be released very shortly, I suggest getting this version.

I have not had time to update the demo found in this repo, so maybe there are issues with it. But I found no issues with the demo found in the twain_library repo in the master-staging branch.

dynarithmic commented 1 year ago

Just to let you know, I am not a C# guru, as my main languages are C++ and C, with Java being third. I can set up, debug, and make the requisite calls to the DLL's, but any in-depth knowledge of .NET, the framework, etc. unfortunately I'm not that person.

Having said that, the project, at least how it stands now in the master-staging branch, does build and run with the setup that I have.

martron1 commented 1 year ago

The full demo yields the same results. I also tried using the 64 bit dll but that also had the same outcome. After testing a bit more it seems that the highest version of .Net that doesn't crash is 3.5 (in Visual Studio 2022).

So it looks like the problem is with visual studio. I also tried using VS 2019 and it worked. Unfortunately using VS 2019 is not the solution I'm my case since the production build for the application is made using VS 2022.

The solution I came up with and the one which works the best so far is separating the scanning logic into another project in my application, setting the projects framework version to 3.5 and type to windows application, and just calling the project as a separate process from my application.

dynarithmic commented 1 year ago

Just curious -- what happens if you run the program outside of Visual Studio 2022?

dynarithmic commented 1 year ago

I just tested the AllDemo.sln version of the C# project under Visual Studio 2022. Chose 4.7.2 as the NET framework. The program ran without error under Visual Studio. The DLL's and the text resources are in the same directory as the executable, to ensure that older versions of DTWAIN are not being loaded.

So probably it is a Visual Studio issue on your end -- but again, what happens if you run the executable outside of Visual Studio?

Another thing that may be happening (not a surprise if it is happening) is that the driver you are selecting has purposefully disallowed debugging of the driver. Either an exception is thrown, or the driver will detect it is being debugged and thus shut down access. This was the case a long time ago with a scanner driver I dealt with -- the application could not be debugged if that driver was selected, but outside the debugger, the application worked flawlessly.

So try running the app outside the debugger to see if there is a difference.

martron1 commented 1 year ago

Using Visual Studio 2022 to build it and then running it outside of VS 2022 works.

After further investigation your assumption about the driver disallowing debugging seems to be correct since when I tried running it without a debugger it didn't crash and I was able to use it without any problems.

martron1 commented 1 year ago

The driver I'm using is the hp smart tank 750 series driver.

dynarithmic commented 1 year ago

Just to let you know, there is an open issue with HP concerning exceptions being thrown when their TWAIN driver is selected.

This was also briefly discussed in #1.

dynarithmic commented 1 year ago

Since this seems to be a driver issue, I will be closing this ticket.