SOLVED

Add custom installation in specified directory along with registry entry

Copper Contributor

HI,

I want to register some COM components on the machine along with some other DLL, And want to place those item in other Folder like  c:\ Program Files\FolderName. 

Those extra DLL will be placed in this folder.

 

If i uninstall the application , the other folder and registry entry also removed from the system.

 

Can we achieve  this using MSIX, appx deployment process?

 

4 Replies

@AtulD I believe so.  There is a potential issue depending on how applications are supposed to find the dlls placed in an alternative folder that might not work out of the box, but can be easily addressed.

Thank you @TIMOTHY MANGAN 

 

You are correct but some other applications are dependent on some of the DLL and registry entry and i want to deploy when we installing the app and and i want to remove those registry entry and other folder when uninstalling the application just like MSI work.

 

This can be achieved using InstallShield suit but we can not distribute them with web browser. 

I am looking the solution which can install both from the web browser.

 

Your inputs most welcome.

 

 

best response confirmed by AtulD (Copper Contributor)
Solution

@AtulD OK then!

  • Deploying dll components for use by non-containerized applications outside the container they are delivered in is not supported at this time.
  • Depending on the type of COM registration, those might be available external to the container, and depending on their internal design (i.e. does the software inside the COM require access to package registry once activated) might work.
  • There is the possibility of creating a dependency (or maybe framework, I'm not sure which term applies here) package with shared components. If you look on your system you'll see these for things like .net packages and vcruntime packages. Each package that requires this would need to list it as a dependency in the manifest. 
  • Microsoft has discussed the possibility in the future of defining a group of packages that should run together in a single container, but not provided details or dates (to my knowledge).

Newer is better when it comes to runtime, so stay working with 2004. You'll eventually need to test on back-rev OS due to the COM, but I'd start here.

1 best response

Accepted Solutions
best response confirmed by AtulD (Copper Contributor)
Solution

@AtulD OK then!

  • Deploying dll components for use by non-containerized applications outside the container they are delivered in is not supported at this time.
  • Depending on the type of COM registration, those might be available external to the container, and depending on their internal design (i.e. does the software inside the COM require access to package registry once activated) might work.
  • There is the possibility of creating a dependency (or maybe framework, I'm not sure which term applies here) package with shared components. If you look on your system you'll see these for things like .net packages and vcruntime packages. Each package that requires this would need to list it as a dependency in the manifest. 
  • Microsoft has discussed the possibility in the future of defining a group of packages that should run together in a single container, but not provided details or dates (to my knowledge).

Newer is better when it comes to runtime, so stay working with 2004. You'll eventually need to test on back-rev OS due to the COM, but I'd start here.

View solution in original post