Web Deploy / Web Update

[NewsArchive]

It seems that I read and read and still do not get this straight.

Do the Web Deploy and Web Update work off of two different folders on the
internet server?

Thanks,

Michael

[NewsArchive]

Michael,

Web Installation (project1.sb6) and Web Update (project2.sb6, to update
project1.sb6) can be located in the same folder.

1) You install your full product (standard or Web Install) that also
initializes the web update features. This copies all files, creates
shortucts, adds your product to the Add/Remove Programs Panel, etc.

2) Some hours, days, weeks or months later you have an update available.
You now create a web update package (includes only what changed). It does
not create Add/Remove Programs Panel entries, etc.

Does this help?

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I think what he's asking is when you deploy the webupdate, is that put in a
different folder that the webinstall?
This has always been a muddy area for me too...

So, essentially, when you release an update, you need to have 2 SB
projects....

1. WebInstall (full install) for new installs: Lets say it's in the
'webinstall' folder on our server.
2. WebUpdate (just updates): It's in the 'webupdate' folder on our
server....

The WebInstallProject:
In the web section of the SB project settings you need to set the folders
according to the above settings.
The 'Installer' (MyProject.exe) looks in the webinstall folder for it's
files.
The WebUpdate.exe that is installed by WenInstall looks for MyProject.exe?
in the WebUpdate folder?

The WebUpdateProject:
In the web section do we only include WebUpdate info?
The EXE created is a webupdate - not a full install?
The files included in this project are patch files?

How is version information coordinated between the projects? Manually?

paul macfarlane

[NewsArchive]

Thanks Paul,

For some reason the documentation is just not clear to me still after
reading it numerous times.

Michael Brooks

[NewsArchive]

Hi Friedrich,

> Does this help?

Well...not really. For some reason I think the documentation doesn't say it
all.

It seems to give the "details" of what to do but doesn't give me the overall
picture
so I KNOW without question how it operates. When I deploy this to 8,000
users
I need to be certain I know just what is happening.

For instance, if I use the same directory will it contain a complete set of
files to do a
web install, a complete set of files for a web update? And how are patches
handles.

I think you need to write up a more general and qualitative description. And
one I understand
it I would be happy to write it....both to have you read to see if I've got
it right and also perhaps
to add to the docs to help others.

But, of course, it is a superior product in all ways!

Mike

[NewsArchive]

> It seems to give the "details" of what to do but doesn't give me the
> overall picture
I think I can relate to that. I know that Friedrich has put a lot of work
into the documentation, but yet I have the same feeling when it comes to
certain topics, for example "serial numbers". Maybe an overview section or a
"cook book/how-to" with a more conceptual or practical approach would help
clarify.

Peter

[NewsArchive]

Yes...he has put a lot of work into the documentation! I too share the
feeling
with serial number as well (but he cleared it up for me a while ago).

Friedrich is also #1 on my list of great tech support. He has helped me via
private
email amny times and always is gracious and helps till I am satisfied.
I can't imagine how many others he has donethis for.

It is only because I passionately want this functionality to be working
perfectly to
relieve me of huge headaches that I want to figure it out so badly!

I just scanned the last 6 months of newsgroup listings and read many topics
of
on the web update topic and am slowly getting a better handle on it.

I think the critical one was the File | New | Web Update Project
functionality
that build the update script automatically and then using the Project | Task
Automation |
Perform Auto Update Scan. I have not used these yet but will do so shortly.

Mike

[NewsArchive]

Mike,

There are two cycles of tasks that you perform when using Web Update to
perform periodic updates over the Internet:

1) Initial Deployment
2) Web Update Deployment

Once you have performed the Initial Deployment steps for your application,
each time you want to distribute an update of that application to your
customers, you perform the Web Update Deployment cycle of steps.

Example:

- Initial Deployment -

You create your "version 1.00" standard installation. This installs all
files, creates shortcuts, creates registry keys and values, etc. And it
makes your application "live update ready" by installing the wupdate.exe
client.

Let us assume, your product installs the following files (killerapp.sb6):

killerapp.exe [version 1.00]
killerapp.dll [version 1.00]
servive01.dll [version 1.00]
servive02.dll [version 1.00]
servive03.dll [version 1.00]
servive04.dll [version 1.00]
servive05.dll [version 1.00]
servive06.dll [version 1.00]
servive07.dll [version 1.00]
servive08.dll [version 1.00]
servive09.dll [version 1.00]
servive10.dll [version 1.00]
wupdate.exe

