After designating which PBLs you want to have the tool examine, you'll
be able to print, save, and browse the Migration Assistant's analysis
report. (Figure B)
You can now begin formalizing your Migration Plan.
The Migration Assistant is a great boon to the developer in that its
discovery success rate is close to 100%, but you'll want to add a
thorough quality assurance cycle to the tail end of that plan.
Once you believe you and your team are ready for the migration process,
open the application in PowerBuilder 11. The Migrate Application
response window will open. Verify your library list, choose your
message notification level, select whether you want PowerBuilder to
automatically convert DBCS string manipulation functions appropriately
for unicode usage...this is the point of no return and your last chance
to back up your PBLs...then click OK. (Figure 3)
Unsupported Features in Windows Forms Projects
In
its 11.x time frame, PowerBuilder is a .NET deployment solution. That
is, the developer isn't strictly working with .NET in the PowerBuilder
IDE. (.NET in the PowerBuilder IDE is slated for version 12). As such,
any application can use PowerBuilder features that are appropriate to
Win32 deployments, but aren't supported yet or not appropriate for .NET
deployments. (Figure C)
There are, however, those unsupported features that Sybase doesn't plan
to support for .NET deployment such as non-visual classes for profiling
and tracing. PowerBuilder developers will have to identify where in
their applications they may be using unsupported features and then
decide how they want to refactor the application to work around each
feature. The next part of this article will cover identifying
unsupported features in your application, yet I highly recommend at
some point that you review Chapter 11 of "Deploying Applications and
Components to .NET" in the documentation to become familiar with this
reference for "Unsupported Features in Windows Forms Projects".
http://infocenter.sybase.com/help/topic/com.sybase.dc00586_1100/html/dplynet/CJAJHFGB.htm
Deploying Your WinForm Application
OK. It's time
to deal with the nuts and bolts of features not supported for
WinForm-deployed applications, so it's time to do our initial deploy!
Since the thrust of this article is preparing your PowerBuilder
application for WinForm deployment rather than the details of how to
actually deploy it as WinForm, I'll refer you to the detailed external
resources on just how to do that.
In the core document "Deploying Applications and Components to .NET,"
Chapter 9 "Deploying PowerBuilder Applications as .NET Windows Forms"
takes you through the use of the .NET Windows Forms Application wizard.
http://infocenter.sybase.com/help/topic/com.sybase.dc00586_1100/html/dplynet/BABEEDAC.htm
There are also detailed recordings of deploying/publishing your
WinForm application using .NET Smart Client techniques. Look for
demonstrations of PowerBuilder 11's "Intelligent Updater" at www.sybase.com/products/development/powerbuilder/videos and at www.sybase.com/products/development/powerbuilder/webcasts.
The .NET Deployment Output Log
Once you've
deployed your target as a WinForm, you'll want to examine the tabbed
output logs in the PowerBuilder IDE. Exporting can save these logs and
I highly recommend you do so.
Pay attention to the Default, Warnings, and Errors logs first. They
arguably will have the most critical issues needing your attention. A
text file named DeployLog.txt is generated with each .NET deployment in
PowerBuilder 11. Besides aiding you with deployment errors it may be
beneficial in helping you resolve any remaining configuration issues.
Now it's time to examine the Unsupported Features output log.
The Unsupported Features output log is populated the first time you
deploy to WinForm and each subsequent time you choose to do a full
rebuild. Of course, if after a deployment you add any features to your
application that are unsupported, even an incremental rebuild should
yield a populated output log. There's a lot of useful information in
that output log, but I'm sure you'll agree that it'll take some effort
to read through it in its raw form and continue to use it as a
reference document as you formulate your Refactoring Plan. That's why
the .NET Features Analyzer was recently introduced.
The .NET Features Analyzer IDE Add-in
The .NET Features Analyzer is available on Sybase's codeXchange Web site at https://powerbuilder.codexchange.sybase.com....
This tool was created in the 4GL tradition to provide you with a
productive IDE for browsing the Unsupported Features output log.
The tool is an add-in to the PowerBuilder IDE. Once installed, open it
from the File>New menu item in the IDE and select it from the Tool
tabpage of the New response window. Use the tool to open a saved output
log or tell it to import the log that may be open in the PowerBuilder
IDE. .NET Features Analyzer lets you browse unsupported features by
class and PBL. In its IDE, you may also examine the raw output log as
well as any exceptions that are thrown. All of this may be printed and
you may save the raw output from here as well. (Figure 4)
Formulate Your Refactoring Plan
So once you've
identified the features in your application that aren't supported in a
WinForm deployment, it's time to divide and conquer. Decide what
workaround you'll use for each unsupported feature, how much time it'll
take, what resources to assign, and estimate a time frame. In other
words, you won't want to skimp in managing this as a formal project.
Some Caveats
A couple of caveats while you
refactor your PowerBuilder application for WinForm deployment: 1) the
functionality of the debugger for .NET deployment targets is different
from Win32 deployments using pcode; 2) You may want to consider
migrating to PowerBuilder 11.1 rather than version 11 to take advantage
of the incremental compilation that was added. Otherwise your entire
application will have to be compiled before you can see the runtime
impact of the modification of a single line of code or even a minimal
layout change in one of the visual painters. While the runtime speed is
comparable to Win32 deployments, full build-and-deploy times for a
library list of PBLs amounting to 150MB can take as much as a half-hour.
Additional Resources
Additional resources are
available to aid you in this process. Besides the white papers and tech
tips available from the support section of the Sybase Web site, there
are technical articles in the PowerBuilder Developer Journal, the ISUG
Journal, as well as the International Developer Magazine. The most
notable supplemental resources in my opinion are the PowerBuilder
newsgroups.
www.sybase.com/detail_list?id=11507&multi=true&SR=Y&show=1248
Sybase Newsgroups
The Sybase newsgroups are where
your peers and a group of skilled volunteers (TeamSybase and Team
iAnywhere) answer questions posted on a range of Sybase products and
solutions. I can't think of a better place to get an answer to a
question by a person who discovered the solution to the problem you're
experiencing today...six months ago.
www.sybase.com/support/community-forums
The Most Productive .NET Developer
PowerBuilder
isn't the first development tool to take you to .NET, but it's among
the first. Sybase wanted to ensure that PowerBuilder users could take
their applications and their components to .NET long before they had
to. PowerBuilder ensures that you don't have to rewrite all of your
applications completely from the ground up to take them to
.NET...unlike some of its competitors have.
PowerBuilder 11's WinForm deployment capabilities take the PowerBuilder
presentation layer application of your two-tier or n-tier solution to
.NET today and preserves your standing as the most productive business
application developer on the block.
Subscribe to Web 2.0 Journal Email News Alerts
Subscribe via RSS
