WebClient Extensions in 9.1C

2001PROGRESS WORLDWIDE

Summer Technical Institute

WebClient Extensions in 9.1C

Bryan MauJune 22, 2001

© 2001, Progress Software CorporationSummer Technical Institute 2001, Bedford MA, USA 2

AgendaAgenda

What’s New in 9.1C Overview Details Migrating from 9.1B Troubleshooting


AgendaAgenda



What’s New in 9.1C?What’s New in 9.1C?

New “IntelliStream” technology for app:– Don’t have to download whole app front

end at once (“at startup” components vs “as needed”)

– Faster, smaller updates (new update paradigms possible!)

– Download app code through AppServer pipe

– Digitally signed apps– Assembler tool for application deployer


What’s New in 9.1CWhat’s New in 9.1C

Ease of use for ISV:– Easier for ISV to prepare app for WebClient

deployment

– InstallShield no longer necessary



What’s new architecturally?– WebClient Assembler replaces

PROWCAPP Editor -- new, central tool for ISV

– WebClient now can download/install application code

– System Tasks piece of WebClient front end to handle OCX registration, shortcuts etc



We still support 9.1B-style app install Auto convert 9.1B PROWCAPP file to 9.1C

PROWCAPP file in Assembler (but no automatic IntelliStream functionality)

Although WebClient downloads application files from AppServer, PROWCAPP file still comes only from Web server


Update IntelligenceUpdate Intelligence

When ISV creates a new version of app, we take care of figuring out which files have changed, collecting them into “diff” file

If individual .r file (or other file) from procedure library changes, we detect that and end user downloads only the new .r file (doesn’t have to download whole .pl file)!


New Update Paradigm?New Update Paradigm?

Because updates are smaller (and we automatically take care of a lot of work)…

ISV can (in the extreme) post a new version every night, with the bugfixes or enhancements from that day’s development

Then the end user who starts the app every morning always runs with the latest bits!


Refresher--9.1B Web InstallRefresher--9.1B Web Install

For good OOBE: bootstrap HTML file Launches WebClient install ISV customizes to launch app install after

WebClient install App install runs (e.g. InstallShield

OneClick) App runs


9.1C Web Install9.1C Web Install

All still the same (including bootstrap HTML) except:– WebClient can install the app (no need for

OneClick)

– Linking the WebClient install to the app install involves modifying a small HTML file

No changes in WebClient install itself in 9.1C--new ways to install application


9.1C CD Install9.1C CD Install

Still recommend InstallShield for CD install

Can then use IntelliStream for updates! Mixed mode: some users CD, some Web: – Web install can be:

IntelliStream OneClick (based on same InstallShield

project as CD install)– IntelliStream for updates


Changes in 9.1CChanges in 9.1C

No more “fixins” (pieces used to make the WebClient install). Not needed--ISV can customize (for good OOBE) using WebClient.htm, to tell WebClient install to kick off app install (via prowcini)

webinst.exe becomes webinstall/setup.exe


CaveatsCaveats

Despite the name “IntelliStream”, we do NOT DO STREAMING in the same way that “Web radio” does. When we’re downloading something, the end user waits--no background downloading while we’re doing something else

IntelliStream not available in other Progress clients--only WebClient (maybe future?)


CaveatsCaveats

No support for FTP protocol in IntelliStream (only: FILE:, HTTP(S): and APPSERVER:)


Hosting App CodeHosting App Code

Web server (as in 9.1B), or AppServer (either the same one as used

for running the app, or different one) Can share AppServer connection and/or

authentication info for “as needed” components and running the app


Changes on AppServer SideChanges on AppServer Side

No WebClient-related changes to server side in 9.1C, except:

One new file on AppServer machine:

$DLC/WCADD/_GetAppServerFiles.r


Changes on AppServer SideChanges on AppServer Side

_GetAppServerFiles.r:– Same file runs on UNIX & Windows (no U/I)

– Installed w/ 9.1C AppServer

– To run WebClient w/ 9.1B AppServer, must copy this file (see release note instructions)


Sample App ChangesSample App Changes

There is an IntelliStream-ed version of Sports2000 (as well as original, non-WebClient version)

Configuration of WebClient version on ProVision CD has changed somewhat from 9.1B


AgendaAgenda



AgendaAgenda

Overview– Architecture

– Assembler

– End User Machine

– Security

– Migrating to WebClient


InternetInternetoror

IntranetIntranetEnd User PC

Application Server

Application DeliveryServer

AppServer Calls (RUN)

Front End Components+ Config File

ProgressRDBMS

ProgressRDBMS

Application DevelopmentPC

Front End Components

+ Config File

Architecture DiagramArchitecture Diagram


The SitesThe Sites

End User PC: runs WebClient Application Server: UNIX, PC, etc Application Delivery Server:– Web server, or

– Application server (9.1C)--can be same Application Development PC:– Application development

– Preparing application for WebClient


The Players: What Do They Do?The Players: What Do They Do?

Deployer (on development PC):– Prepares application for WebClient

– Copies front end component files (and configuration file) to delivery server

End user (on end user PC):– Downloads WebClient and application front

end

– Runs application (makes AppServer calls)


What’s on the Delivery Server(s)?What’s on the Delivery Server(s)?

Codebase– Application files (.r, .ocx, .pl, etc) that go

onto end user machine

– May have install set of files and update set of files

Application Configuration File– May be on a different machine

– Must be on a Web server (not AppServer)


Application From the AppServerApplication From the AppServer

RUN statements go to an AppServer Components can come from same

AppServer– Maybe easier configuration

– Single sign-on (same authentication info for installing, updating & running app)

– May even share same AppServer connection


InternetInternetoror

IntranetIntranetEnd User PC

Application Server

WebServer

AppServer Calls (RUN) + Front End Components

Config File

ProgressRDBMS

ProgressRDBMS

Application DevelopmentPC

Front End Components

Config File

Architecture w/ AppServer DeliveryArchitecture w/ AppServer Delivery


Web Server Not RequiredWeb Server Not Required

For Intranet/LAN scenario, don’t need Web server to distribute that application

Can put Application Configuration File and codebase on file server

Reference URL’s: – FILE://M:/directory

(where M is mapped drive)


AgendaAgenda


– Assembler


– Security



AgendaAgenda

Overview– Assembler

General Components Using Assembler Assembler-related files System Tasks 4GL Installer Locators


Start with the AssemblerStart with the Assembler

ISV uses Assembler for everything to do with packaging app for deployment

Comes with ProVision ISV can invoke from Pro*Tools ISV can invoke w/ RMB on project file

(.wcp)


Files to be DeployedFiles to be Deployed

