I am looking for a user-friendly Windows installer for deployment of a Windows Forms Application I developed in Visual Basic under VS2010. My solution file currently consists of two projects, my main application and a working Setup & Deployment project. The current setup & deployment project seems to work, but the installer it generates is quite spartan and I understand that Setup and Deploy projects will not be supported in future versions of Visual Studio.
So I downloaded the trial version of Advanced Installer and created an .aip project based on an import of my current Setup & Deploy project. The first problem I noticed was that the Deployment Package Folder path was composed with double backslashes (\\) which threw an "Invalid folder path" error so I deleted the extra backslash and no longer throw this error.
A somewhat more perplexing problem concerns referenced assemblies. In the Visual Studio IDE, most of my dll references are stored in the folder "/dll_lib" which is immediately below my main application directory, but the AI import process apparently composes a source path for assemblies based on the main application directory. As a result, the list of assemblies under AI > Resources > Files and Folders is using an incorrect source path. Is there a way to globally change the default path for these dlls?
Also, I'm not sure about the naming or custom processing of these dlls. For example, AI lists my first assembly as AcroPDF.dll, but the project references I have in Visual Studio are Interop.AcroPDFLib.dll and AxInterop.AcroPDFLib.dll. How are these files related and do I need to do any custom processing to generate a PIA (and what is a PIA?).
I'm really hoping that Advanced Installer will work for my situation. Thanks for any assistance.
Suggested Articles
Re: AI Evaluation questions: Assembly reference path
Hi,
In this context PIA most likely stands for Primary Interop Assembly.
Regards,
Cosmin
Can you please give me more details about this? What do you mean by "Deployment Package Folder path"?The first problem I noticed was that the Deployment Package Folder path was composed with double backslashes
This is a bug in the import process. Thank you for bringing it to our attention. A bugfix will be included in a future version. A solution is to manually set the correct source path for each file. Another solution is to delete the current files from your project and add them again from the correct locations.In the Visual Studio IDE, most of my dll references are stored in the folder "/dll_lib" which is immediately below my main application directory, but the AI import process apparently composes a source path for assemblies based on the main application directory
This is not really related to the installer. You should know best what dependencies your application has, how they are used and how they need to be installed. Please note that the dependencies shown by both Visual Studio and Advanced Installer are basically suggestions. You should decide which are included in your package and which are not.AI lists my first assembly as AcroPDF.dll, but the project references I have in Visual Studio are Interop.AcroPDFLib.dll and AxInterop.AcroPDFLib.dll. How are these files related and do I need to do any custom processing to generate a PIA (and what is a PIA?).
In this context PIA most likely stands for Primary Interop Assembly.
Regards,
Cosmin
Re: AI Evaluation questions: Assembly reference path
Thanks for the reply, Cosmin.
The double backslashes show up in the output path AI imported from my Visual Studio deployment project. In the context of the AI menu hierarchy, Deployment > Media > Package > Folder, the path composed by the import process is S:\\cds_installer\\DataShareAPS\\Debug\, where it should be S:\cds_installer\DataShareAPS\Debug\. My "S" drive is mapped from a local server.
As for the relationship between the Interop, AxInterop, and other dlls which may be signed or derived from custom processing, I would like to have a better understanding of how these files are created and what they do. I have a lot of application programming experience, but this is my first attempt at building a complex windows installer. I have the feeling that some of the assemblies referenced listed in my Visual Studio project may be redundant, and if so I obviously don't want to deploy them inadvertently.
In reading about assemblies, I remember that the file nomenclature is something like Interop.FileName.dll, AxInterop.FileName.dll, and FileName.dll, with some of the files being managed wrappers for unmanaged COM modules, but I don't know which file is which. I also don't know about specifying a custom tool to sign or wrap these references, or whether specific files should be embedded into my own application code. I would like to have a better handle on these concepts before deploying my application to the general public.
I probably should have started this thread in the Building Installers forum since it is primarily a beginner questions, but I am currently evaluating AI along with Setup Factory (Indigo Rose) which appears to take a simpler (and proprietary) approach to building an installer. My current assessment is that AI may have more features, is msi compliant, and is more flexible, but AI is also more complicated. Please feel free to move this thread the the Building Installers forum if it is more appropriate.
At this point, I am just trying to climb the learning curve sufficiently to make an informed purchase decision. Thanks again for your help.
The double backslashes show up in the output path AI imported from my Visual Studio deployment project. In the context of the AI menu hierarchy, Deployment > Media > Package > Folder, the path composed by the import process is S:\\cds_installer\\DataShareAPS\\Debug\, where it should be S:\cds_installer\DataShareAPS\Debug\. My "S" drive is mapped from a local server.
As for the relationship between the Interop, AxInterop, and other dlls which may be signed or derived from custom processing, I would like to have a better understanding of how these files are created and what they do. I have a lot of application programming experience, but this is my first attempt at building a complex windows installer. I have the feeling that some of the assemblies referenced listed in my Visual Studio project may be redundant, and if so I obviously don't want to deploy them inadvertently.
In reading about assemblies, I remember that the file nomenclature is something like Interop.FileName.dll, AxInterop.FileName.dll, and FileName.dll, with some of the files being managed wrappers for unmanaged COM modules, but I don't know which file is which. I also don't know about specifying a custom tool to sign or wrap these references, or whether specific files should be embedded into my own application code. I would like to have a better handle on these concepts before deploying my application to the general public.
I probably should have started this thread in the Building Installers forum since it is primarily a beginner questions, but I am currently evaluating AI along with Setup Factory (Indigo Rose) which appears to take a simpler (and proprietary) approach to building an installer. My current assessment is that AI may have more features, is msi compliant, and is more flexible, but AI is also more complicated. Please feel free to move this thread the the Building Installers forum if it is more appropriate.
At this point, I am just trying to climb the learning curve sufficiently to make an informed purchase decision. Thanks again for your help.
Re: AI Evaluation questions: Assembly reference path
Hi,
Regards,
Cosmin
This is a bug in the import process and it will be fixed in a future version. Thank you for bringing it to our attention.The double backslashes show up in the output path AI imported from my Visual Studio deployment project.
I'm afraid that we cannot help with that. We can help only with installer problems, related to the installation process. Understanding application dependencies and how they are deployed is the package developer responsibility.As for the relationship between the Interop, AxInterop, and other dlls which may be signed or derived from custom processing, I would like to have a better understanding of how these files are created and what they do.
Like I mentioned in my previous post, the dependencies shown by both Visual Studio and Advanced Installer are just suggestions. The package developer needs to determine which should be actually included in the package and which should not.I have the feeling that some of the assemblies referenced listed in my Visual Studio project may be redundant
Regards,
Cosmin