How do I generate a single-file installer and web-installer at the same time?

[NewsArchive]

Without having to change settings between each compile?

Paul MacFarlane

[NewsArchive]

Paul,

>
> Without having to change settings between each compile?
>

Please see the following link:

http://www.lindersoft.com/forums/showthread.php?p=73760#post73760

Friedrich

[NewsArchive]

Thank you ....

Just to verify - the "release" uses the same product ID, etc, correct?

The only thing I changes was the installer EXE name (added _FULL)

Paul MacFarlane

[NewsArchive]

Paul,

> Thank you ....
>
> Just to verify - the "release" uses the same product ID, etc, correct?
>
> The only thing I changes was the installer EXE name (added _FULL)

Correct.

The only difference is that the "web-enabled" version compiles into a small
setup.exe loader and cluster files. The "standard" version compiles into a
single-file setup.exe.

Friedrich

[NewsArchive]

Also, the Version file is modified and uploaded with the different EXE
name....

Does that matter to my WebUpdate users? Is a new release going to try
and download the "_full.exe" ?

Basially, the standalone "_full.exe" is rarely going to be used but I
have some people that get errors during webinstall.
I'm sure it's their firewall but I'm not in the business of solving
their firewall problems....ggg

All the files end up on the same server folder.
WebSetup.exe.....WebSetup_01601 and WebSetup_full.exe
Is there a way to prevent the FTP from uploading the Version file?

or other suggested solution?

Paul MacFarlane

[NewsArchive]

Friedrich,

Any ideas about this version file issue?

Paul

[NewsArchive]

Paul,

>
> Any ideas about this version file issue?
>

I'm not quite sure I understand this question, sorry. What is the "version
file" in this case?

The initial install and the web update install are completely different
projects. As I understand it, you compile the very same project as 1)
'single-file' install image and 2) as a 'web-enabled' install image. So the
only difference is the "image type". The contents is the same.

Friedrich

[NewsArchive]

Correct - content the same....

BUT, the WebUpdate "Server Manifest File" changes between the
webinstall versoin and the standalone version.

It's generated for both, one has the normal install, the other has the
_Full.

the last one I do overwrites.....

So, right now my customers will click webUpdate , the Server Manifest
File will be checked, and if they do not have the latest release
WeUpdate will attempt to download the setup.exe references within the
SMF. Right now it's the _FULL install rather than the WebInstall I want
them to use....

Is there any way to:
- override the SFM
- prevent it from being uploaded during FTP when I generate a FULL setup
- or force the EXE value

Paul MacFarlane

[NewsArchive]

Paul,

I read, re-read and read your message again. But I am afraid I still do not
understand :-(

I think your problem is that you are using the same project for the
"initial" install (which makes your app web update ready) and web updates
(to update an existing system)? If this is the case, this is not allowed.
You need two separate projects for the initial install and for web updates.

Or did I misunderstand and have two separate projects for the initial
install and web updates?

You can provide the initial install as single-file -AND- web install images.
But the web update for the app can only be a single-file -OR- a web install
image.

Friedrich

[NewsArchive]

Friedrich,

Correct - one project. WebInstaller, Single-File Installer, and
WebUpdate (which is really just the WebInstaller)

Forever I've used a webinstaller / webupdate capability in the same project.
The same for initial and webupdates. (it was always my understanding
that webinstalls/webupdates only downloaded needed parts)
Documentation: "Configure iDeploy Web Installation" - first 2 paragraphs
say webinstall can function as an update, etc....

I do not do patching......

So, all I needed to do was ADD a single-file initial installer.
So, have it generating now per instructions.
BUT, during the generation of the single-file installer, SB re-writes
the Server Manifest File.

Right now I'm generating MyAppSetup_full.exe as a single-file installer
and MyAppSetup.exe & 1600 other files for the WebInstaller.

Generating the WebInstall the Server Manifest File contains a version
number and MyAppSetup.exe.
When I generate the Single-File release the Server Manifest File
contains the version number and MyAppSetup_Full.exe

As I understand it, the WebUpdate checker process downloads the Server
Manifest File.
It compares the versions, reports and new version and if the user
chooses downloads the EXE referenced within it.
Documentation: "Configure iDeploy Web Update" Server Manifest File
description.

So now you are saying my WebUpdate should be a separate project?
This would be a separate set of files on my download server?

So, forgetting the single file issue right now.
I need to create 2 projects - 1 for WebInstall, 1 for WebUpdate.
WebInstall project:
WebDeployment section I put server, directory, etc.
WebUpdate section I need a DIFFERENT directory?

WebUpdate:
WebDeployment section - same info as WebInstall's WebUpdate?
WebUpdate section - blank ?

Then, back to my Server Manifest File issue:
If the INSTALL Project generates MyAppSetup.exe, My UPDATE project also
needs to generate MyAppSetup.exe but stored in a different path on the
server (per WebUpdate section path settings) ????

Then, if I generate a single-file INSTALL, what do I do about WebUpdates?
The Server Manifest File will contain MyAppSetup_Full.exe, not
MyAppSetup.exe Update which is in that separate path.....

It appears I cannot control the NAME of the WebUpdate EXE file - has to
be the same as the initial INSTALL.

So if I have a Single File INSTALL with WebUpdate AND a WebInstall with
WebUpdate, I need basically 4 copies of the install on my server?

SINGLE File Install + SINGLE File WebUpdate
WebInstall + Webinstalls WebUpdate

If I could control the content of the Server Manifest File OR prevent it
from being generated on a certain Release that would solve all this
confusion......

Confused Paul

[NewsArchive]

Paul,

> Correct - one project. WebInstaller, Single-File Installer, and WebUpdate
> (which is really just the WebInstaller)

The initial install (to make the application web update ready) and web
updates are always two different projects. If you are doing it from the
same project then you always overwrite the "initialization" settings when
you do a web update.

http://www.lindersoft.com/forums/showthread.php?t=9459

So in the initial project, "Install Web Update Client" is always turned ON.
In the Web Update projects, this setting is turned OFF.

Friedrich

[NewsArchive]

Okay - but using the same project for both - my users have the same
experience.

So, using the example in the thread above, the webupdate project for v3
is yet a another webupdate project - or the same one?

Also, that example does not use an Initial WebInstall... If it did, the
WebInstall would generate into a WEB folder, correct?
I would need 2 folders on the web server....
"MyApp\WebInstall" (the web install folder for initial install)
"MyApp\WebUpdate" (the WebUpdate folder for Updates)

Is that correct? And the advantage is size of distribution, correct?

okay - BACK to my INITIAL Issue:

If the INSTALL Project generates MyAppSetup.exe - My UPDATE project
needs to be in a separate folder on the server (per above)
generate MyAppSetup.exe but stored in a different path on the server
(per WebUpdate section path settings) ? Correct?

Then, if I generate a single-file INSTALL, I need to point it also to
the separate WebUpdates path?

So I will end up with 2 installs and 1 update:

- Single File INSTALL
- WebInstall
- WebUpdate

Paul MacFarlane

[NewsArchive]

Paul,

You have two install projects:

1) For new installs (which installs the web update programs).
2) For any and all web updates. This does require a versioning system
in your program (the SV shipping templates is one of them, CHT is another).