Application files to be deployed must be:– Collected together on development PC in

Application Root Directory (ISV specifies it in General Tab)

– AppRootDir must be accessible to Assembler--e.g. on same machine or reachable via File Open dialog

– Relative pathnames for files are all relative to App Root Dir



Files under AppRootDir must be organized in same directory structure that they will have on end user machine (but application installation directory on end user machine will probably have a different name than root directory on ISV machine)


AgendaAgenda




Separating Front End into ComponentsSeparating Front End into Components

With IntelliStream, you can treat your entire application front end as one component, or split it into two or more components.

Three flavors of component– At Startup (recommended)

– As-needed (optional)

– Ask User at Startup (optional)



Types of files that can go into components:– .r files (Assembler doesn’t need .p files)

– .pl files

– OCX’s, DLL’s, icons, images

– CAB file (CAB within CAB!)

– any other type of file


Three Flavors of ComponentsThree Flavors of Components

At startup: what you need to get going, plus utilities and shared code (e.g. ADM2)

As-needed: subsystems, should be as self-contained as possible

Ask: give user choice (now or later)


“At Startup” Component“At Startup” Component

Everything needed to start the app (e.g. first screen and menus)

Utility code, common files OCX’s and DLL’s that need to be

registered (by System Tasks) Files needed by 4GL Installer ADM2 common code


“As Needed” Component“As Needed” Component

Subsystem Stuff not all users will run, or stuff that

they won’t need right away (faster start without)

Tradeoff: faster start vs wait (for download) in the middle of running the app


“Ask User at Startup” “Ask User at Startup”

WebClient will ask the user if s/he wants to download the component as part of the initial install

Allows end user to get all the installs out of the way at the beginning, for the subsystems s/he expects to use


“Ask User at Startup”“Ask User at Startup”

Components user says “yes” to: WebClient downloads with “At Startup” component

Components user says “no” to: WebClient treats them as “As Needed” components


Packaging ComponentsPackaging Components

Assembler packages each component into a CAB file for downloading during app install:– Compression

– Collection (whole component goes as one)

– Digitally signed


Packaging ComponentsPackaging Components

CAB only for transport to user machine--WebClient deletes CAB file after expansion

After dust settles and CAB files deleted, app files on end user machine look same as:– They would look if installed without

IntelliStream, and– They look on application development

machine (except different root directory)


Note on ComponentsNote on Components

For OCX’s used in 4GL, need .wrx file also--should be in same component as corresponding .r file

Can contain any type of file--but by default, WebClient only copies them down; any special handling (e.g. registering) requires install steps (System Tasks or 4GL Install)


AgendaAgenda




Application AssemblerApplication Assembler

Generates three (sets of) CAB files:– Front end install downloads (CAB files)

– Front end update downloads (CAB files)

– Application Configuration File (in CAB file)


Generating Install FilesGenerating Install Files

ISV tells Assembler how many components and which files are in which components, plus some other info

ISV normally designates one component as “at startup”; all others (if any) are “as needed” or “ask user at startup”



ISV hits Okay in “Generate” dialog Assembler creates version-specific

directory containing CAB files:– One CAB file containing the PROWCAPP

file, and

– One install CAB file for each component, containing all the files in that component



ISV copies CAB files to Application Delivery server


Generating UpdatesGenerating Updates

ISV tells Assembler s/he wants to create a new version

Hits Okay in “Generate” dialog:– Creates a new directory for the version

– Finds all app files that have changed

– Collects changed files into one “diff” CAB file per component (only for components with changed files!)


Generating Updates -- Smarts!Generating Updates -- Smarts!

ISV doesn’t have to remember what changed! How does Generate figure out what app files have changed? It uses:– MD5 for .r’s compiled w/ GENERATE-MD5

– Time-stamp for others Compares value for each file against value

from previous version (saved in Version Info file)


Generating Updates -- Smarts! Generating Updates -- Smarts!

Front End Files

foo.ocx

baz.pl

gleep.r

...

bar.r

...

Assembler

Version Info File

Diff CAB File

foo.ocx

bar.r

gleep.r

Instructions


Diff CAB FilesDiff CAB Files

Diff CAB file contains (compressed):– Add, replace, remove flags for each

changed file

– Files that are new or modified since previous version

– For files in .pl files--just the files, not the whole .pl file(!)


Generating UpdatesGenerating Updates

ISV copies “diff” CAB file to Web server or AppServer, new PROWCAPP file to Web server

WebClient downloads and expands “diff” CAB file, puts updated files in right places (then deletes the CAB file)


Assembler RegenerationAssembler Regeneration

In “Generate” dialog, after initial generation of app files, ISV can say:– Regenerate the current version (because I haven’t

deployed it yet--still working on it), or

– Generate a new version But: cannot change previous versions:

– ISV creates V1 and V2, then makes changes

– Can regen V2 or gen V3, cannot modify V1




AgendaAgenda


Assembler-Related FilesAssembler-Related Files

Following files all go in version-specific directory (each version has its own set):– PROWCAPP CAB file (signed if app is

signed)– Component install CAB files (maybe

signed)– “diff” CAB files, one set per non-obsolete

version (maybe signed)– Version Info -- list of all components, files

in each component, MD5/timestamp values


Assembler-Related Files -- 2Assembler-Related Files -- 2

Filenames in directory <appname>_v3:– <appname>.prowcapc

– <compname>.cab, per component

– diffs/<compname>v1tov2.cab, diffs/<compname>v2tov3.cab, etc

– <projname>.wcv



Also project file (not in version directory)– Filename is <projname>.wcp in arbitrary dir

– Always contains most recent info, on current version



Assembler-generated files to be deployed (copied to Web/AppServer):– PROWCAPP CAB file

– CAB files (component install and diff) Assembler-generated files not deployed:– Project file (.wcp)

– Version info file (.wcv)



PROWCAPP file for download: Has to be on Web server (or file server)

because prowcini downloads it, cannot access AppServer

In version-independent location:– <prowcapp-locator>



CAB files for download: For each non-obsolete version:– Component install CAB files for this

version (for end users who don’t have the app at all)

– Diff CAB files from older versions (for end users with older versions of app)

Location:– <codebase-locator> + <version-name>


Application Configuration FileApplication Configuration File

Also known as PROWCAPP file Enclosed in CAB file (for compression) WebClient downloads a fresh copy every

time it starts the application Contains “meta-data” about the app that

WebClient needs, including list of all .r’s in as-needed components

Must go on Web server or file server


AgendaAgenda




System TasksSystem Tasks

Optional; takes care of Windows-specific stuff, so ISV doesn’t have to use InstallShield (we hope it covers 95%!)

