Make Sure The Binary Is Stored At The Specified Path Or Debug It To Check For Problems
Emerio Boykins
From my previous question, SOLIDWORKS ErrorCode:1722 CA:Register_DocMgrDLL, I am missing the swdocumentmgr.dll library. So I downloaded the library from -dll.info/file/swdocumentmgrdll and paste it in the C:\Program Files\Common Files\SOLIDWORKS Shared directory. When I try to register that library by
make sure the binary is stored at the specified path or debug it to check for problems
DOWNLOAD ⚙ https://urllio.com/2zLVys
I get:The module C:\Program Files\...\swdocmentmgr.dll failed to load, make sure the binary is stored in specified path. But it is in the path (in the directory). I have even tried to do it with administrator privileges but to no avail. How should I then load that library in order to install the solidworks?
So the installer is surely trying to execute the regsvr32.exe upon the swdocumentmgr.dll library. (So when I first encounter the error, I tried it register myself exactly as seen above, and when I could not register it manually, then it makes sense that the installer could not too).
EDIT: It seems that that this problem on the poster's Windows 10(and mine) comes from having a Windows 10 system that was upgraded.Perhaps some previous software remnant causes this problem.For the poster, a complete reinstall of Windows 10 has "fixed" the problem.
I have first looked into the digital certificate with which it's signed,created for Dassault Systemes SolidWorks Corp.,valid from June 2007 to June 2012.The certificate has elapsed, but that should not be a problem since an elapsedcertificate is still valid.Just in case, I digitally resigned the DLL, but this didn't change anything.
This message means that the DLL (or a DLL that it imports) has an import fromanother DLL (call it bad.dll). When the Dependency Walker scans bad.dll,it finds that it does not export the required function. This missing export ismost likely the reason that regsvr32 fails to load the DLL in order toregister it.
The part that worries me here is the number of anonymous functions, meaning entriesin Windows DLLs that are referred-to by their ordinals and not by name.If the ordinals have changed in later versions of Windows, this can cause havoc.
From the date of the digital signature, I would say that the SolidWorks software wasdeveloped on Windows Vista or at most early Windows 7. The problem can't bewith a wrong Visual C++ redistributable, because I have on my computer basicallyinstalled all the versions, up to and including for 2005.
I downloaded the software, unpacked it and installed it. But when I open the PLX DAQ excel file, it says: 'can't load object because it isn't available on this machine" (free translation). I checked the troubleshooting guide and it says i should check my macro security. I've put the secuity level to low, but it still won't work. I'm running windows 7 on a macbok pro OSX10 ith bootcamp.
The arduino is programmed by someone before me and i don't have the code. Is that a problem? I do have the arduino software running and the board is plugged in my laptop.
'What do you know, I sorted it. There is an activeX control (selmaDAQ_Ver2.ocx) that is in the c:\windows\system32 directory. However my registry was set to d:\windows\system32. My computer has done things like that before, confusing d with c, and some programs don't install right. I could have changed all registry references, but it was easier to just create system32 on my D and copy that file over.'
I found the file selmaDAQ_Ver2.ocx at another location:C:\Windows\SysWOW64. Could this be the problem? When i try: run-> regsvr32 selmadaq_ver2.ocx it says: 'the module 'selmadaq_ver2 failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found'
So now i copied the file selmadaq_ver2.ocx to the system32 file and ran regsvr32 again. Now it says: 'The modue 'selmadaq_ver2.ocx" may not compatible with the version of Windows that you're running. Check if the module is compatible woth an x86 (32 bit) ot 64 (64-bit) version of regsvr32.exe'. I have a 64 bit version of windows. What should I do?
Quite possibly. If you don't know what the code is, how do you you know it is what you want? Having said that, PLX DAQ need not be demanding of code. Other than a label in setup and accessing the windows clock in the loop, the data I send to Excel is just like data sent to any other CSV file. In view of this, I guess the first thing to do is send the data to the serial monitor and see if you can make some sense of it, but I suspect all your problems are at the receiving end. I guess you can test that by connecting Arduino to a proper Windows computer.
OK after hours of trying all kinds of stuff i found a solution. I thought i'd put it here because other topics helped me a lot.
The problem was with the 64 bit windows and 2013 excel version. I installed parallels desktop, installed windows xp and office 2003 and had no more problems!
(I posted this to all "first search site result" websites I found with Google for PLX DAQ issues so the next users of PLX DAQ can find the new version as fast as possible sorry for grave digging this thread)
Even after somehow correcting it and using it in windows 10 pro with excel 2007, the data from arduino is getting enrolled but after that the first row is getting overwrited again, even when there is a presence of data already.
I am having the same problem when writing GeoTiff files. The files can be saved when I am running in debug mode, but not when running the code outside of debug. I can also save the intermediate file by displaying first in ArcDesktop 10.5 and then exporting to a file. I am calculating the difference between two input (geotiff) Rasters, the results are in type "Double." I have checked to make sure there is not a file of the same name already in existence. I have also tested whether or not using a different geodatabase path makes a difference, it does not. I have check to see if I could just save it to a folder, I cannot. The code is as follows (current_datestr example: 201909101900):
I think the problem was that I set the nodata value for the current_raster, but forgot to set it for the previous_raster. In addition, I should have calculated accumulation amounts by setting Null values to zero before subtracting.
Actually, for your case (defining dependency for the binary target and getting it auto-pulled) there is an improvement/workaround in your Manifest file by making use of a regular source target as wrapper and define the binary target as dependency on it:
The only way I could somehow get my framework and the final client app to build properly was to add the 3rd party dependency's XCFramework folder manually via drag'n'drop rather than SPM, which probably works as the Framework Search Path is then finding the dependency properly.
Interestingly, if you make an "import Facebook" in the client's app itself the SPM dependency is found, just not from within the .swiftinterface files
The general issue here is that the Swift compiler needs to be able to see all the modules being used at build-time, either via .swiftmodule/.swiftinterface or module maps. A single XCFramework can only contain one such module, though.
You provide the third-party SDK separately, e.g. as its own XCFramework. The important part here is that you need to make sure that it doesn't get linked statically into your other XCFramework, otherwise you will run into duplicated symbols. For packages that means making any library products dynamic. This might require some significant effort since there could be more transitive dependencies.
I am trying to use your second solution, or something similar. My 3d party dependencies are not under my control and thus I am having problems linking them dynamically. If I use the wrapper described above, the dependency gets always linked statically, and it can not be found on runtime.
Is there anyway of forcing the linking of the deps as dynamic? Is this only possible if the vendor of the library set type: .dynamic on their SP repo?
@NeoNacho I am having this exact issue and the @_implementationOnly option is not viable for me. I would love to attempt either of the other 2 options, however, I don't have a lot of background on either. Would you mind shedding some more light on those options or perhaps some helpful reading you could point me to? TIA
To be honest, I haven't yet fully understood why then the build of the iOS app fails in case both our own XCFramework as well as the external framework (here: AppAuth) are defined as SPM dependency - shouldn't the Swift compiler "see" the required AppAuth dependency when building from our .swiftinterface? I have the feeling that XCode is just not searching in the correct path, but have no idea what path could be added properly to FRAMEWORK_SEARCH_PATH.
Actually this approach seems to work for us. However, we are still unsure about any side-effects of doing so, and unfortunately the @_implementationOnly feature is not very well documented and is still in some alpha state. Even after researching some links and our internal tests we fear the risk that this brings any trouble in external apps that do integrate our framework.
Is there anything that is known that might give trouble when making use of @_implementationOnly for third-party dependencies? Would it be possible for other apps to pull in the same dependency for their own app without messing up with our framework's dependency?
I had the same problem as @brunobasas. The solution approach with @_implementationOnly helped me. But i had an additional problem where a file was created at runtime which defined public classes and methods and didn't use @_implementationOnly. With two additional lines in the shell script, I adjusted this file and now it works fine.
If it adds any context to this topic, we weren't able to successfully include an XCFramework with the @_implementationOnly imports if the client app uses the same dependency. We're getting
Class XXX is implemented in both A and B. One of the two will be used. Which one is undefined runtime errors, here is a straightforward sample that replicates this issue: [SR-14752] Receiving runtime warnings about duplicated dependencies while trying to integrate framework with @_implementationOnly imports Issue #4414 apple/swift-package-manager GitHub.