Can I use the runtime installation for IIS

Before the new state tool method, we just installed ActivePerl and set up IIS to use the perl.exe.

With this new runtime install, the perl.exe is installed in C:\Users\user\AppData…

When I add this path to IIS, I get a 401 error. I assume IIS doesnt have permissions. So is the solution to just add the permissions?

Or can the state tool add new packages to the traditional C:\Perl64 location?

Hi there, I’ll check in with the State Tool team and get back to you when I’ve got an answer.

Cheers,
Luke

You are correct. If a State Tool installer is used, a system service like IIS will be unable to access the virtual environment under a user’s folder. State Tool is intended as a developer environment.

For production use, a “classic” installer with MSI or Exe format will result in an installation to the traditional folders, and IIS can be configured so that it can use that folder. For testing and development of services running Perl the classic installer is also the way to proceed.

So how would I add packages/modules to a production type installation? Am I required to build another .exe or .msi installer package then re-deploy?

Correct. The State Tool can only add modules to builds installed with the State Tool and in a virtualized environment.

Hi Support,

I need an MSI Installer in order to install ActivePERL on a server that uses IIS, but this server has no direct internet connection, so I cannot use the Powershell script. Anyway, I need to install ActivePERL to C:\PERL because of the usage with IIS.
In case you are not going to create an MSI, please tell me so that I have to look for another PERL version from another mother.

Thanks in advance

Kind regards,
Frank

FYI,
ActivePerl hasn’t officially provided support for use with a version of IIS since IIS 6.
The ActiveScripting engine Perl variant is dead.
The PerlEX engine Perl variant is dead.
The isapi engine Perl variant is dead.

ActivePerls are no longer significantly forked from the upstream open source version of Perl.

What’s left now for use with IIS is the same as what worked with the open source version of Perl, which is not very much. The Perl community has been working with Apache, and later with Nginx, and current best Perl practice is to use a framework like Catalyst or Dancer on one of those. IIS can’t do that, and what’s left is GCI and maybe fastCGI. It is very hard to find any documentation on how to set up either of those with current versions of IIS.

Thanks for the response.
This info helped me alot.

Best regards,
Frank