ISV tells Assembler what System Tasks functions to execute

At app install, after downloading “At Startup” component, WebClient runs System Tasks using info in PROWCAPP



Allows ISV to:– Set up shortcuts for any or all of:

Running the app Uninstalling the app Running PROWCAM for the app

– Install system files (not in app directory)

– Register OCX’s and application DLL’s

– Run INI2REG on some file



Note: Assembler automatically adds all files referred to in System Tasks to the at-startup component

Because it needs those files when it runs System Tasks, after downloading (only) the at-startup component


AgendaAgenda




4GL Installer4GL Installer

Optional, “escape” to allow unspecified install-time processing (using the 4GL)

ISV tells Assembler to run xxx.r during install and uninstall

xxx.r should be in the “at startup” component (Assembler does not automatically put it there)


4GL Installer4GL Installer

For uninstall, 4GL installer should:– Remove any files that the app generates

while running (and leaves around between invocations)

– Undo whatever it did at install time (nobody else will undo this!)


Special File ProcessingSpecial File Processing

Generally, for files in components, WebClient just copies them onto end user machine

Special processing of files supported by:– System tasks:

Registering file Running INI2REG on file

– 4GL installer (arbitrary code run from 4GL)


AgendaAgenda




Tale of Two LocatorsTale of Two Locators

ISV enters both into Assembler, both go into PROWCAPP file

PROWCAPP locator tells WebClient where to get fresh PROWCAPP file (so PROWCAPP file points to itself)

Codebase locator tells WebClient where to go to download app components (all components come from the same place)


LocatorsLocators

Both specify:– A URL

that refers to a directory (never to individual file)

on a Web server (HTTP, HTTPS, FTP, FILE), or

on an AppServer, for codebase only– Authentication information (e.g. what

prompt to use when asking end user for uid/password)


Codebase LocatorsCodebase Locators

AppServer codebase locator URL– WebClient passes this URL as the -URL

connection parameter in the AppServer connect() call

– Protocol should be HTTP/S: if connection uses AIA, else APPSERVER:


Codebase LocatorsCodebase Locators

AppServer codebase locator URL (cont)– URL can specify two sets of authentication

information (one for AIA Web server, one for AppServer)

– Does not contain a directory name--codebase is always relative to the AppServer’s working directory


AgendaAgenda


– Assembler


– Security



AgendaAgenda

Overview– Architecture– Assembler– End User Machine

Application Install “As Needed” components Running the app Mixed Mode Miscellaneous


App Install ProcessApp Install Process

Start with a virgin machine End user launches WebClient install from

browser (via bootstrap HTML file) WebClient install completes, looks at

WebClient.htm file and generates a reference to the PROWCAPP file

Browser downloads PROWCAPP file, looks at MIME type, launches prowcini


App Install Process -- 2App Install Process -- 2

Prowcini looks at PROWCAPP file, launches prowc in “prowcini mode”

prowc (in “prowcini mode”) downloads “at startup” component (+“Ask user at startup” components that user asks for)

Has to be prowc that downloads components because they may be coming from an AppServer



If ISV called for System Tasks, prowc runs it and perform functions indicated by PROWCAPP file

If ISV called for 4GL installer, prowc runs it (all .r files in 4GL installer must be in “at startup” component)



prowc runs prowc again, in “app mode”, using the -p startup parameter for the app (plus other startup params specified by ISV in Assembler & end user w/ PROWCAM)

prowc (in “app mode”) runs the (first .r of) the app

Note: prowcini also sets up an Add/Remove entry to uninstall the application


AgendaAgenda


– End User Machine Application Install “As Needed” components Running the app Mixed Mode Miscellaneous


How Does “As Needed” Work?How Does “As Needed” Work?

Once app starts, if it hits RUN statement for .r that is not found, WebClient looks to see if it’s in an “as needed” component

Looks in list of files/component from the PROWCAPP file (sorted in-memory list)

If the .r file is in a component, WebClient downloads the component and runs the .r (app does not run during download!)


“As Needed” Detail“As Needed” Detail

RUN statement semantics for RUN foo:– Take first element of PROPATH (e.g. bar)

Look on disk for bar/foo.r (& check memory for previously run bar/foo.r)

[New in 9.1C] [Only in WebClient] See if bar/foo.r is listed as being in an “as needed” component--if so, download it

– If not found, go to next element in PROPATH


As-Needed ImplicationsAs-Needed Implications

As-needed not triggered by any other file reference (e.g. LOAD-IMAGE)

So any non-.r files in as-needed components should be in the same as-needed components as the .r’s that uses them


Good, Bad and...Good, Bad and...

Moving stuff into as-needed components:– Good: faster initial startup (no waiting to

download the whole app)

– Bad: end user hits some key that needs as-needed component and has to wait for it to download--users more tolerant of waiting during initial install?

– Ugly: codebase server could be down


AgendaAgenda




Running the App AgainRunning the App Again

End user starts app from shortcut or browser (same as 9.1B)

WebClient (prowcini) downloads fresh PROWCAPP file

Checks WebClient version Checks app version


Running the App Again -- 2Running the App Again -- 2

In normal case, same version, no updates But if there is a newer app version

available than what’s on the end user machine:– If end user’s version is older-but-

acceptable, give user the choice to update or run existing

– If end user’s version is not older-but-acceptable, tell end user s/he has to update or exit (i.e. mandatory update)



If user requests app update, WebClient:– Downloads “diff” CAB file(s) to get from

existing version to latest version

– Expands CAB files

– Copies contents to right places (update .pl files on end user machine as appropriate)

– Deletes the CAB files



WebClient runs System Tasks again if new System Tasks version

WebClient runs the 4GL Installer again if new 4GL Install version

WebClient runs the (updated) app


AgendaAgenda




Mixed ModeMixed Mode

Internet access too slow for install, but fast enough to update (& run)

Install WebClient & app from CD Use IntelliStreamTM to update! App front end install (from CD) should

include whole front end (including as-needed components)



To do mixed mode, ISV still has to use Assembler to define components (even though WebClient doesn’t download them), so we can do the updates



App install (non-IntelliStream, e.g. InstallShield) should:– Set up uninstall in Windows Add/Remove,

which calls prowcini and passes <appid> -u

– Set registry keys required by 9.1B plus:

– Bunch of new registry keys needed by 9.1C


AgendaAgenda




Who Does What Again?Who Does What Again?

On end user machine, three executables:– prowcini: downloads PROWCAPP file (from

Web server or file server), checks versions, launches prowc

– prowc: downloads app install CAB files and diff CAB files, performs app installs and updates, deletes the CAB files and runs the app

– PROWCAM: end user app management tool


