I have a VCL application built in C++Builder 10.0 Seattle. It uses Axis Media Control on the Form to display video, therefore it loads the AxisMediaControl.dll file when it runs.
In the past, I have had this deployed on a 32bit target machine, where the application lived in the C:\Program Files\AppName directory, and the AxisMediaControl.dll was installed to this same location. Everything worked as expected.
This application is a 32 bit application, so when deploying to a 64 bit target machine, it is installed in the C:\Program File (x86)\AppName directory. Once again, the AxisMediaControl.dll file is deployed in the application directory.
The app fails to launch with the error "The specified module could not be found". Using Process Monitor, I found the program is looking for the Axis DLL in the older Program Files directory instead of the x86 dir. What would cause the application to look for the DLL in that location?
Running the same binary on my dev machine, the application loads the DLL from my SysWOW64 directory. If the DLL is placed there on the target machine, it still fails to look in that location. It is ONLY looking in the older Program Files application path, which I cannot understand.
I'm hoping someone can shed some light.
Related
What works in normal desktop application
When we try to load a dll from a normal desktop application the system automatically checks the directories specified in the environment variable "PATH" and finally, the dll is found. E.g. we are using NVidia CUDA dlls this way.
What doesn't work when application is packed into MSIX?
When we pack this application into MSIX the dlls can't be found any more, because the packed application doesn't check the folders specified in the environment variable "PATH".
In some cases a workaround would be to load the dll dynamically from code, but it only works when the dll has no dependencies. Otherwise the loaded dll is not able to find it's dependecies.
What's the recommended approach to load the dlls to which path is defined in environment variable "path" from MSIX packed application?
Platform: Windows 10/11
Language: .NET/C#
How do you know the DLLs are not found when packaged as MSIX? Are you debugging the app with Visual Studio or using Process Monitor?
From what I know an application packaged as MSIX should still be able to load resources from folders listed under PATH env var. An MSIX package cannot write in the PATH env var, but the application it installs should be able to read it.
A known problem with loading DLLs from MSIX packages is when the DLLs are in a different folder from the one where the EXE loading is found. But this applies only to DLLs that you deploy inside your package, not DLLs installed by other applications on the machine.
The role of the MSIX container is to isolate the resources from the MSIX package (restrict other applications from accessing them), but the application deployed via an MSIX should be able to "see" all the resources present on the machine (installed by other non-MSIX packages), just like any other application.
Have a VB.Net app wherein I am trying to call klist.exe to purge cached Kerberos tickets.
Dim klist As New ProcessStartInfo("C:\Windows\System32\klist.exe")
klist.Arguments = "purge"
Process.Start(klist)
Debugger spits out:
System.ComponentModel.Win32Exception: 'The system cannot find the file specified'
The file clearly exists, and can be run without elevated permissions from a command prompt.
What kind of tomfoolery is this? Or am I so tired I'm missing something obvious?
On a 64bit machine, the files in c:\windows\system32 are 64bit files and the files in c:\windows\SysWOW64 are 32bit files (yeah.. I know what you're going to say). A background redirection in the OS ensures that 32bit programs that try to access c:\windows\system32 are redirected to c:\windows\syswow64 so they can find the 32bit files they think they want out of system32. Given that klist.exe is in system32 and hence 64bit (for me at least, ymmv), your app not finding it means it's likely it is 32bit and being redirected to the syswow64 folder, which doesn't contain klist.exe. Your console session, on the other hand, doesn't have this bitness problem and is using the system32 folder/finding klist.exe
Set your app to be 64bit; set the Target CPU to x64 or make it AnyCPU and turn off the "Prefer 32bit" tickbox
I have a VB6 app that utilizes a non-activeX DLL (non-registering).
It's declared via the classic Public Declare Function "Function Name" Lib "Library.DLL" syntax.
On my dev machine (XP) it works fine but when I deploy to Vista or Win7 I'm constantly greeted with a Run Time Error 48 - File Not Found for the DLL in question.
I have tried copying that DLL to every directory I can think of including every environment path on the test machine and the app path too.
These are all 32-bit test environments so it's not a SysWow64 issue.
Possibly throwing a wrench into the mix is the fact that the application in question is an Outlook COM Addin.
I managed to install VB6 on Win7 and was able to run a tiny sample app that utilizes this DLL (outside of the Outlook process) so I know it works PROVIDED the DLL is located in App path. If I call App.Path from my DLL when I run it on the test environment it shows, to no surprise, my installation directory however the DLL is there.
I tried turning off UAC. I tried making the App.Path directory permissions open to everyone, still no dice.
According to the details you give, it looks like placing the DLL in the path of standard Add-in locations would help.
I believe the first place a DLL search looks is the directory that the EXE loaded from, so your DLL's App.Path won't be used.
Are you sure that you tried installing this DLL into System32? Into Windows?
Aside from that you should be ble to create a PATH (messy) or an isolation manifest for the calling code (VB6 if I'm following you) that specifies DLL Redirection to a relative path (i.e. a subfolder under the folder with your VB6 code in it).
See Dynamic-Link Library Search Order
You may want to check the DLL's own dependancies. You will get the same error if it couldn't load the DLL in question or some DLL 20 levels deep in the dependancy chain.
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.
So I created a cab file in Visual Studio and it all was fine and dandy. i am using HP thin client with WinCE 4.0
One thing though, there is a folder called Program Files on My Device and there is a folder called Program Files on Hard Disk.
Now, My Device memory resets itself each time the machine is rebooted.
Unfortunately, VS 2008 won't let me change the path for where the cab installs the program.
Any ideas on how to change the path?
I have figured it out: any time you wish to install an application in a different path, use Custom folder, not Programs or Program Files.
Looks like InstallDir can not be modified w/o hacks. I used Custom folder while in the Cab project and specified the path I wish to install this app; it worked.