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.
Related
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.
I've written a Windows program using the C API of Tcl/Tk to create a nice GUI. I've installed ActiveState ActiveTcl for the dependencies and everything compiles and runs fine. Compiling required me to link against the import libraries provided by ActiveTcl.
Now that i want to distribute this program i have to make a choice on how to handle the dependency on ActiveTcl. One option is to require ActiveTcl be installed before my program, while another is to just distribute the ActiveTcl DLL's that my program actually uses.
If i view my program using a Dependency Walker i can see that three ActiveTcl DLL's are used. tcl86.dll, tk86.dll and zlib1.dll. So then i tried to move the DLL's.
If i moved these DLL's to the C:\Windows folder or to the program's folder, the program no longer functions. After moving the DLL's and viewing the program in the dependency walker, i can see the DLL's are being found in these alternative locations but the program refuses to start. I don't even get an error.
Do any of you guys know why this might be the case? That the only time my program runs is if the DLL's are located in the installation directory of ActiveTcl (C:\Tcl\bin).
The DDL's had dependencies of other files that should exist in the same folder.
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.