Who Does What Again?Who Does What Again?

Note: end user should never invoke prowc directly

It should always be prowcini (or prowc itself) that calls prowc


Local PROWCAPP FileLocal PROWCAPP File

We always keep a local (disk) copy of the most recently downloaded PROWCAPP file (regardless of who downloaded it--browser or prowcini)

Location available from PROWCAM for troubleshooting


Uninstall an AppUninstall an App

For apps installed or updated with IntelliStream, prowcini does following:– Run 4GL installer

– Run System Tasks to clean up what it did

– Delete files IntelliStream put on end user machine

– Delete registry keys IntelliStream put on end user machine


Problems with NetscapeProblems with Netscape

If end user uses Netscape to launch WebClient/app install:– MIME type not really registered until end

user exits Netscape and restarts it

– System Tasks may not work on some platforms (see release notes) unless end user kills Netscape first


AgendaAgenda


– Assembler


– Security



Overview of Digital SigningOverview of Digital Signing

ISV can tell Assembler that a version of the app should be signed

Progress recommends that ISV’s digitally sign the app!



Benefits:– End user knows who it came from– WebClient detects tampering between

application development machine and end user machine

But: it’s still possible to have a problem if end user accepts signed app from evil parties



If an app version is signed, then all these files are signed for this version (all with same certificate):– PROWCAPP file

– Install CAB files

– All diff CAB files to bring end users up to this version



The 9.1C Web-based WebClient install (which uses InstallShield’s One-Click technology) is also signed (by Progress), but CD install (Windows-based InstallShield) is not signed



In order to sign app, ISV needs to get:– Authenticode SDK: ISV must get from

Microsoft due to licensing issue (we don’t ship it)--see instructions in release note

– A digital certificate: A real one (e.g. from Verisign) or Test certificate (MakeTestCert.bat)


Using SSLUsing SSL

Deployer should use SSL (HTTPS) for any traffic that goes over the Web:– PROWCAPP file

– Install files

– Update files

– AppServer calls So any calls to AppServer over Web

should use AIA and HTTPS


Why Sign if I’m Using SSL?Why Sign if I’m Using SSL?

With HTTPS protocol, traffic from Application Delivery server is encrypted

But still possible for hacker to corrupt unsigned files on the Application Delivery server after ISV has put them there

Signing app code guarantees integrity of app code from ISV development machine (where Assembler runs) to EU machine


AgendaAgenda


– Assembler


– Security



Migrating to WebClientMigrating to WebClient

For non-WebClient application, what’s involved in getting it deployed with WebClient?– Modifying the application itself

– Using Assembler to prepare CAB files


Modifying Your ApplicationModifying Your Application

Separate front end and business logic– Front end runs on WebClient

– Business logic runs on AppServer Even if you’ve already done that, make sure:

– All database access from AppServer; no database connection from front end

– Front end gets (& sends) database data via calls to business logic routines on AppServer


Modifying Your Application...Modifying Your Application...

Other things to consider:– Performance of AppServer calls

– Better error checking on AppServer calls

– Authentication (single sign-on)

– Move images to separate library?

– Compile r-code with MIN-SIZE

– No COMPILES in front end code

– Database multiplexing issues


Application Server

ProgressRDBMS

ProgressRDBMS

Application Server

ProgressRDBMS

ProgressRDBMS

End User 1

End User 2

End User 3

End User 4

Customer 1

Customer 2

Non-WebClientNon-WebClient


Application Server

ProgressRDBMS

ProgressRDBMS

End User 1

End User 2

End User 3

End User 4

Customer 1

Customer 2ProgressRDBMS

ProgressRDBMS

?

Deployer

WebClientWebClient


Breaking into ComponentsBreaking into Components

To use the “as needed” feature of IntelliStream, you have to break the front end into components

How hard that is depends on the architecture of the front end code

As-needed components should be self-contained, except for utility calls


For 9.1B WebClient ApplicationsFor 9.1B WebClient Applications

Assembler takes 9.1B PROWCAPP file and converts to 9.1C format

Can still use 9.1B install (e.g. InstallShield)


AgendaAgenda



AgendaAgenda

Details– Assembler


– Digital Signing


AgendaAgenda


Menu and Main Window Component Dialogs Version Dialog Locator Dialog System Tasks Dialog Generate Dialog Miscellaneous


Assembler MenuAssembler Menu

File menu: New/Open/Save for project files (.wcp)

Can also open 9.1B PROWCAPP file for autoconvert to project file

Save allows incomplete project to be saved, to allow incremental development--but can’t generate with incomplete info


Assembler MenuAssembler Menu

Deployment menu:– Validate

– Generate (brings up Generate dialog)

– Versions (brings up Versions dialog)