You now distribute that install to 8,000 happy customers.

If the customers "check for updates", the message "You already have the most
recent version of KillerApp on your system" displays.

Ten minutes later, you get an urgent call from one of your customers because
there is a showstopper in your application. You fix the bug and that
changes the following two files:

killerapp.exe [version 1.01]
servive05.dll [version 1.01]

- Web Update Deployment -

What you do now is to create your web update project (update.sb6). There
are several different ways to create such a web update project, but let us
use the "Web Update Project" wizard (File | New.. | Web Update Project...).
The wizard will automatically set all relevant information. You only have
to increase the version number from 1.00 to 1.01. That's it!

You now have an empty web update project. Now we fill it with life. You
have again several options to do this because *all* functions are available
in a web update. You can modify the registry, you can remove files,
register file extensions, post messages to your server, etc. What we do now
is to let the "Auto Update Scan" (Task Automation | Perform Auto Update
Scan...) do the dirty work for us.

For example, you have the following directory structure on your development
machine (holds all application files):

c:\development\killerapp\ver100 (holds all version 1.00 files and folders)
c:\development\killerapp\ver101 (holds all version 1.01 files and folders)

Now you point "Auto Update Scan" to the "Previous Version Folder" (\ver100)
and to the "New Version Folder" (\ver101). The wizard scans through the
folders and displays all new or changed files (and folders).

In our case, it detects and displays the following:

c:\development\killerapp\ver101\killerapp.exe
c:\development\killerapp\ver101\servive05.dll

By default, all changes are selected. Press Next and mark the "Support
Delayed File Install" option in the next screen. This option makes sure
that all files are downloaded from your web server before they are updated.
Unreliable Internet connections will not cause problems.

Compile the script and upload all files located in your \Web project folder
to your web server.

For example:

update.exe
update.00001
update.00002
killerapp.ini

If the customers "check for updates", the message "There is a newer version
of KillerApp available than the one currently installed on your system"
displays. If they click Next, the update is applied.

If the customers again "check for updates", the message "You already have
the most recent version of KillerApp on your system" displays.

Does this help?

Friedrich

Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Peter,

SetupBuilder's built-in Serial-Number-Key Protection feature allows
developers to add serial number functionality to the installer.

Let us assume, you expect to sell your product to 10,000 customers and you
would like to protect your installation with a unique serial number.

Implementing the serial number feature is a two-step process.

1) Create the list of serial numbers
2) Add serial number verification to your installer

Example:

- Create the list of serial numbers -

You would like to upload a list of 10,000 serial numbers to your eCommerce
system (e.g. eSellerate) or to your own ordering system. Start the
"Serial Number Key Wizard" (Tools | Create Serial Number List). By default,
you see a "Unique Serial Number Generation ID".

For example: {FBF378E0-CF10-11DB-3D6C-110D5A554AE1}

You can leave it as it is or enter your own ID.

For example: PeterHermansenTopSecretSerialNumberKeyCode

To generate a list of 10,000 serial numbers, enter 10,000 in the "Ending
Serial Number" field and press Next. This will generate 10,000 serial
numbers.

- Add serial number verification to your installer -

Add a "User Info" dialog to your installation. Open the dialog properties
and in the Serial Number tab, enter the information from Step 1.

For example:

Serial Number ID : PeterHermansenTopSecretSerialNumberKeyCode
Starting Serial Number : 1
Ending Serial Number : 10,000

That's it ;-) Your installer is now serial number protected.

Does this help?

Friedrich

Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

Yes, that helps very much!


Two questions
Just to be sure...

(1) For the "Web Update Deployment" you mention uploading the files to the
"Web" directory.
For "Initial Deployment" is it BETTER to use a separate directory on the
server, say "Initial Install" ??

(2) For the SECOND "Web Update Deployment, are the files created by the
second web update deployment build uploaded to the same "Web" directory on
the server...thus perhaps erasing files of the same name from the prior web
update?

(3) I will be reading about Delta Patches shortly. How does this technique
fit into the scenarios?

THANK YOU!!!!!

Michael

[NewsArchive]

Hi Michael,

