|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Choosing an Installerdistribute our software. We have made numerous modifications to it to meet our requierments, such as adding controls, revising the look and feel, suppressing alerts, adding activation/registration screens, etc. We like it because it is flexible, we ca leverage our VB skills o make it do what we want it to, and it has served us well (for the most part). Not sure how it allows all of that to work without installing the DLLs and OCX's, and our actual APP needs to have the stuff installed to work properly, but somehow, the setup1.exe can operate wothout that stuff installed. We are considering moving to a more modern installer. However, we would still need the ability to "code" the installer like we can with the PDW (in PDW, you can code the setup1.exe and then recompile it). We are especially interested in being able to have the installer be able to read a script that is generated AFTER the main functionality (similar to the setup.lst file, but with perhaps real script such as VBScript or JavaScript), probably in some sort of encrypted file that the installer can decrypt, so we can add functionality after the fact wothout having to go back into the installer and recompile it. We need this because our product enables people to create their own software, and the software they create also needs to be installed - so OUR software needs to be able to write code that the INSTALLER can use in order to facilitate that anything our customers create can be dynamically wrapped into the installer script (if that makes sense). You can download the software from our site to see what I mean if you are not sure what the heck I am talking about: www.atrixware.com - Can anyone recommend an Installer (free, or one that costs money) that has this flexibility, or, comment on other ideas that we might want to consider? Thanks in advance -
Show quote
Hide quote
"Anthony" <Anth***@discussions.microsoft.com> wrote in message Here is a list I stole from Ken Halter ...news:405E8336-B8BB-4893-B82D-D8600C44ABFD@microsoft.com... > We have been using the (VB6) Package and Deployment Wizard for years to > distribute our software. We have made numerous modifications to it to meet > our requierments, such as adding controls, revising the look and feel, > suppressing alerts, adding activation/registration screens, etc. We like it > because it is flexible, we ca leverage our VB skills o make it do what we > want it to, and it has served us well (for the most part). Not sure how it > allows all of that to work without installing the DLLs and OCX's, and our > actual APP needs to have the stuff installed to work properly, but somehow, > the setup1.exe can operate wothout that stuff installed. > > We are considering moving to a more modern installer. However, we would > still need the ability to "code" the installer like we can with the PDW (in > PDW, you can code the setup1.exe and then recompile it). We are especially > interested in being able to have the installer be able to read a script that > is generated AFTER the main functionality (similar to the setup.lst file, but > with perhaps real script such as VBScript or JavaScript), probably in some > sort of encrypted file that the installer can decrypt, so we can add > functionality after the fact wothout having to go back into the installer and > recompile it. We need this because our product enables people to create their > own software, and the software they create also needs to be installed - so > OUR software needs to be able to write code that the INSTALLER can use in > order to facilitate that anything our customers create can be dynamically > wrapped into the installer script (if that makes sense). You can download the > software from our site to see what I mean if you are not sure what the heck I > am talking about: www.atrixware.com - > > Can anyone recommend an Installer (free, or one that costs money) that has > this flexibility, or, comment on other ideas that we might want to consider? > > Thanks in advance - > > > -- > Anthony Dunleavy > www.atrixware.com > Microsoft Visual Studio Installer 1.1 http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx Inno Setup http://www.jrsoftware.org/isinfo.php NSIS (Nullsoft Scriptable Install System) http://nsis.sourceforge.net/home/ "If you want something that's extremely easy (but not free), try the latest version of InstallShield Express. I use version 10 (or "InstallShield X" as they like to call it these days) at home and 3.54 at work." - Ken Halter InstallShield® Windows® Express Edition 11.5 http://www.macrovision.com/products/flexnet_installshield/installshield/editions/express.shtml I too used P&D for years, but it is showing its age with the newer platforms. None of the above will allow you to use your "VB" code, (well not completely true - you can shoe-horn it in), but they all provide such robust 'scripting' ability plus a number of features already built-in that it is possible you won't need or want them anymore. While you can't use your VB code, you can certainly leverage your distribution-builder skills to build some very interesting packages. If you have the bucks - then go with the full-blown versions of InstallShield. The only limitation I have found is the amount of time you want to spend on what is suppose to be a secondary product. You can build installation packages that are prettier, flashier, and more sophisticated than the app you are delivering. <g> -ralph "Anthony" <Anth***@discussions.microsoft.com> wrote in message I use NSIS as it's free, easy to use and has been used by some large news:405E8336-B8BB-4893-B82D-D8600C44ABFD@microsoft.com... > We have been using the (VB6) Package and Deployment Wizard for years to > distribute our software. We have made numerous modifications to it to meet > our requierments, such as adding controls, revising the look and feel, > suppressing alerts, adding activation/registration screens, etc. We like > it > because it is flexible, we ca leverage our VB skills o make it do what we > want it to, and it has served us well (for the most part). Not sure how it > allows all of that to work without installing the DLLs and OCX's, and our > actual APP needs to have the stuff installed to work properly, but > somehow, > the setup1.exe can operate wothout that stuff installed. companies. It has a scripting interface which is quite flexible and it will do all the dialogs you wanted to do but I haven't done custom dialogs so I'm not sure how easy is. I always put these sort of things in the app instead and have them popup when it is first run. That way you've got those dialogs there in the app in case they need to be brought up at a later date (eg user changes registration details). For going beyond the functionality of NSIS it's fairly easy to write addins for it and there are plenty of addins available. One other thing worth mentioning is you need to decide if you want to create an MSI package or an exe package. MSI can be a pita and fairly inflexible and probably won't suit the requirements you mentioned in your post but it does have it's good points I guess. If you want MSI then NSIS won't help you. Michael "Michael C" <nospam@nospam.com> wrote in message I think you mean VSI, as in Visual Studio Installer. MSI is just the news:u9pTn3KQGHA.2668@tk2msftngp13.phx.gbl... > > One other thing worth mentioning is you need to decide if you want to > create an MSI package or an exe package. MSI can be a pita and fairly > inflexible and probably won't suit the requirements you mentioned in your > post but it does have it's good points I guess. If you want MSI then NSIS > won't help you. extension for Windows Installer files. There's nothing inherent in Windows Installer packages that prevents any kind of custom dialog box. You just need the right tool for creating the MSI file. VSI, on the other hand, has an absolutely pitiful selection of dialog boxes you can include in your package. And, as far as I know, there's no way to add your own custom dialog boxes to it. -- Mike Microsoft MVP Visual Basic "MikeD" <nob***@nowhere.edu> wrote in message Correct. and if you use VSI then you need to use Orca for making it do news:uMHuZFLQGHA.3944@tk2msftngp13.phx.gbl... > VSI, on the other hand, has an absolutely pitiful selection of dialog > boxes you can include in your package. And, as far as I know, there's no > way to add your own custom dialog boxes to it. things it can't do natively. (by the way: I use VSI for all my installers as its works for what I need) > > -- > Mike > Microsoft MVP Visual Basic > > -- Chris Hanscom - Microsoft MVP (VB) Veign's Resource Center http://www.veign.com/vrc_main.asp Veign's Blog http://www.veign.com/blog -- "MikeD" <nob***@nowhere.edu> wrote in message No I did mean MSI. I wasn't referring to the custom dialogs when I said it news:uMHuZFLQGHA.3944@tk2msftngp13.phx.gbl... > I think you mean VSI, as in Visual Studio Installer. MSI is just the > extension for Windows Installer files. There's nothing inherent in Windows > Installer packages that prevents any kind of custom dialog box. You just > need the right tool for creating the MSI file. might not suit Anthony's requirements, I was more referring to the way he wanted something that can be scripted. Michael > > I think you mean VSI, as in Visual Studio Installer. MSI is just the I think you're both talking about the same thing. It started> > extension for Windows Installer files. There's nothing inherent in Windows > > Installer packages that prevents any kind of custom dialog box. You just > > need the right tool for creating the MSI file. > > No I did mean MSI. I wasn't referring to the custom dialogs when I said it > might not suit Anthony's requirements, I was more referring to the way he > wanted something that can be scripted. > as Windows Installer and gets called Visual Studio Installer there, but I think they're both the same thing. It's a fully scriptable system through the WindowsInstaller.Installer object, but the object model is horrendous. There are also several versions out now. I think there's been something like 1.0, 1.1, 1.5, 2.0, 3.0, 3.1 for Windows Installer versions, and each version refuses to install a newer versioned MSI package. "mayayana" <mayayanaX***@mindXXspring.com> wrote in message Microsoft Installer (MSI file) and Visual Studio Installer are seperate news:MmPOf.210$k75.208@newsread3.news.atl.earthlink.net... > I think you're both talking about the same thing. It started > as Windows Installer and gets called Visual Studio > Installer there, but I think they're both the same thing. > It's a fully scriptable system through the > WindowsInstaller.Installer object, but the object model > is horrendous. There are also several versions out now. > I think there's been something like 1.0, 1.1, 1.5, 2.0, 3.0, 3.1 > for Windows Installer versions, and each version refuses > to install a newer versioned MSI package. things. VSI is the tool used to *author* an MSI file but you can also use Install Sheild, Wise etc. I'm not exactly sure what "Windows Installer" is but I presume it's just an earlier version of VSI before it was integrated into visual studio. You could have an analogy with help files. The first thing you have to do is decide whether you want a .hlp or a .chm file. Once you decide that then you need to work out what tool you want to use to author the help file with. Show quoteHide quote > >
Show quote
Hide quote
"Michael C" <nospam@nospam.com> wrote in message Windows Installer is not an earlier version of VSI. I'm not sure where news:OHlCbzNQGHA.3924@TK2MSFTNGP14.phx.gbl... > "mayayana" <mayayanaX***@mindXXspring.com> wrote in message > news:MmPOf.210$k75.208@newsread3.news.atl.earthlink.net... >> I think you're both talking about the same thing. It started >> as Windows Installer and gets called Visual Studio >> Installer there, but I think they're both the same thing. >> It's a fully scriptable system through the >> WindowsInstaller.Installer object, but the object model >> is horrendous. There are also several versions out now. >> I think there's been something like 1.0, 1.1, 1.5, 2.0, 3.0, 3.1 >> for Windows Installer versions, and each version refuses >> to install a newer versioned MSI package. > > Microsoft Installer (MSI file) and Visual Studio Installer are seperate > things. VSI is the tool used to *author* an MSI file but you can also use > Install Sheild, Wise etc. I'm not exactly sure what "Windows Installer" is > but I presume it's just an earlier version of VSI before it was integrated > into visual studio. you're coming up with "Microsoft Installer" unless you're just guessing at that from the MSI extension. The file type description for an MSI file is even "Windows Installer Package". Windows Installer is the "feature" built-in to later versions of Windows for "managing" MSI files. It's the technology that VSI, InstallShield, Wise, etc. use to create MSI files. It's fully documented. http://msdn.microsoft.com/library/en-us/msi/setup/windows_installer_start_page.asp -- Mike Microsoft MVP Visual Basic > Microsoft Installer (MSI file) and Visual Studio Installer are seperate Yes, that's what I meant, as MikeD has clarified.> things. VSI is the tool used to *author* an MSI file but you can also use > Install Sheild, Wise etc. I'm not exactly sure what "Windows Installer" is > but I presume it's just an earlier version of VSI before it was integrated > into visual studio. > An MSI is a specialized database installer file, based on a documented object model. You can use VSI, Orca, InstallShield, your own custom vbscript, etc. But in all cases it's editing the MSI database. And more to the point, in all cases it's a product from the Rube Goldberg school of programming, with a lot of unnecessary dependencies and complexities. The only reason I know of that one would choose to use an MSI is because the installation can be managed and documented by network admins through WMI. Since WMI can track installed software - but only if that software is installed via MSI - some network admins may prefer an MSI package. The one nice thing, from an end-user point of view, is that one can fully inspect all files and Registry settings that the installer will be adding before installing the software, because the MSI database is fully "dissectable". "Anthony" <Anth***@discussions.microsoft.com> wrote in message news:405E8336-B8BB-4893-B82D-Show quoteHide quote > We are considering moving to a more modern installer. However, we would I didn't read your message completely at first. I presume you want to > still need the ability to "code" the installer like we can with the PDW > (in > PDW, you can code the setup1.exe and then recompile it). We are especially > interested in being able to have the installer be able to read a script > that > is generated AFTER the main functionality (similar to the setup.lst file, > but > with perhaps real script such as VBScript or JavaScript), probably in some > sort of encrypted file that the installer can decrypt, so we can add > functionality after the fact wothout having to go back into the installer > and > recompile it. We need this because our product enables people to create > their > own software, and the software they create also needs to be installed - so > OUR software needs to be able to write code that the INSTALLER can use in > order to facilitate that anything our customers create can be dynamically > wrapped into the installer script (if that makes sense). You can download > the > software from our site to see what I mean if you are not sure what the > heck I actually create installers on the end users machine? I think NSIS will work for what you want because it is free you can distribute it with your package, then have your package generate the script file and use a command line to compile it. Although I probably shouldn't be telling you this as you look like you might be the competition :-) Michael > Although I probably shouldn't be telling you this as you look like you might What are the odds of that?> be the competition :-) Well, I certainly thank you for helping if we are in fact your competition. I guess I owe you one - although not sure what your product is. You have me curious now ... "Anthony" <Anth***@discussions.microsoft.com> wrote in message I'm in australia so we're probably not the competition. :-) We do news:6C07E911-CA39-4F7F-9E75-8E7C0707331E@microsoft.com... >> Although I probably shouldn't be telling you this as you look like you >> might >> be the competition :-) > > What are the odds of that? > > Well, I certainly thank you for helping if we are in fact your > competition. > I guess I owe you one - although not sure what your product is. You have > me > curious now ... timetabling, attendance marking, admin and report marking. Michael |
|||||||||||||||||||||||
Other interesting topics