– Locators: Configuration File (to Application

Configuration File locator dialog) Codebase (to codebase locator dialog


Assembler Main WindowAssembler Main Window

General Tab:– Vendor name

– Application name

– Acceptable versions (read-only list of versions defined in Versions dialog, for reference only); contains current version and any older-but-acceptable



General Tab:– Configuration File URL (to self when

deployed)--read-only (set from Locator dialog)

– Startup parameters (for running app); must have at least -p

– Application root directory: where app code is on machine with Assembler.



Component Tab:– Codebase URL (read-only, defined in

Codebase Locator dialog)

– Locator button (to bring up Codebase Locator dialog)

– Read-only list of components defined so far + download mode; double-click to Edit component dialog

– Add/Edit/Remove for list



Options Tab:– ISV can select any or all of:

IntelliStream System Tasks IntelliStream 4GL Install procedure Web-enabled External Installer (9.1B style)



Options Tab: System Tasks– Specify version number for System Tasks

– Button to bring up System Tasks dialog



Options Tab: 4GL Install procedure:– Specify version

– Startup parameters when WebClient calls it to install

– Startup parameters when WebClient calls it to uninstall

– Can’t use -param (WebClient uses it)



Options Tab: Web-enabled external installer:– Specify version number

– Install URL

– Uninstall URL


4GL Install Procedure4GL Install Procedure

4GL Install procedure has its own version WebClient re-runs 4GL installer only when

the 4GL installer version changes No “diffs” for 4GL Installer, so should be

idempotent -- WebClient invokes same 4GL installer for– New app install

– Update (new 4GL installer version)


4GL Install Procedure4GL Install Procedure

When WebClient invokes installer, it appends: “-param <old installer version>,<new

installer version>”



WebClient Tab:– Specify where to get WebClient install for

preferred version of WebClient

– Comma-separated list of WebClient version numbers:

First is preferred Others are acceptable if already installed Can specify patch level (must be that or

higher)


AgendaAgenda




Assembler Component DialogAssembler Component Dialog

Component name Download mode End User Description (for “Ask at

Startup”) List of component files (except: for “At

Startup” component, omits files that Assembler added automatically for System Tasks)


Assembler Add Files DialogAssembler Add Files Dialog

Read-only reference to application root directory (defined in main window)

Tree control to select files “Perform recursive add” toggle Tree shows only files not yet added


AgendaAgenda




Assembler Version DialogAssembler Version Dialog

Display info about all deployed (and not obsolete) versions of app

End user can update from all listed versions to current version

Some versions may be not acceptable (WebClient won’t run them--end user has to update)



Why remove a version (make it obsolete)?– No end user has it any more, save space

on development machine

– Suspect version was corrupted, want to make sure no one can install it or update from it (force uninstall/reinstall)

– Newest version has so many changes, more efficient to uninstall than to update!



Version list (no 9.1B versions of app) with name and “acceptable to run”

Remove button to make version obsolete Read-only reference for output directory

(defined in Generate dialog) Comment: for ISV reference only, to

remind him what the version is



End user description: when asking end user if she wants to update to this version

“Acceptable to Run” toggle box--only turn this off if all older versions already off


AgendaAgenda




Assembler Locator DialogAssembler Locator Dialog

Allows ISV to designate locator info:– URL & type (Internet vs AppServer vs File)

– End User Description--WebClient displays to end user when asking for authentication info

– Disable persistent cache

– Suggestion to prompt for authentication info (optimization)


Assembler Locator DialogAssembler Locator Dialog

Codebase locator dialog:– Keep connection open (WebClient leaves

connection open if any “as needed” components left not downloaded); only for AppServer codebase

– Separate suggestion to prompt for AppServer authentication info

– Tell WebClient to use Configuration File locator to get to codebase


AgendaAgenda




System Tasks DialogSystem Tasks Dialog

General Tab:– Run INI2REG on selected file

Shortcuts Tab:– Application, Uninstall, PROWCAM

shortcuts



For application shortcut, ISV can specify:– Put an icon on the desktop

– Put an entry in the Programs menu For application shortcut and application

uninstall shortcut, ISV can specify an icon file (must be relative to application directory)


System Tasks DialogSystem Tasks Dialog

Files Tab:– List of files already selected

– Add/Edit to select files -- brings up Installation File Definition dialog

– Remove


Installation File DefinitionInstallation File Definition

Specify filename (relative to application root directory)

Indicate whether file should be registered or not

Indicate type of file (system vs application)


System FilesSystem Files

Can specify “register the file” or not Two types of system files:– COMMON files, which WebClient puts into

C:\Program Files\Common Files

Used for files shared between >1 ISV app

– System files, which WebClient puts into Windows System folder (e.g. C:\windows\system (W9x) or C:\winnt\system32 (NT))


System FilesSystem Files

System files: can specify which flavor or Windows to put them in: – Windows 2000/NT only

– Windows 95/98/ME only

– System Generic (all Windows versions) Can specify two files with same filename

but different file types (WebClient picks correct one for end user’s system)


Application-Specific FilesApplication-Specific Files

Dialog also allows ISV to specify non-system files that need to be registered--files will go into application directory

ISV chooses “Application Specific” radio item in file definition dialog

Forces “Register File” toggle box to:– Checked (i.e. yes)

– Disabled (so can’t toggle to “no”)



System Tasks is prebuilt InstallShield exe System Tasks runs silently (except may

force or suggest a reboot after installing system files)

App uninstall also runs System Tasks, to undo whatever it did


System Tasks VersionsSystem Tasks Versions

When the ISV specifies System Tasks instructions to the Assembler, s/he also specifies an System Tasks version string.

On subsequent app executions, WebClient runs System Tasks only if version number changed.


System Tasks IdempotencySystem Tasks Idempotency

No “diffs” for System Tasks, so WebClient does exactly same things for:– New app install

– Update (new System Tasks version) Exception: shortcuts


System Tasks and ShortcutsSystem Tasks and Shortcuts

If WebClient notices that a shortcut already exists when it processes System Tasks, it does not modify it or create a new one

So, no mechanism in System Tasks to:– Change shortcut once defined– Remove shortcut– Rename shortcut

Can replace icon file for shortcut, though


AgendaAgenda




Assembler Generate DialogAssembler Generate Dialog

New:– Create a new version directory, put files

into it Regenerate– Re-use existing current version directory– Deletes contents of directory first, then

regenerates– Don’t do this if already deployed current

version!



Output directory: folder where version-specific directory is (or where to create it)

Version directory--read-only, name of version directory in output directory: <outputdir>/<version-name>



Version information:– Unique name for version

– Name of last deployed version (read-only)

– Comment (for ISV’s benefit, to identify the version)

– End user description -- shown to end user when asking if s/he wants to upgrade to this version



Digital signing:– None

– Yes, get digital certificate from the registry

– Yes, get digital certificate from disk files



Picking certificate from registry:– Pick certificate store from list (list is based

on info from Windows)

– Pick specific certificate name within the store

Picking certificate from disk file:– Identify file containing certificate

– Identify private key



Registry vs Disk File for certificates:– Usually a choice when you get the

certificate

– Registry is more secure (cannot be copied off machine, so better protected) but more work (?)


AgendaAgenda




Sequential UpdatesSequential Updates

Each “diff” CAB file goes from Vx to Vx+1 When Assembler generates a new version,

it copies all previous “diff” CAB files and adds a new “diff” CAB file (to go from the previous version to the new one)

For multi-version hop, WebClient applies “diff” CAB files sequentially


Sequential UpdatesSequential Updates

Example: ISV generates V5 Assembler copies 3 diff files (V1-to-V2, V2-

to-V3 and V3-to-V4) and generates one new diff file (V4-to-V5)

End user has V2, wants to update to V5 WebClient downloads and applies diff

files: V2-to-V3, V3-to-V4, and V4-to-V5


Sequential Updates--CleanupSequential Updates--Cleanup

ISV’s should keep “diff” CAB files until version becomes “obsolete”


Sequential Updates--Cleanup 2Sequential Updates--Cleanup 2

ISV tells Assembler to remove obsolete version X. Assembler:– Removes the whole version X directory – Removes the diff file (for X-to-X+1) from the

current version directory (so diff file will also be missing in all future version directories)

So no way to install X or update from X to current (or subsequent) versions of the app


Sequential Updates--Cleanup 3Sequential Updates--Cleanup 3

Note: a previous version may be supported (not obsolete) but not acceptable.

This means that some users have this version

WebClient won’t run this version, but WebClient can update it (because the ISV

still has the “diff” CAB files)


What’s the MD5 Thing?What’s the MD5 Thing?

New GENERATE-MD5 option on COMPILE statement puts MD5 hash value into .r file

MD5 more accurate than time-stamp (e.g. if you recompile a .p without changing the source code, you’ll get the same MD5 value but a different time-stamp)

Like CRC only essentially no collisions


Figuring Out What’s ChangedFiguring Out What’s Changed

When Assembler generates a version, it stores a value for each file into the VersionInfo file:– MD5 value for .r files that have them

– Time-stamp for .r files without MD5 values

– Time-stamp for all files other than .r files


Figuring Out What’s Changed Figuring Out What’s Changed

When it generates the next version, Assembler looks in each application file and compares the MD5/time-stamp value in the file against what’s in the VersionInfo file from the previous version, to see what files changed


AgendaAgenda



– Digital Signing


AgendaAgenda

Details– End User Machine

Authentication Sharing AppServer Connection Keep Connection Open PROWCAM prowcini


AgendaAgenda


Authentication– Intro– Single Sign-on– PROWCAPP Authentication– Codebase Authentication– Authentication Failure– Caching– Sharing AppServer Authentication Info


AuthenticationAuthentication

End user may have to provide authentication for:– Web server to get PROWCAPP CAB file– Web server to download application CAB

files– Web server fronting AIA to download

application CAB files from AppServer– Connecting to AppServer to download app

files– Connecting to AppServer to make app calls


AuthenticationAuthentication

Connecting to Web server requires:– Userid– Password (probably)

Connecting to AppServer requires connect() method parameters, passed to connect proc : – Userid– Password (probably)– AppServer info


Authentication OptionsAuthentication Options

ISV can embed authentication info into URL’s in PROWCAPP file

Not recommended: – PROWCAPP file not necessarily encrypted

(only if app is signed)

– Same userid/password for all users (all share same PROWCAPP file)

– PROWCAPP distributed widely/frequently


Authentication OptionsAuthentication Options

Better: ask the end user for authentication info

Problem: potentially lots of places that we would have to ask for authentication info; end user gets annoyed having to enter same info more than once


AgendaAgenda




Single Sign-on: the IdealSingle Sign-on: the Ideal

End user has to provide authentication info only once, and then WebClient will:– Use the same info every time it needs to do

authentication (in the current app invocation)

– Policy: also remember and re-use info at next app invocation, without asking the user again

How close app comes to ideal is up to ISV and end user


Single Sign-onSingle Sign-on

ISV:– Same authentication info works

everywhere: All locks accept user’s key Share PROWCAPP authentication info Share AppServer authentication info w/ app

– (Policy) Don’t disable persistent cache



End user:– Invoke w/ shortcut, or tell browser to cache

info

– (Policy) Tell WebClient to cache authentication info persistently



Key to single sign-on is authentication info cache:– Always a “session” cache

– Can be a persistent cache


AgendaAgenda




PROWCAPP AuthenticationPROWCAPP Authentication

If end user launches app every time from Web browser, browser downloads PROWCAPP file and is responsible for authentication (and digital signature validation, if any)

Browser may allow end user to cache userid/password for browser, but WebClient has no access to that cache--has to ask again



If end user launches from shortcut, WebClient downloads PROWCAPP file

By default, WebClient tries download without authentication; if Web server says “need authentication”, WebClient asks end user for authentication info and tries again

When WebClient prompts, uses description string ISV saved with PROWCAPP locator



If ISV plans to require authentication for PROWCAPP file, can tell Assembler to prompt end user. WebClient doesn’t bother trying without authentication

Optimization only--any time WebClient gets authentication failure on PROWCAPP file, prompts user for (new) authentication

Ignored if cache has value for PROWCAPP


AgendaAgenda




Codebase AuthenticationCodebase Authentication

When WebClient downloads app CAB files, may need:– Web server authentication (with AIA)

– AppServer authentication Unlike PROWCAPP file, may be multiple

CAB files downloaded during single app execution



In 9.1C, all app CAB file downloads come from one codebase--would be annoying to ask end user for the same info more than once during single app execution!

WebClient does session-level caching of codebase authentication info automatically

WebClient asks end user > once per app execution only if authentication failure



By default, WebClient tries to connect to codebase without authentication

If authentication failure, prompt end user for info (using codebase locator description string)

ISV can short-circuit by asking for prompt:– For Web server and/or

– For AppServer



Three different prompt dialogs:– Web server info only

– AppServer info only

– Web server and AppServer info



Potentially three Web servers: need one for– PROWCAPP file

– Codebase (AIA)

– AppServer calls in app (AIA) If ISV uses same Web server for two or

more, may or may not use same authentication


PROWCAPP/Codebase SharingPROWCAPP/Codebase Sharing

Two ways:– Codebase is on Web server, and uses

same Web server as PROWCAPP file

– Codebase is on AppServer, using AIA, but AIA is on same Web server as PROWCAPP file

Would be nice if we didn’t have to ask end user for authentication for same Web server more than once per app execution



ISV can request that WebClient try to use PROWCAPP file authentication info when it needs to access the codebase

ISV checks “Share Authentication Cache of .prowcapp locator” in codebase definition dialog of Assembler



Works only if end user launches from shortcut: prowcini downloads the PROWCAPP file and stores authentication info in registry; prowc gets it out of registry and uses for codebase

If end user launches app from browser, browser downloads PROWCAPP file, we don’t have access to authentication info


AgendaAgenda




Authentication FailureAuthentication Failure

Ultimately, authentication (or digitial signature validation) may fail after several attempts. Effect:– PROWCAPP file: WebClient exits

– “At startup” component: WebClient exits

– Diff CAB file: WebClient exits

– “as needed” component: RUN statement returns ERROR


AgendaAgenda




CachingCaching

“Session” caching of authentication info is always on

Session is an application invocation, including: prowcini+prowc+prowc

So if prowcini asks for authentication info, saves it (in registry) for prowc to use also


Persistent CachingPersistent Caching

Persistent caching (preserved between app invocations) requires:– ISV allows it

– End user asks for it



ISV can separately disable persistent authentication info cache for:– PROWCAPP file

– Codebase To disable: ISV checks “Disable Persistent

Cache” toggle box in Assembler locator dialog



End user requests persistent cache by checking toggle box in authentication request dialog boxes (separately for PROWCAPP file and codebase)

Mechanism: cache info is in registry during app invocation; at end, prowc either deletes it (non-persistent) or leaves it (persistent)



Once end user requests persistent cache, WebClient won’t ask for same info again--unless authentication fails

If cached info fails, WebClient clears the cache and asks the end user for new info

WebClient uses new info for rest of session

WebClient won’t make cache persistent unless user requests it again in dialog



Authentication cache is encrypted (per user) in registry; we try 128-bit encryption first--if not on machine, we use 40-bit

End user can clear persistent cache with PROWCAM, if:– User knows authentication info has

changed

– User decides not a good idea to have persistent cache (e.g. machine not secure)


Persistent Cache and PromptingPersistent Cache and Prompting

If ISV has said “Prompt” for PROWCAPP or codebase, and end user has saved a persistent cache for authentication info, cache wins (no prompting--unless cached value fails, then prompt for new)


AgendaAgenda




Sharing AppServerSharing AppServer

If codebase is on the same AppServer that the app connects to, there are two kinds of sharing that could happen:– The app could make its own connection to

the AppServer but re-use the codebase’s authentication info (avoid prompting user), or

– The app and WebClient could share the same AppServer connection


Share AppServer AuthenticationShare AppServer Authentication

The application wants to re-use AppServer authentication info from previous codebase connections (so app doesn’t have to ask user again for same authentication info)

CODEBASE-LOCATOR pseudo-widget has attributes that allow this

Uses persistent cache only (not session); attributes return UNKNOWN if no persistent codebase cache


CODEBASE-LOCATORCODEBASE-LOCATOR

App can read any of these from persistent codebase cache:– URL-USERID

– URL-PASSWORD

– APPSERVER-USERID

– APPSERVER-PASSWORD

– APPSERVER-INFO



In effect, WebClient populates these attributes at startup if there is a persistent codebase cache

If ISV specified “Share Authentication Cache”, WebClient copies URL-USERID and URL-PASSWORD from PROWCAPP cache at app startup (so no backwards effect on PROWCAPP cache if app modifies ‘em)



App can also set these--e.g. if it connects to AppServer first (WebClient will use this authentication info if it has to download “as needed” components)



Also, following attributes copied from PROWCAPP (read-only):– LOCATOR-TYPE (codebase locator type--

“Internet” or “AppServer)

– URL

– NEEDS-PROMPT

– NEEDS-APPSERVER-PROMPT



Also, following attributes copied from PROWCAPP (read-only):– END-USER-PROMPT (string to show user)

– KEEP-CONNECTION-OPEN

– PERSISTENT-CACHE-DISABLED



Additional R/W attributes:– KEEP-PERSISTENT-CACHE (default is

false unless end user said “Keep persistent” for codebase cache)

– SERVER (AppServer handle, used to share AppServer connection)


End User Prompt ProceduresEnd User Prompt Procedures

Problem: for a given app execution:– WebClient could connect to AppServer first

(because of an update or an “as needed” component), or

– App could connect first (e.g. if no updates) App would have to use its own

authentication dialog, WebClient has its own--different dialogs confuse end user



Solution: 3 4GL routines app can call to get same authentication dialog as WebClient:– GetAIAAuthentication.r– GetAppServerAuthentication.r– GetAIAandAppServerAuthentication.r

These 3 .r files get installed with WebClient, in $DLC/WCADD

Not in POSSE, no source code available



App calls:

RUN wcadd/Get…Authentication(…) Several input parameters to control

appearance of dialog box and default values

Several output parameters to return user input


AgendaAgenda




Share AppServer ConnectionShare AppServer Connection

App connects to AppServer App sets

CODEBASE-LOCATOR:SERVER

to point to AppServer connection WebClient uses same connection to

download “as needed” components



Benefits:– Saves resources (only one connection)

– Performance: WebClient doesn’t have to take time to establish its own connection when it has to get an “as needed” component

Application does its own authentication request dialog, but WebClient uses its own for “at startup” components



If SERVER handle is set, WebClient assumes it can use to get an “as needed” component--if WebClient has any problem using it (e.g. connection broken or outstanding async calls), it returns ERROR from the RUN statement

Don’t use if application is doing async AppServer calls!


AgendaAgenda




Keeping Connection OpenKeeping Connection Open

For codebase locator, by default, WebClient connects/disconnects for each “as needed” component

If expecting more than one per app execution, ISV can request WebClient keep the codebase connection open (after the first time it has to open it)

Ignored if sharing AppServer connection!


Keeping Connection OpenKeeping Connection Open

ISV specifies “Keep Connection Open” in Assembler codebase locator dialog

WebClient closes connection after downloading the last “as needed” component (no point in leaving it open)

Even if WebClient doesn’t disconnect, connection may be broken (e.g. timeout); if so, WebClient just reconnects


AgendaAgenda




PROWCAM End User ToolPROWCAM End User Tool

End user can view and edit app info Also some WebClient info (e.g. versions) Can generate app-related info to text file

(for troubleshooting) Can clear WebClient log file No on-line help


PROWCAMPROWCAM

Invocationprowcam /* webclient mode */

prowcam “vendorname/appname” System Tasks can create shortcut for app

mode Handles both 9.1C and 9.1B versions of

WebClient


PROWCAM WebClient ModePROWCAM WebClient Mode

Shows versions of Progress installed Allows end user to specify proxy server

information Allows end user to override application

directory s/he designated during WebClient install

Also identifies applications installed


PROWCAM App ModePROWCAM App Mode

“Write to File” creates text file with registry settings relevant for application. User specifies filename. For troubleshooting



General tab read-only fields:– PROWCAPP file URL

– Application directory (where app is installed)

– Where local copy of Configuration file is (so ISV can ask end user to send in the Configuration file--this tells end user where to get it)



General tab:– App version, App Install version (9.1B-style

install), System Tasks version, WebClient version

– PROWCAPP file format version

– End user can enter startup parameters which WebClient will digest after whatever parameters the PROWCAPP file specifies



Log tab: displays log file contents, allows end user to clear it. Also identifies log file name (in case ISV needs end user to send it in to help troubleshooting)

Note: “Clear Log” is immediate and permanent (Cancel button has no effect)



Security tab:– Is app signed or unsigned (currently

installed)

– Is persistent cache in use for PROWCAPP authentication info?

– Is persistent cache in use for codebase authentication info

– Allows end user to clear either persistent cache (effect is immediate and permanent)



Component tab:– Identifies which components WebClient

has downloaded so far


AgendaAgenda




prowciniprowcini

First, always downloads new PROWCAPP Will run prowc directly in app mode if:– 9.1B-style app install, or

– App version number in PROWCAPP same as registry entry showing current version

– App version in PROWCAPP is later, but current version is acceptable and end user declined to update to later version


prowciniprowcini

How check for updates?– 9.1B PROWCAPP: ApplicationVersion field

– 9.1C PROWCAPP: ProwcappVersion field If current version on end user machine is

older-but-acceptable, ask end user if s/he wants to update to latest version


prowciniprowcini

Dialog that asks end user will display End User Description strings from Generate dialog in Assembler for all diffs between current and latest (e.g. for v1/v2 and for v2/v3)

End user can say “don’t ask me again”--i.e. I don’t want this version--but prowcini will ask again for the next app version


prowciniprowcini

If incoming PROWCAPP file is in 9.1C format, but the current app version came onto end user machine with 9.1B PROWCAPP file--no updates possible.

Have to uninstall app and install 9.1C version of app


Detecting Incomplete UpdatesDetecting Incomplete Updates

Prowc (in prowcini mode) first sets ProwcappVersion in registry to “Unusable”

If prowcini-mode downloads are all successful, prowc resets ProwcappVersion

When prowcini starts up, it checks to see if ProwcappVersion is “Unusable”--if so, end user has to update to latest version (e.g. try again)


prowcini Authenticationprowcini Authentication

If end user launches WebClient from browser, browser downloads PROWCAPP file (and handles authentication issues)

If end users launches from shortcut, prowcini downloads PROWCAPP file


prowcini Authenticationprowcini Authentication

Asking Web server for PROWCAPP file:– If persistent PROWCAPP authentication

cache has info, prowcini uses it– Else if the PROWCAPP URL contains

uid/pw, prowcini uses it– Else if ISV indicated Prompt for

PROWCAPP locator, prowcini prompts end user for info

– Else prowcini assumes no authentication needed


AgendaAgenda



– Digital Signing


AgendaAgenda



– Digital Signing Certificates Signing the app Effect on end user machine Test Certificate


CertificatesCertificates

In order to sign the app, ISV must have a certificate (e.g. from Verisign)

Certificate is not specific to WebClient (ISV may already have one), can be used for other things too

On ISV machine, certificates go into registry or disk file


CertificatesCertificates

ISV has his own certificate, and ISV and end user must also have certificate from the CA (Certificate Authority--e.g. Verisign)

Most common industry CA certificates already installed with Windows


AgendaAgenda





Signing the AppSigning the App

In Generate dialog box Toggle box tells Assembler to sign the app ISV identifies the certificate to use For certficates in the registry on ISV

machine, Assembler creates list of stores and certificates using Authenticode



If ISV generates version X+1 with signing, and version X was either unsigned or signed with a different certificate:

The Assembler resigns all the diff CAB files in X+1 to use the new certificate--so all diff CAB files for a version use the same certificate



Example: version 2 directory contains:– PROWCAPP,V2 Install CAB,V1-V2 diff CAB

All signed with Bryan’s certificate Now if ISV signs version 3 with Ken’s

certificate, the V3 directory will contain:– PROWCAPP, V3 Install CAB, V1-V2 diff

CAB and V2-V3 diff CAB

All signed with Ken’s certificate



Once generated, ISV takes same steps to deploy signed app as unsigned--copies CAB files to codebase server


Signing and OuthostingSigning and Outhosting

App is signed by ISV’s certificate, regardless of whether ISV hosts download files or uses outhoster.

Outhoster does not sign any app files So end user sees “do you trust this”

dialog referring to ISV, not to outhoster


AgendaAgenda





Effect on End User MachineEffect on End User Machine

First time end user tries to execute unsigned app, WebClient will put dialog box saying app may not be secure, does end user want to run anyway (bias toward signed app!)

If user says “no”, WebClient won’t run it If user says “okay”, WebClient won’t ask

again (unless app flips to signed and then back to unsigned)



If app was signed, and new version comes down unsigned, WebClient will again ask end user (someone may have hacked the PROWCAPP file)

If app is signed, WebClient will validate the signature on the PROWCAPP file before proceeding



If WebClient finds a signed PROWCAPP file, it expects all other files to be signed also (hacker cannot substitute unsigned CAB file)


Validating SignatureValidating Signature

WebClient calls on Microsoft Authenticode technology to validate a signature.

Authenticode (by default) prompts end user for verification every time.

End user can say “I trust this file and any other files signed by the same guy”, so Authenticode won’t ask again


Security ConsiderationsSecurity Considerations

If ISV goes from unsigned to signed, he should consider making the unsigned version obsolete, if he suspects somebody may have hacked the unsigned version(s)

WebClient won’t run it and won’t install it, and end user cannot update it


AgendaAgenda





Using a Test CertificateUsing a Test Certificate

For testing purposes, ISV can use:– $DLC/bin/MakeTestCert.bat

to generate a test certificate Test certificate good enough for testing

only Particularly useful for beta (don’t waste

time waiting for certificate issuer)


Test Certificate CaveatsTest Certificate Caveats

Test certificate is machine-specific--generated on one machine but works only on that machine and cannot be exported to any other machine

See comments in the .bat file for some tweaking ISV should make before running


Test Certificate CaveatsTest Certificate Caveats

MakeTestCert.bat requires Authenticode SDK (same as required for Assembler)


AgendaAgenda



Migrating from 9.1BMigrating from 9.1B

Assembler can take 9.1B PROWCAPP input, create corresponding 9.1C project file (but no automatic IntelliStream functions)

Problem: ISV already deployed w/ 9.1B, now wants to use 9.1C features (IntelliStream)--what happens on end user machine (like to avoid uninstall/reinstall!)



ISV must create update install (via a Web page) to:– Install the new (9.1C version of) app code– Set some registry entries

ISV tells Assembler about update installer Then ISV uses Assembler to generate new

(9.1C) version of app, containing same files the update install puts on end user machine



New PROWCAPP file will tell WebClient to run update installer (install new app files)

WebClient will not do an IntelliStream update because version numbers will match (after update installer runs)

App on end user machine now ready to be updated by IntelliStream & do “as needed” downloads



Okay, but what if we have V1 (9.1B), V2 (9.1C, as just described), and then we update app to get V3

Problem: some user may have missed V2, still have V1 (9.1B) on machine

WebClient runs update installer (installs V2), then sees it needs to update to V3--normal update processing



Implication: ISV has to keep update installer around as long as any end user still has V1--needed to get to V2!

But update installer never changes Only case when you would normally

identify both a Web-based install and IntelliStream install for same app


AgendaAgenda



TroubleshootingTroubleshooting

Two files end user can send to ISV: – Local copy of most recent PROWCAPP file

(end user can find it by using PROWCAM to get filename)

– Registry data file generated by PROWCAM All registry entries of interest are covered

by these two files, so no need to walk end user through regedit!


TroubleshootingTroubleshooting

ISV can also request that end user send in the log file (filename available on Log tab in PROWCAM app mode)

IntelliStream puts temp files into the system TMP directory

Documents

WebClient Extensions in 9.1C