> Yes, that helps very much!
>
>
> Two questions
> Just to be sure...
>
> (1) For the "Web Update Deployment" you mention uploading the files to the
> "Web" directory.
> For "Initial Deployment" is it BETTER to use a separate directory on the
> server, say "Initial Install" ??

I have all the stuff in the same "\SB5" folder on my web server (SB5 full
and web updates *and* SB6 full and web updates). As long as the full
install and the web updates do no not have the same file name, no problem
with that at all.

> (2) For the SECOND "Web Update Deployment, are the files created by the
> second web update deployment build uploaded to the same "Web" directory on
> the server...thus perhaps erasing files of the same name from the prior
> web update?

The SECOND web update replaces the FIRST web update.

Remember, you have this:

**** VERSION 1.00 ****

killerapp.exe [version 1.00]
killerapp.dll [version 1.00]
servive01.dll [version 1.00]
servive02.dll [version 1.00]
servive03.dll [version 1.00]
servive04.dll [version 1.00]
servive05.dll [version 1.00]
servive06.dll [version 1.00]
servive07.dll [version 1.00]
servive08.dll [version 1.00]
servive09.dll [version 1.00]
servive10.dll [version 1.00]
wupdate.exe

**** VERSION 1.01 ****

killerapp.exe [version 1.01]
servive05.dll [version 1.01]

Okay, now you have added cool new features to your application and it is
time to add a new build. This time, you add one file and the following
files change:

killerapp.exe [version 1.02]
servive01.dll [version 1.02]
servive02.dll [version 1.02]
servive11.dll [version 1.02] <-- NEW FILE

If you build a new web update now, it includes the following files:

killerapp.exe [version 1.02]
servive01.dll [version 1.02]
servive02.dll [version 1.02]
servive05.dll [version 1.01] <-- CHANGED IN WEB UPDATE #1
servive11.dll [version 1.02]

You see, you do not include any "unchanged" file!

> (3) I will be reading about Delta Patches shortly. How does this technique
> fit into the scenarios?

This is a good question. SetupBuilder 6 can create multi-version patches.
And web update is the optimal method for multi-version updates because only
what is required is downloaded. But the Auto Update Scan wizard cannot
create such a project for you (at the moment). We are already working on
this and one of the next builds can automatically scan your folders and
create multiple-version patches. Problem is that you have to define all
previous folders and the wizard will then create the auto patch for you.
Very tricky.

To handle this now, you have to manually add the patches to your project.
In our test scenario, you have to add the following previous versions to the
script (File Propetries -> Patch tab):

killerapp.exe [version 1.00]
servive05.dll [version 1.00]
killerapp.exe [version 1.01]
servive05.dll [version 1.01]

You then have a true multi-version web update patch.

Does this help?

Friedrich

Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Friedrich,

This was a great 'tutorial'...<g>

Here's a question for you.....

So, you've got:
KillerApp.exe[1.00] as part of KillerAppSetup
KillerApp.exe[1.01] as part of KillerAppUpdate

When a NEW user comes along to do a new install, they run KillerAppSetup.
Does that mean they will immediately need to run the update too?

Thanks,
Paul

[NewsArchive]

Hi Paul,

What I always do is create a "current" full install everytime I create
an update and upload both to my site. That way new users will download
the latest full install but existing users can keep upgrading. I
suspect that Friedrich does it this way too because whenever he
releases a new build he invariably suggests that you can either "check
for update" OR download the latest full build.

Best Regards,
Geoff Spillane
Data Down Under

[NewsArchive]

Sorry about the late answer.

Yes, it does help! What I was missing is the fact that <all> 10.000 serial
numbers are stored in the installer and that <any> of these will be deemed
good when entered by the end user. Am I correct here?

Peter

[NewsArchive]

Hello Peter,

Yes and No <g>.

Yes - <any> of these (10,000 serial numbers) will be deemed good when
entered by the end user.

No - it does not really store all 10,000 serial numbers in the installer.
For 10,000 serial numbers, this would add an overhead of, say, 120 KB to the
setup.exe binary. Or 100,000 serial numbers would add 1.0 MB of overhead.
SetupBuilder 6 compiles native Win32 executables. The verification logic
for these 10,000 (or 100,000 or 1,000,000, etc.) serial numbers is compiled
into the executable.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder 6
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

OK, you win again <g>, you've got a great product!
BTW, I'm amazed that you also answered the scandinavian ng - how do you do
that?

Peter