So a Windows Application Packaging Project in Visual Studio can have references to multiple projects, which will be included in the package. One of those references/applications then gets defined as the entry point/startup application.
Is it possible to know where the other application in the package is located, so that I can start it from the entry point/startup application?
Hope this makes sense...
I assume you want to programmatically launch your other application, right?
By design, the binaries from an installation folder of an MSIX folder are not directly accessible through their direct path. I know this is how we did it for Win32 applications, but for containerized ones things have changed.
The correct way to run an app, installed by an MSIX package, programmatically or from the command line is with the use of an execution alias. The following article contains more details about how an execution alias works and how you can define it in your package, no matter the tool you use to build the MSIX package.
- App Execution Alias
Also, here is a related question on SO and another similar one.
Related
I've created a "related set" (in the language of MSIX) consisting of a main package and an optional package. Each of these two packages contains standalone applications. When I run the applications that are part of the optional package, I find that they run within their own virtualized file system, separate from the virtualized file system of the main package.
Using the "Invoke-CommandInDesktopPackage" Powershell command, I find that the applications in the optional package should be able to "see" the contents of the virtualized filesystem of the main package, as virtualized (by browsing to the relevant folder under C:\Program Files\WindowsApps); but they seem to also have their own VFS.
Can I force them to run in the same VFS as the main package's apps use, so that they will have the same view of the filesystem and the same view of the Registry?
According to Microsoft they should be running in the same container. Here is an extract from "Optional packages and related set authoring" article:
Optional packages and related sets all run inside the main app's MSIX container.
I haven't built an optional package recently but I will give it a try when I have the chance. It might be a bug in what OS which breaks this shared container (Microsoft had a similar similar bug when modification packages were released).
What Windows version are you testing on?
I am currently working on a java project and i want to generate an installer which can add the program to the windows context menu automatically with maven. I had no luck with the generators i tried, some of them couldn't create windows registry entries (which are needed for the context menu), others were not free (it is only a side project so i don't want to spend money). I am already able to generate a .exe file with all dependencies wrapped inside, so i only need to generate an installer that copies this file to a user specified location, create some config/log folders in appdata (which can also be done by the application on first run) and create some registry entries to enable the context menu. I know java is not the language that installers are used most for, but maybe somebody had a similar use case and can provide some maven plugin that will generate the installer.
Thanks in advance
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I want to run an Installer class during the set-up of a Windows desktop application. The point of the installer is to encrypt the configuration settings for the application using the DataProtectionConfigurationProvider (this must take place on the user's machine).
Executing custom actions seems quite straightforward in the old vdproj projects, but we prefer to use Inno Setup since it works really well and goes nicely in our build environment.
I've looked at the documentation around running other executables etc after the install process but do not see anything that refers to running an Installer class within the application.
You cannot call a .NET code directly from InnoSetup.
Either build a small application that you embed to the installer, extract to a temporary folder during installation and run it.
Or build a .dll and call it from InnoSetup.
See Call C# DLL from Inno Setup with callback
How to run the exe file to other system?
Using VB 6
I copied the exe file to other system, then run that exe file, it not working it showing error
“component comdlg32.ocx or one its dependencies not correctly registered a file is missing or invalid”`
Can any one help me how to avoid this error?
When deploying VB6 applications, you should create a Setup, this will manage the DLL's that the VB6 application depends on. Since it is not enough to just copy the .Exe and .Dll's. You also need to register them.
The creation of the setup is included in the VB6 environment.
You can read this http://support.microsoft.com/kb/830761 which is very comprehensive.
1: http://support.microsoft.com/kb/830761 for more information.
Or if you just want the redistributable files check this kb http://support.microsoft.com/kb/290887
Copy and register the comdlg32.ocx on other system. Link: Fix Missing Comdlg32.ocx Run time Error in Portable apps.
Create an installer for your program.
Unless you are deploying your program to really old versions of Windows (prior to XP), one nice alternative is to create an XCopy package using reg-free COM. This is fairly easy for most simple programs using Make My Manifest though it can be done by hand or using other tools if you invest in a little study.
Even then a formal installer package is usually desireable though, if nothing else to create Start Menu shortcuts and set up application workspace directories.
Keep in mind that even the PDWizard is difficult to use blindly. Packaging and deployment is a topic that requires some learning investment.
Outdated or missing comdlg32.ocx runtime library is causing this error. Here is a copy of comdlg32.ocx (~60 Kb Zip). Download the file to the Desktop and extract the comdlg32.ocx to your the Windows\System32 folder.
Note: If you already have a copy of comdlg32.ocx, backup the existing file to a different folder and delete it from System32 folder.
1. Download comdlg32.zip and save to Desktop.
2. Unzip the file using WinZip or any other utility.
3. Extract comdlg32.ocx to Windows\System32 folder.
4. Type the following command from Start, Run dialog:
regsvr32 %Systemroot%\System32\comdlg32.ocx
Typically a VB 6 app will consist of an .exe some .dll libraries and a config.ini file. The exe is the starting place and it consumes the dll's and config.ini and other resources to run => you have to have all parts in the same directory for the app to run typically called "packaging" an app. E.g. An installer simply ensures that all those files in a packaged app are placed on a users computer in an Windows application directory, and creates a shortcut launch icon so that a user can click the shortcut in the start bar and the app will run.
To "package" your app (put the dll's and exe in the same folder) you can use an Add-In called "Package and Deployment Wizard":
And here is a demo of using it: https://www.youtube.com/watch?v=XT7jaoAiKDo
You can either package and create an installer and package or just create a package:
Now if the Deployment Wizard doesnt show as an add-in on your VB6 Editor Installation, go to editor's program folder and find the tools Tools folder, i.e:
Then you should be able to find the Deployment Wizard there:
Open it to use it.