Packaging Program
in [Visual Studio]
|
From: WebBiz on 5 Oct 2006 11:46 "mayayana" <mayaXXyana1a(a)mindXXspring.com> wrote in message news:JY_Ug.5123$Y24.4791(a)newsread4.news.pas.earthlink.net... > >> >> How do I figure out what 'versions' to ship? I write the programs on my >> XP >> Home system. When done and ready to package, I don't know what files >> Win98 >> can or cannot run. What tells me that I wrote my program with a version > that >> is too high for other systems? >> > > I think it's the responsibility of the programmer to > research that. You're asking people to trust your > installer. You should know what's in it and why. > Especially if you're writing on XP, since that means > many of your system files won't be compatible with > Win9x. > > If you've installed VB/VS service packs, a lot of > what's in those is updates for files as a result of > problems that have occurred over time. The PDW will > take files from the folder Wizards\PDWizard\Redist, if > they're there, rather than from the XP system folder. > For instance, with the VC6 runtime, MSVCRT.DLL, the > version to ship is 6.00.8397.0. (Though as Steve Gerrard > said, very few people will need that file.) If you can cut out > whatever you're using in SCRRUN.DLL then the PDW > probably will also drop MSVCRT.DLL from the list. > > In the case of SCRRUN.DLL, the current version > is 5.6, but I think that 5.1 is probably the one to ship. > V. 5.1 is almost the same as 5.6, but v. 5.6 ships differently > for Win9x vs. WinNT. ...That's the kind of thing I mean that > you should know - that MSVCRT.DLL is a dependency of > SCRRUN.DLL and that there might be problems shipping > v. 5.6 of SCRRUN.DLL. ...And also that you're using something > in that (FileSystemObject? Dictionary?) that, if you can eliminate > that need, should remove two of your dependencies. > >> comdlg32.dll - I think that's wrong. If you're using a common > dialogue control you need comdlg32.ocx, but not the DLL. > >> comdlg32.ocx >> fmtkit32.dll >> igtabs40.ocx >> igtoolbars50.ocx >> mscomctl.ocx > >> msvbvm50.dll - Why this? You've already got the VB6 > runtime listed. It's VB6 software? Maybe you've declared > something from MSVBVM50 that could have been declared > from MSVBVM60.DLL? > >> msvcrt.dll >> scrrun.dll - Maybe you can dump these. See if you really > need to use the FileSystemObject. > >> VB6 Runtime and OLE Automation. >> > >> As for a packaging program, what do you find to be really, really good >> and >> easy to use? >> > > That's up to you. A lot of people really like Inno. I like > to use the PDW. I've rewritten the code for my > own use and I can now make fully customized > installs with my own graphics, an EULA clickthrough, > desktop shortcuts, etc. I also shrank the size of it down > by quite a bit. (The Setup1.exe project comes with > VB. Setup1.exe is the PDW installer. So you can > write your own installer if you want to. See here for samples: > http://www.jsware.net/jsware/vbcode.php3 ) > > A lot of people complain about the PDW, but it works fine > as long as you're not shipping newer versions of > protected files. SCRRUN.DLL is a good example of > that. It's pre-installed on 2000/XP and probably on > WinME. Those systems won't let you overwrite it. > So you should ship the oldest version that you need to > do the job on Win98. That way the pre-installed versions > on 2000/XP will be newer and therefore your installer, > whatever you use, won't try to overwrite on those > systems. But you'll still have it there in case it's needed > on Win98. > > Using the PDW offers potentially more control and > customization, but I've never heard anything bad about > Inno from anyone. (Their interface is very bland, but > so is IS and MSI.) The only thing I would never use, > personally, is MSI. It's a breathtaking mess. > Thanks for the heads up on MSI. And yes, INNO has served me well for a few years now, although I'm still learning about it as you can see. The scrrun.dll is referenced because I'm using the function DirectoryExists(). What would be a good alternative? Thanks. Rick
From: WebBiz on 5 Oct 2006 11:49 "Alfie [UK]" <me(a)privacy.net> wrote in message news:3si8i25je8bb6id01h15kmlngsboi6ael8(a)4ax.com... > On Wed, 4 Oct 2006 16:25:30 -0500, "WebBiz" <justask(a)andyouwillget.com> > wrote: > >>1. What do you recommend as a good deployment/packaging program? I'm I >>cool >>with Inno, or is there actually better/easier? >> >>2. Is there an easy way to determine which files I must install with my >>program? Inno requires I know upfront what they are. >> >>3. How do you know whether you should replace the file on the user's >>machine >>if it already exists? Is there Win98 vs. XP file issues? >> >>I want to make sure that all the proper files get loaded onto the machine >>if >>necessary, whether they are using Win98, XP, Win2K, NT, etc. >> > The basic rule to avoid such issues is to build and test on the lowest > level OS that you wish to support, in this case, Win98. Keep a minimal > install Win98 box around for that, or have a dual boot system so you can > use it for testing. > > You can take that a step further by developing on the lowest level OS, > but that's not always necessary if you understand what has changed in > controls, libraries, and APIs (also which library functions, APIs have > been deprecated or changed) under new OS'. For APIs > http://www.allapi.net/ is invaluable, for libraries it's not always > obvious whether full backwards compatibility is available. > > That way you avoid using any new features not supported in older OS', > and when you build, regardless of your packaging software, it will > always use the older versions. When installing, any installer worthy of > the name will not try to 'update' new versions with your packaged old > versions. > > If you build from the lowest version you should only then need to deploy > any custom controls or non-standard controls/libraries that you are > using. > -- > Alfie > <http://www.delphia.co.uk/> > Borrow money from pessimists-they don't expect it back. > Creating deployment packages seems to be more technical and difficult than writing the program to begin with! :-0 Well, guess I should get the old dusty PC in the corner ready for Win98. Thanks Alfi. Rick
From: Alfie [UK] on 5 Oct 2006 13:10 On Thu, 5 Oct 2006 10:49:54 -0500, "WebBiz" <justask(a)andyouwillget.com> wrote: >Creating deployment packages seems to be more technical and difficult than >writing the program to begin with! :-0 > >Well, guess I should get the old dusty PC in the corner ready for Win98. > >Thanks Alfi. > It's one of those things that most (at least those who never faced the same issues supporting 95/98) don't think too much about until it goes wrong :) -- Alfie <http://www.delphia.co.uk/> Law and Order do not always mean Peace and Justice
From: BeastFish on 5 Oct 2006 17:46 "WebBiz" <justask(a)andyouwillget.com> wrote in message news:HN9Vg.20549$2g4.7197(a)dukeread09... > The scrrun.dll is referenced because I'm using the function > DirectoryExists(). > > What would be a good alternative? Depends on what you're using it for. Do you need for it to determine not only if the entity exists but also if the existing entity is in fact a directory and not a file? Regardless, you can make your own function named "DirectoryExists" that uses GetAttr, trapping the error. How robust or flexible you make it is up to you.
From: mayayana on 5 Oct 2006 19:03
> The scrrun.dll is referenced because I'm using the function > DirectoryExists(). > > What would be a good alternative? > I assume you mean FSO.FolderExists. You can use the following. It just so happens that I got it from the PDW code: Public Function FolderExists(ByVal sPath As String) As Boolean On Error Resume Next FolderExists = (GetAttr(sPath) And vbDirectory) = vbDirectory Err.Clear End Function |