Web updates are not possible without the new install first. First and
foremost reason is that a GUID is placed in the registry so the wupdate
(and wcheck if you use it) can look up where they are suppose to look
and how. I would imagine when you compile a new install that can do a
web update, that GUID is embedded in the update programs.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Russ,

That's the first I've ever heard of #2 being a requirement. I think
that is mis-information.

I thought SB stored a version in the Registry during installation (along
with the installation location).

My install script has always checked for the location of any previously
installed version (via the GUID) and then used that install location
when installing updates.

"Web updates are not possible without the new install first." Not sure
where you got the idea I was trying to install an update before the
initial install.



Paul

[NewsArchive]

I think you mis-read my post.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Russ,

You said "This does require a versioning system in your program"
I read that as requiring version stamping in the EXE.
NOT true.
What did you mean?

Paul

[NewsArchive]

Version stamping, yes.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Paul,

> Okay - but using the same project for both - my users have the same
> experience.

The first step is to create your "initial" project (to make your app
LiveUpdate-ready). When you have an update available, you create the "web
update" project. You'll then use the same web update project for all future
web updates.

> So, using the example in the thread above, the webupdate project for v3
> is yet a another webupdate project - or the same one?

If you change the version number (e.g. from V2 to V3) then you should create
a new "initial" install and a new "web update" project because the Product
GUID should change if you do a version jump. Similar to Clarion 7 to
Clarion 8 to Clarion 9 or Visual Studio 2008 to Visual Studio 2010 to Visual
Studio 2012. It's always a new Product GUID (that's the standard in
Windows).

> Also, that example does not use an Initial WebInstall... If it did, the
> WebInstall would generate into a WEB folder, correct?

"CoolApp10.sb8" is the initial install project.
"WebUpdate.sb8" is the web update install project.

> I would need 2 folders on the web server....
> "MyApp\WebInstall" (the web install folder for initial install)
> "MyApp\WebUpdate" (the WebUpdate folder for Updates)

No. You can have both located in the same folder (see attached screenshot).

>
> Is that correct? And the advantage is size of distribution, correct?
>

The advantage of a web update with enabled web install capability is that it
only downloads/installs what it needs.

> okay - BACK to my INITIAL Issue:
>
> If the INSTALL Project generates MyAppSetup.exe - My UPDATE project
> needs to be in a separate folder on the server (per above)

No.

> generate MyAppSetup.exe but stored in a different path on the server
> (per WebUpdate section path settings) ? Correct?

No.

> Then, if I generate a single-file INSTALL, I need to point it also to
> the separate WebUpdates path?
>
> So I will end up with 2 installs and 1 update:
>
> - Single File INSTALL
> - WebInstall
> - WebUpdate

If you create an initial single-file install image and an initial WebInstall
image (both images are used to make the app WebUpdate ready) and an
WebUpdate project (to update an existing installation) then you'll end up
with 2 installs and 1 update.

Of course, you can develop your initial installs in such a way that they
also allow updates. Similar to the SetupBuilder install image. You can use
the same image to make the initial install and you can use it to handle
updates (e.g. offline updates). It will then switch into "maintenance mode"
and does an update. It all depends on the deployment logic behind the
project. See attached screenshots.

Friedrich

[NewsArchive]

Thanks Friedrich,

For Major Versions I always create a new project / new GUID.
For minor updates I maintain the same GUID.

Of course, you can develop your initial installs in such a way that they
also allow updates. Similar to the SetupBuilder install image. You can use
the same image to make the initial install and you can use it to handle
updates (e.g. offline updates). It will then switch into "maintenance mode"
and does an update. It all depends on the deployment logic behind the
project. See attached screenshots.

That is essentially what I have been doing. But the users do not get an
"Upgrade or Uninstall" screen. It just detects the location of the
install and updates that... I'll look into maintenance mode.

Paul

[NewsArchive]

Nope.

Paul MacFarlane