After the success of my previous question I thought I would try another, although this one is partly question and partly looking for advice.
I imported an old VB6 project. Mostly this was very successful except for one thing which is questionable, the various system libraries (some ocx) that the project uses are listed in the Application Folder. Some examples are: COMDLG32.OCX, MSCOMMCTL.OCX, MSCOMM32.OCX, RICHTX32.OCX and MSFLXGRD.OCX). I'm a bit hazy about this but I think that some of these should not normally be installed (because they are specific to the version of Windows in use). So here's a few questions:
1. Are there any of these you wouldn't install but instead expect them always to be there already?
2. Would you install them in the Application Folder where Advanced Installer seems to have chosen to put them? (the application would use them from there Ok as it already has a .local file for other dll's) but they may not fit with the users Windows??? Sheesh I wish I knew more about this!
3. I'm really unsure about these files, I don't understand why Advanced Installer is listing them for the Application Folder when I would normally expect them to be in SYSWOW64. Any clarification on this welcome.
Many thanks for any help on this.
Ian
EDIT: Does this have something to do with the "COM" feature which I see available on the PRO version? If so, could someone please explain exactly what this feature does? Thanks
Suggested Articles
Re: System Libraries
Hello Ian,
I am not so sure but some of the related OCX file could be indeed modules that come with the OS and in that case your assumption is right: you should not include them into your setup package. They could have been wrongly imported by our Import feature indeed.
To find out if they are part of the system modules you can proceed like this:
1. go to "Files and Folders" page and right click on your application executable file, choose the "Add Dependencies" option
2. check the "Show system modules" option and check if any one of related OCX files are listed as system modules; if so then you can later on manually remove them from "Files and Folders" page
3. repeat the above steps for all of your app executable files
Hope this helps.
All the best,
Daniel
I am not so sure but some of the related OCX file could be indeed modules that come with the OS and in that case your assumption is right: you should not include them into your setup package. They could have been wrongly imported by our Import feature indeed.
To find out if they are part of the system modules you can proceed like this:
1. go to "Files and Folders" page and right click on your application executable file, choose the "Add Dependencies" option
2. check the "Show system modules" option and check if any one of related OCX files are listed as system modules; if so then you can later on manually remove them from "Files and Folders" page
3. repeat the above steps for all of your app executable files
Hope this helps.
Most likely not, our "COM" feature consist of dedicated support to register COM DLL modules written by our customers.EDIT: Does this have something to do with the "COM" feature which I see available on the PRO version? If so, could someone please explain exactly what this feature does? Thanks
All the best,
Daniel
Re: System Libraries
Thank you Daniel, that is very helpful.
Ian
Ian
Re: System Libraries
Sorry for the double post.
Daniel,
I just tried your suggestion about checking Dependencies, the "Add Dependencies" screen appears but is empty and I don't understand why because it clearly has some (at least the vb6 runtime libraries but there are definitely others).
Ian
Daniel,
I just tried your suggestion about checking Dependencies, the "Add Dependencies" screen appears but is empty and I don't understand why because it clearly has some (at least the vb6 runtime libraries but there are definitely others).
Ian
Re: System Libraries
Hello Ian,
This is strange. To further investigate this we would need your VS solution files or a small sample solution which replicates the issue.
Could you send us by email to support at advancedinstaller dot com your entire VS SLN or a small sample SLN which we can use to replicate the behavior?
All the best,
Daniel
This is strange. To further investigate this we would need your VS solution files or a small sample solution which replicates the issue.
Could you send us by email to support at advancedinstaller dot com your entire VS SLN or a small sample SLN which we can use to replicate the behavior?
All the best,
Daniel