We are referencing Serilog Nuget package in our .Net 6 application. Then we use AssemblydependencyResolver.ResolveUnmanagedDllToPath to load the application assembly as plugins. It can't find the kernel32.dll which is refereced via Serialog.Sinks.SystemConsole.
Our questions are:
Is this because Serilog is not supported with Net 6?
Is it a 32bit or 64bit version of kernal32.dll getting loaded from Serilog?
Follow-up for question 2:
When loading 32bit kernel32.dll, we get a bad image format exception, which means our application is 64bit and trying to load a 32bit assembly.
When replacing the 32bit with 64bit kernel32.dll, we get the following error:
Unable to load DLL 'C:\kernel32.dll' or one of its dependencies: The specified procedure could not be found. (0x8007007F) at System.Runtime.InteropServices.NativeLibrary.LoadFromPath(String libraryName, Boolean throwOnError) at System.Runtime.InteropServices.NativeLibrary.Load(String libraryPath)
Related
On my development machine, I have Delphi 10.2 and Firebird 2.5. Database apps that I create in this configuration work correctly.
I copied one program along with its database to another computer running Windows 10. I installed Firebird; I also installed SQL Manager Lite for InterBase/Firebird on this computer, and this program is able to open the database and view the data contained within. But my Delphi program cannot open the database, displaying the error message 'Unable to load dbxfb.dll (error code 193). It may be missing from the system path'.
I have copied dbxfb.dll to every location that I can think of (the same directory as where the program is, the same directory as where the database is, windows\system32, C:\Program Files (x86)\Firebird, and more) but the message stays the same. On my development machine, what I believe to be the path (i.e. system properties\advanced\environment variables) contains only the directory %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. On the other computer, I added C:\Program Files (x86)\Firebird but to no avail.
So where should dbxfb.dll be located, or how do I "tell" my program where to find it?
Edit: Regarding 'bitness', both computers are 64 bit. In the Project Options dialog box in Delphi, there is only the option of 32 bits. I've set the program's compatibility setting to Windows 8, but this made no difference regarding the missing dll.
Further edit: The version that is/was on the target machine is 1,412kb in size and dated 13/11/2015 1:55; this version apparently comes from C:\Program Files (x86)\Embarcadero\Studio\17.0\bin64, so this is definitely the wrong version.
In C:\Program Files (x86)\Embarcadero\Studio\17.0\bin, there is a version that is only 278kb in size, same date but hour 06:55. Copying the smaller file to the target machine and running the program gives now a different error message: i/o error during "#1" operation for file "#2". Error while trying to open file.
https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
ERROR_BAD_EXE_FORMAT
193 (0xC1)
%1 is not a valid Win32 application.
It is indeed the bitness problem as suggested by Mark.
We have developed a DLL in Delphi 10 that we use in some legacy Delphi 6 applications. The new functionality in the DLL is only for a few clients and is therefore not required to roll out to all our clients. If we try to deploy the Delphi 6 application without the DLL we get the error "The code execution cannot proceed because xxx.dll was not found.". We get the error the moment the app starts to run. Is there a way to prevent this error if the DLL does not exist? In our Delphi 6 code we already use FileExists(xxx.dll) to see if we should make the functionality in the DLL available therefore we don't have the risk that the application will crash if the dll is not present.
We would also be keen to learn where/when the Delphi 6 app checks if the DLL exists because it happens before the Application.Initialize, which is the first line of code in the DPR file.
This type of failure is caused by statically (aka : implicitly) linking the DLL. There is no option if you have chosen to use static linking - the DLL must be present on the system trying to run the application.
There are two ways to allow the DLL to be optionally present.
One is to rewrite the affected sections of code to use dynamic linking (aka : explicit ) for your DLLs instead of static linking. For Delphi 6, this is unfortunately your only option.
The other, an option if you are targeting Windows only and if you are compiling with Delphi 2010 or greater, is to use delayed loading by decorating your import declarations with the delayed directive:
function GetSomething: Integer; external 'somelibrary.dll' delayed;
This is really just syntactic sugar resting on top of what is otherwise dynamic loading, but it does provide an easier path to migrate statically linked code to a dynamic linked model without needing an extensive rewrite.
From Embarcadero :
The delayed directive is useful in the case where the imported routines do not exist on the target operating system on which the application is run. Statically imported routines require that the operating system find and load the library when the application is started. If the routine is not found in the loaded library, or the library does not exist, the Operating System halts the execution of the application. Using the delayed directive enables you to check, at run time, whether the Operating System supports the required APIs; only then you can call the imported routines.
Note: Trying to call a delayed routine that cannot be resolved results in a run-time error (or an exception, if the SysUtils unit is loaded).
In either case, delayed or dynamic loading, you would need to catch the failure to resolve the DLL and gracefully deny users access to whatever functions the DLL provides.
I am using the TMS FMX Cloud Pack. Throughout their code is liberally sprinkled FMX.Forms (and FMX.Dialogs which uses FMX.Forms). I currently use these libraries in a VCL DLL successfully.
My initial testing shows that, if I have FMX.Forms in the Uses clause of a DYLIB, the host application flashes in the MAC task bar and the application fails to start (I suspect because the DYLIB fails to load).
EDIT: I get this error when running from the Windows IDE through PAServer (I get no error when running from Finder on the MAC VM):
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist'
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.60.1/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist'
Runtime error 230 at 0015EA03
The simple test application is here: Working HOST/DYLIB application. If I simply add FMX.Forms to the uses clause I get the behaviour above.
Question 1: Is this expected behaviour?
Question 2: Is there a workaround (without removing FMX.Forms - since I use the TMS FMX Cloud Pack third party libraries)?
EDIT:
This appear to be the manifestation of this error "Unable to register class TFMXApplicationDelegate" when the application is run on a Physical Machine. The "Runtime Error 230" is what I get When I run the application within a Parallels macOS VM.
Regardless, the workaround to the "Unable to register class TFMXApplicationDelegate" issue is to NOT use FMX.Forms (or any unit that uses FMX.Forms in a DYLIB. All well and good, except that I am using (extensively) the TMS FMX Cloud Pack which uses FMX.Forms and FMX.Dialogs (which contains FMX.Forms) white liberally. Me trying to take out FMX.Forms etc from their code seems overly ambitious and, quite frankly, is getting to the point of why we buy third party libraries in the first place. If the just don't work, then they probably should not be used. And yes, I have emailed the Vendor.
But if anyone has any ideas how this might be resolved so that I can indeed use FMX.Forms in a DYLIB then please let me know.
We're using the chromium browser component https://github.com/hgourvest/dcef3 in our application. We recently updated this and today found out that it gives an access violation when running on Windows 2008 machines and older.
This AV happens as soon as you start the application. The part where this component is used, is only a small part of the application.
I hoped a solution would be to load that package at runtime instead of design time, but the option to dynamically link runtime packages seems to be an all-or-nothing decising. We want to keep all our other packages internally in the exe.
What would be a solution for this? Is there a way of telling Delphi it should only load that package when needed? That way the users running on Windows 2008 servers can continue to use the other parts of the application.
You can dynamically load the packages like a DLL. You can't use RTTI, but you can load and execute procedures from the Package.
You can load a package with code like this:
H := LoadPackage('RESTAS.BPL');
And access methods with code like this:
#resta := GetProcAddress(H, 'Resta');
Similar to a DLL.
Here you have a complete explanation related with packages load (BPL's) and libraries (DLL's) in delphi, with different configuractions (with and without runtime packages). It's in spanish, but you can use automathic translation and see code and download samples.
I am using dynamic PDF in my .net project to get .PDF and to send it for printing
My code is failing at the below line with the error message
eTe.DynamicPDF.Printing.DocumentLoadException: File not found or could not be opened.
at ceTe.DynamicPDF.Printing.InputPdf..ctor(Byte[] data)
pdfs.Add(new InputPdf(ms.ToArray()));
where ms is a memorystream.
In my dev environment the dynamic pdf used in for X86 based processor. ie
ceTe.DynamicPDF.Printing.40.x86.dll.
Now in production environment the processor is x64.
Is the differnece in the dll cause the above error?
Also Can anyone help me to get link for DLL?
ceTe.DynamicPDF.Printing.40.x64
I work for ceTe Software, the company that develops DynamicPDF libraries.
The dll you would need to use depends on the .NET version and the target platform (x86 or x64) of your application. Refer to the following documentation link on the dlls provided for PrintManager. If you are using ceTe.DynamicPDF.Printing.40.x86.dll and compiling your application as 32-bit, then you should be able to use that application on both x86 and x64 machines.
The difference in the dll (x86 or x64) should not cause this type of error. This type of error is usually caused when there is some issue with the PDF document that you are trying to print. Try printing the PDF that worked on your dev machine on production and see if that works. Also, I recommend that you download the most up to date build of PrintManager available and see if it resolves the issue. If you are a licensed user, download it from the customer area by logging in with you serial number. If you are still evaluating the product and do not have a serial number, you can access the download here.
If the issue is not resolved even after you try the latest build, please email to our support team and include the following information - full exception message (including the stack trace), a copy of the PDF, code to reproduce the error & version info of the PrintManager dll you are using.