We are using C# ZKempkeeper (CZKEMClass) dlls to downloading attendance data from biometric/finger scanning machines.
Some time the code is working fine, but mostly its taking long time and even not giving time out error. This is the line where compiler stuck and never come back
status = zkemkeeper.ReadAllGLogData(iMachineNumber);
I've experienced the same problem before. I had to run it as administrator because the main project is using an external DLL.
try
Actually, from the screen only ZKEMSDK.DLL and "Visual C++ 2003
runtime" is missing but required. The other DLLs above is "normal" to
be missing and will not harm your application's functionality.
Unfortunately since seems Microsoft have removed downloads for C++
runtime before VC2005, you should use the DLL that comes with the
package.
Also, make sure your program compile as "x86" instead of "Any CPU" or
it won't find the DLL on 64-bit systems. (The fact that it depends on
VC++ 2003 runtime implies this must be 32-bit DLL)
https://social.msdn.microsoft.com/Forums/en-US/11fbbd80-cf40-4ecd-8f73-26785cb32383/unable-to-use-zkemkeeperdll-from-64-bit-computer?forum=netfxbcl
Related
Lately I am having some very weird problems and I can't exactly pin out what is causing it.
I've got an Access frontend application which uses SQL Server linked tables. A few days ago I deployed a new ACCDE version which caused some very weird problems.
At one computer I was unable to open a form from the Ribbon (some 21~ ish error can't exactly remember but it was a default open-form error). After some investigation I found out that the problem is caused by an allow additions = false line on the on-open event of the form. This however is very strange since it has always been there. Besides that, at almost every other computer, including mine, it just works fine while the code (and forms, queries, etc.) are exactly the same..
When trying to open the same access file in accdb at that specific computer it does seem to work (opening being done with runtime version).
So as workaround (for the time being) we made sure that that this computer opened the file as accdb while the others (where it did work) opened it as accdde.
Today however it went wrong again but on a different computer and a different issue. Now a completely other form doesn't load it's data (it's empty). Testing it locally it works fine however and testing it yet again on another computer (with also a runtime version) it also opens fine with data in it...
The weird thing is when using an older file (a few application versions back) just works fine but the current one doesn't, at least not on all computers. This makes me believe that the file is corrupted but the weird thing is, why DOES it work on some other computers? If the file would be corrupted you would say that it is causing the issues on all the computers?
So the next thing I thought of was different Access runtime versions. I tested 4 computers (two where everything works fine) and the other 2 have issues.
Computer one (which works fine) is a 32 bit system with Access runtime version 15.0.4841
Computer two (with issues) is a 64 bit system with Access runtime version 15.0.4569
Computer three (also with issues) is a 32 bit system with Access runtime version 15.0.4833
Computer four (my own computer tested against a local db) is a 64 bit system with Access runtime version 15.0.4849
So the computers where the Access file doesn't work all have a lower version than the ones that do work, is it possible that this is causing the problem?? If it is, I still wonder why the older Access application file works on all computers but the current one doesn't..
On a side note:
Also tried to repair the access runtime version on one of the computer where it didn't worked but this had no effect
Doing a Compact & repair on the Access file itself also doesn't have any effect
Well, you plain and simple cannot run an x32 accDE database with the x64 bit runtime – it simply will not work.
And if the runtime versions are different on those target machines then you want to un-install the runtime, and download the latest version. Windows update will NOT update the runtime. With runtime 2010, you had to download + install runtime, and then ALSO download an update to the runtime.
With 2013, then the latest download of the runtime will always include the latest SP updates.
Attempting to run Access with different runtimes will in general be a disaster. And in the case of attempting to use the x64 bit runtime on an application compiled to x32 will not work at all.
I would also before you compile to an accDE check and remove any and all references not required. So references to word, excel or anything else should be removed and late binding should be used.
Regardless, you want to ensure that all computers are using the same runtime version, and this includes the bit size. So in all cases you want to ensure and use the x32 bit runtime, and then ensure that all machines are running the same version/revision of the runtime.
Im trying to use this http://www.devart.com/dotconnect/mysql/ with Indusoft Web Studio to connect from Windows CE to a MySQL database as its the only solution Ive found. The connection works (from what I see in the logs) but then a error message saying "License not found" pops up. Besides having terrible support, Devart for some odd reason does not understand Im using another IDE besides Visual Studio to compile this project. They keep telling me I need to add the resource to the project when IWS has nothing like this.
I tried to decompile the DLL but I cannot find a method to jump pass the "License not found" message.
Has anyone got this to work with a already complied program and just put the DLL in the same folder as their exe?
Ive tried their .NET Compact Framework complier as well but it did not work either. Their support is like I mentioned terrible. One of (if not the) the worst Ive had to deal with in YEARS.
I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.
I am a totally unfamiliar in this C# Visual Studio programming environment but I am required to finish a task.
I am sorry if my question seems silly. But I really could not understand what other posts on this site or other site on the net explaining. I need a step by step guide to do this final step to accomplish my task.
I have been given an application called MCC written using Visual Studio 2008. However, this application could not run properly in Window Vista due to the issue of DEP. MCC has a function to display video from an IP camera. This required the ActiveX control of AxGif89aLite. However, DEP in Vista is by default enabled. The flag IMAGE_DLLCHARACTERISTICS_NX_COMPAT in PE header do not allow this control to be used. Several tests have been run and identified this is the problem.
From an article online,
http://blog.dyadica.net/archives/data-execution-prevention-workaround, they suggest I need to add the below to MCC post build event.
call $(DevEnvDir).. \tools\vsvars32.bat
editbin.exe /NXCOMPAT:NO $(C:\Program Files\Aerocut\MCC\MCC2.exe)
So, I add this and rebuild the MCC solution file. Then, I cannot get what this last step required me to do.
Please note that if you sign the binary in Visual Studio, flipping the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag in the post build step after the binary has been signed will result in an assembly that will fail strong name validation. To work around this sign your binary as part of the post build steps.
To do this, use SN.EXE from the Windows SDK.
I am really confused what is this signing binary.
From information that I googled, signing an application is getting a certificate for the program so that it is more secured, am I right here?
I got the SN.EXE in my computer. But, how do I sign my binary as post build step? The binary should be my compiled execution file right?
I reinstalled the MCC with the rebuilt setup file. It still give me the following error:
Unable to get the window handler for the 'AxGif89aLite' control. Windowless ActiveX controls are not supported.
Help is very much appreciated. I would like to express thank you in advance here first.
If you're not signing the executable already as part of the compilation then you don't need to worry about it.
I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.