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.
My application has to use native code in .dll. I have two questions -
(1) How can I configure my jdev to use .dll. where .dll need to be put?
(2) I also have to make an ear/war of the application/project. How can I bundle .dll in such archives?
You just need a way to call a dll from Java code - google and you'll find some examples.
Then add the dll file as a new file into your JDeveloper project and make sure it is included in the deployment profile of the project.
I am nearing deployment time and am at a loss at to which files to package and deploy when the day comes.
Can I just pull out the executable and be done with it? Or do I need the XML docs and vshost files/manifest files?
Also, the DLLs I am using are also accompanied by an XML document inside my /Release/ folder. Do I need those or can I just grab the DLL files?
Thanks.
At minimum, you need EXE + DLLs. If applicable, add a default config file as part of deployment.
You may want to include PDBs to help debugging.
You don't need XMLs.
For the development machine, if you're using all default controls from Visual Studio, you only need the .exe. Just install the targeted framework. If your app is running in .NET framework 4, then you only need to install framework 4 and your .exe alone will run fine. If you're using 3rd party controls, then you need the .DLL in the same folder you have your .exe, usually.
I'm new to WIX installer and would appreciate if someone could help me solve the below issue.We have a web application where we load plugin assembly(non referenced) using reflection and a web deployment project which merges all the assemblies in to a single one. In the webdeployment project file there are couple of lines which generates the "ProjectWebFiles.wix" source file when built.
<PropertyGroup>
...........
<WixDirectoryId>ProjectWebFolder</WixDirectoryId>
<WixComponentGroupId>ProjectWebFiles</WixComponentGroupId>
</PropertyGroup>
We have a WIX installer project which creates msi installer from this wix file and we want the web application project bin folder to have the unreferenced assembly when the application is installed using msi.
One solution is we could add the project as a static reference to the web project but we want to keep that as a last option since we have to build the web project everytime the plugin project is modified.
Can this be achieved by modifying the web application deployment project file ?
That is MSBuild syntax, not WiX syntax, so I'm not exactly sure what you are asking for. If you are just trying to get all the files from another project or directory, then take a look at the HeatProject task and/or HeatDirectory task.
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.