I’ve inherited an old site running ASP with embeded perlscript in IIS7 on Windows Server 2008. Everything works fine there but for obvious reasons I need to get this migrated to Windows Server 2016.
Recently, I installed ActivePerl 5.28 on a Win2016 Server but I just can’t seem to be able to get PerlScript to work in IIS10. Running scripts for the command prompt is fine so far.
The 5.28 documentation says running the installer without admin privileges causes issues such as:
PerlScript file associations are not created
The PerlScript feature will be unavailable
but the installer was run as an administrator, and yet the feature and associations are not there.
Has anyone managed to successfully get PerlScript in Classic ASP code to work on Windows Server 2016 with a recent version of an ActivePerl installer?
The current versions of ActivePerl no longer provide the components that your old site used. They are deprecated.
To get those components, you will need a Team or Business subscription with access to the back catalog. PerlSE starts to destabilize at 5.10 and by 5.16 it is no longer stable enough for production usage.
Our 5.14 (and older) installers are end of life, and they were not supported for use on Server 2016. IIS8+ isn’t supported for the older versions of ActivePerl either. You might be able to make it work, but you’ll have to work out how to set it up on your own based on the old examples and documentation for IIS 5 and 6. You will also need to add components to IIS itself, as modern versions do not install the libraries needed for Classic ASP sites.
Hello!
I’m also supporting a legacy app, and this info helped me troubleshoot a system failure after our server team upgraded to WS2016. However, we had to have them stand the old server back up since PerlScript in ASP is no longer supported.
What is the recommended way to migrate to the new way of doing things without having to rewrite the entire application?
I assume the problem is focused around the PerlScript code inside the .asp file. Is that entire concept deprecated? Or has the style just changed?
Since I need to get this done ASAP, I’m going to start off down the path of converting it to a standard perl script (from index.asp to index.pl) and change the index.asp to redirect (or iframe) to index.pl. The more I think about it, this might actually be the best stop-gap solution.
Rewriting this legacy app is already on our team roadmap, and we’re expecting to start in a couple of months, so I don’t want to spend too much effort patching this legacy version.
Thanks for your help
PS. This is the only post that I found that actually addressed this issue. This is such a niche design choice (perlscript in asp) that the results were sparse, and the other posts were years old. If this post is found by more people, the recommended fix (not reverting to end-of-life products) would be helpful to have in this thread.
As an interim solution, yes, the Perl scripts can be loaded into standard CGI or FastCGI. Standard CGI is at least as legacy as ActiveServerPages, and the Perl community has been strongly encouraging people to move off, and build modern Catalyst or Dancer frameworks instead, but CGI is the easier path if something temporary is the object.
The problem with PerlScript, and PerlEx, and PerlIS, is that these products were imagined when Perl wasn’t threaded, and IIS wasn’t really threaded either. If they had been proposed five years later, they would never have gotten approved. It’s a really hard thing to get one threaded program running properly inside another threaded program, since you are certain to get race conditions when a process ends and both programs fight to try to clean up the garbage and the pointers. As Perl hardens it’s own ability to manage thread exits, it becomes less and less suitable for running embedded in an IIS worker thread or the ActiveServer engine. The same thing happened to Python and Tcl, and they also dropped their ActiveServer modules. Visual Basic is the last non-threaded ActiveServer language.
As a follow-up on this migration topic, I’d like to share what I’ve done for our immediate need. I’m almost finished migrating all of our legacy apps for WS2016.
I used CGI.pm to migrate, but I’m not writing a “CGI” app. I’m using the CGI module to read inbound parameters and write the header back to the UI. I’m not using any other features of the CGI module, because the app already does its own output and formatting.
The primary migration needs were that I took the index.asp and made it a .pl file while just changing / removing all of the ASP trappings. PerlScript also allows an “include” that apparently puts the include file code directly into the referencing PerlScript file, so those includes needed to be modified to be Perl modules.
The rest is changing PerlScript specific references to standard Perl references with the bulk of it being these 4 replacements.
$main::Request->ServerVariables((.*?))->item
Becomes:
$ENV{$1} (using the $1 from the pattern above)
$main::Request->form((.*))->Item()
Becomes:
$args{$1} (I build an “args” hash from the $cgi->param() data making it easier to handle)
$main::Response->write((.*))
Becomes
print $1
And lastly
$main::Server->CreateObject((.*?))
Becomes:
Win32::OLE->new($1)
There are more smaller changes, but the rest of my debugging has been because converting to CGI exposes all of the problems that were swallowed by the PerlScript framework such as using undefined variables in regex or comparisons. Those warnings being thrown are now going to the browser which causes issues. But on the bright side, after migrating the first of our apps, each one after has been much faster to migrate since it’s a lot of find/replace. I’m just glad Eclipse allows Regex in its find/replace dialog.
Hi, I am also looking to migrate the application from IIS7 to IIS10 with Language=“PerlScript”.
As per the solution provided here, can we get the support for PerlScript in IIS10 by subscribing Team or Business subscription?
PerlIS was supported for IIS 6. Anything newer than that has always been “Experimental”.
The reason it is no longer shipped is that all Perls from 5.8 are threaded, and a threaded Perl is very unstable when run inside an IIS that is also threaded.