Best practice -- application location

[urbanski]

I'm wondering what the consensus is about deploying applications. Currently I have been using Astrum to install the runtime to the program files folder on the users PC. Then I use Astrum to install the application on the C drive, as in C:\Applicationfolder.

I know that I should NOT put the application and the runtime in the same folder and that all the files for the application should be in the same folder.

Am I better off putting the application in the Program Files folder or putting it in its own folder on the C drive?

I know I need to use the installer to install the Runtime onto another computer but is there an advantage to using the installer to put the application on the computer or can I just copy the folder to the other computer?

Thanks for the advice (now and in the past)

Jim

[CALocklin]

Re: Best practice -- application location

My comments. Others may disagree or have other preferences.

Am I better off putting the application in the Program Files folder or putting it in its own folder on the C drive?

Yes. (as in "either way")

I think that's really a matter of personal preference. However, my personal preference is to NOT put them under the Program Files folder for a few reasons. In fact, on my own computer neither A5 nor the applications are on the C: drive. The A5 programs (v1 through v8) are on the D: drive and my applications are all in my E: drive. Whenever possible, only windows system files are on my C: drive. Here are my main reasons for not using the Program Files folder.
- It makes the path names that much longer and harder to read. It can also create problems with expressions in some cases because of the added length.
- For some truly silly reason that I've never fully understood, Microsoft decided to create one of the most commonly used folder names with a space in it. This requires adding quotes around various pathnames. Not a big deal when you know what you are doing but have you ever tried explaining to someone with normal (i.e., *no*) computer capabilities on the phone how to properly type in a full A5 command line in the icon properties? (When they start with, "What do you mean by an 'icon', you know you're in trouble!) The longer it is, the harder it is to get right - then, adding spaces and the required quotes just makes it that much harder. (Oh, silly me - what was I thinking. Customers never have problems with icons.)
- For a generic app, I use one install file and the application is in a folder directly under the runtime. If the runtime is under the Program Files folder, that just makes the whole path to the application that much longer.
- Have you ever tried to open a folder in XP that has lots of folders and files under it? If so, you should have seen a very noticeable delay in getting the folder list. By putting my A5 application under it's own folder, I can get to it a bit faster. (A minor issue but a pet peeve of mine.)

I know I need to use the installer to install the Runtime onto another computer but is there an advantage to using the installer to put the application on the computer or can I just copy the folder to the other computer?

Is "the other computer" on the same network? If so, you will need to do something to get "the other computer" network optimized. Installing the full program on the other computer doesn't really do the job correctly. If you really do want to put the full application on the other computer, it doesn't matter how you copy the files but they can't share data that way. If they are going to share data, they either need to both work from the server files (not very efficient) or the workstations need to be network optimized.

What I did for network installs - intended for generic apps where I often can't be there to do the install - was to create a "workstation install" that is just the runtime with a dummy application by the same name as my real application with one table ("Menus" which is also a table in my real app) and one "form" that just contains one big RTF field that tells the user to navigate to the server, start the application from there, then click the "Update to Server" button that I put on the Maintenance Menu. The "Update to Server" button runs a network optimize. After it's optimized, the real program replaces the dummy program and the same icon that was used to start the dummy program now starts the real program. (I found that non-A5 people didn't have a clue what "network optimize" meant. Some even thought that my program was somehow optimizing their whole network for them. As a result, I changed my button text to say "Update to Server" - it makes more sense to them and they've quit asking so many questions.)

You haven't mentioned whether this is for a generic app or a custom app for one client. For a custom app, I usually put A5 (full or runtime) in one folder and the application in a separate folder (sometimes parallel and sometimes not). As mentioned above, my generic apps are installed directly under the runtime. (Not *with* but "in a folder under".)

The reason for the different installation paths depending on generic vs. custom is in how the install is typically done. For a custom app, I often don't even install A5 myself because the customer already has it. (Not always but frequently.) Also, for a custom app it is not terribly unusual for the customer to create other apps of their own. In these cases, it makes sense to keep A5 separate. However, with a generic app that is typically being distributed to a non-A5 user and with the runtime only, it's much easier for the customer if I just give them one install file that installs both the runtime and the application. That way I can allow them to install it anywhere they want but I still know that both A5 and the app will be together. When the two are installed separately, they each could end up anywhere and (a) they will be harder to find and (b) the setting up of icons gets much more complexerer. In fact, by installing the generic app with one install file, I can create a startup icon with the install file. If they are installed separately, there is either no way to get the icon set up -or- you must force the runtime into a specific folder (which some clients may not like) so the application installer can be set up to build the icon.

Edit: Hmmm, maybe that's a reason to put all apps underneath the A5 program. You could get the path to the A5 executables from the registry and use that to define the install path. It would take a bit more work but it could be done. (I don't personally like the idea of putting multiple apps under the one A5 folder but I can't really think of anything wrong with it.)

You can just copy the data dictionary files when doing application updates (assuming the table structure is not being modified) but in most cases it's much easier to set up A5 to just automatically run a refresh optimize whenever the version number is updated.

By the way, you can install the runtime without an installer (i.e., just copy the files) but you will then have to register the A5_controls.dll and the A5_contexteval.dll files in Windows manually. If you use Astrum, just check the box in the Advanced area to tell it to register those two files. (Something tells me Selwyn said something about not having to register them anymore but I'm not certain. I do know that it works when they are registered.)

FYI: Some developers have commented that allowing the application to be installed anywhere causes problems for installing updates because your installer won't know where to look. Not true if you handle it properly. I use a simple routine that uses Registry.sys_set() to set the "datapath" (the path to the real data files - not the shadow files) every time the application runs. Then Astrum can read that registry value to determine where to install the update - even if the update is being run from a shadowed workstation. Of course, the update installer does not install another runtime - only the new application files - so the location of the runtime is not an issue when just updating the application.

[urbanski]

Re: Best practice -- application location

Thanks for the response.
To answer your question, the application is a custom application that is used across the state by 16 different chairmen, so "the other computer" is a stand alone PC somewhere else and not part of a network.
The data that they need is downloaded from our organization's web site in TXT format and then processed by alpha so that they can use it for their performance events -- schedules, judges forms, etc.
I'm hoping that I can move this setup over to the WAS and eliminate the problem of downloading the TXT file and dealing with it directly but I have MUCH to learn about the WAs
In all of these cases the chairmen are using the runtime.
I have one other application that is used by a small private school for report cards and other data management.
Once again, thanks for the reply.

Jim

[JerryBrightbill]

Re: Best practice -- application location

Be aware that placing your application in the "Program Files" folder in Microsoft Vista will render your application unusable. Vista does not allow write permission to the program folder except in very limited conditions. All writable data must be outside of "Program Files". If you are designing for future implementation, accommodating Vista is a serious concern.

[csda1]

Re: Best practice -- application location

Jim,

One thing I always make sure of in terms of directories is to make all related directories (e.g. all A5 Apps) start from the same main directory. That way if you remove a program, you need only remove that main directory and it's sub folder's. Use all of Alpha 5 directory functions to determine the Program path (EXE), Temp directory (Private), Windows Desktop, A5 Shared, shadow directory, Master database directory, etc. Then use those to build your paths and subdirectories.

One of the things I never do is dump everything into 1 specific directory. Items go into different directories (or sub-directories) based upon their purpose and changeability. E.g. I've seem people install all runtime files (A5 runtime exe) as well as the applications, temp files etc all into the same directory. I always put the program in one, application in another, non-changeable app stuff in another, shadow in another, temporary files for the app in the A5 temp directory. THis makes it much easier for backup and restore, as well as protection against program/app corruption

Jerry,

If that is the case with Vista, what functions do we have now in version 7 that can

• Determine if we are operating under Vista (If A5v7 can't run at all under Vista, then something in A5 Version 8)
• Ascertain a writable directory that corresponds to directories that fit the equivalent directories above (e.g. log-in user, machine specific, program specific for that user, program specific for that machine)

Examples of current directories that I use right now and write to include the a5 exe directory, Addin's install directory, shadow directory, Control Panel Addins, a5 exe's "Shared" directory.

I use all those directories for those items that are centric to the directory's purpose. I suspect this is going to break a lot of other A5 apps as well as mine.

[urbanski]

Re: Best practice -- application location

Jerry,
Thanks for the heads up regarding Vista. I imagine this is being done to prevent malicious code from being attached to program files. I also imagine it will be very disconcerting to users who have functioning applications that will crash once they upgrade to Vista.
I wonder if this is one of the issues that Alpha is dealing with and is causing a delay in the release of the final version.

Jim

[CALocklin]

Re: Best practice -- application location

Jerry,

Cool! I've always hated putting things under the Program Files folder anyway. It makes the path longer (which makes it too long to read in some situations) and adds a blank space that needs to be dealt with when building icons.

It looks like this time my "pet peeve" will turn out to be a real benefit.