Problem loading RPT in web page on Windows Server 2016 - works on development

[former_member563135]

Greetings:

Has the ReportSource behavior changed on Windows Server 2016, or is it affected by a possibly hardened server, or could it be antivirus?

I have code that on my development machine that previews RPT reports on a web page fine, but the very same application on a Windows Server 2016 box fails with a message

....RPT' is a physical path, but a virtual path was expected.

The file name looks like:

<vol>:\\<HttpRuntime.AppDomainAppPath><ApplicatonDirectory><RPTFileName>

created like so:

(all the RPT files reside in directory Crystal directly below the app main directory...)

var crDir = CRYSTAL_REPORTS_DIR.Replace("~", "").Replace(@"/",@"\").ClearPathDirVolSeparators();

var fi = = Path.Combine(crDir , rptFileName);

which results in: Crystal\\SOME.RPT

rptFilePath = Path.Combine(HttpRuntime.AppDomainAppPath, fi);

which results in a typical Windows name with full path

d:\inetpub\wwwroot\KDOTBLPTEST\Crystal\KDOTBLP_SIA_BATCH.RPT

which thern becomes the ReportSource for a CrystalReportViewer control

crystalReportViewer1.ReportSource = rptFilePath;

The ReportSource object type is

CrystalDecisions.ReportSource.NonHTTPCachedReportSource

so on the server, assigning this file to

KABOOM!

and the file name in the exception error message looks like:

d:/inetpub/wwwroot/KDOTBLPTEST/Crystal/KDOTBLP_SIA_BATCH.RPT

which is converted as you can see to use forward slashes????

Development Environment:

Windows 10 64-bit

Visual Studio 2017

.NET Framework target is 4.5.1

Internet Information Services 10.0.16299.15

CrystalDecisions.Web, Version=13.0.3500.0, Culture=neutral, PublicKeyToken=692fbea5521e1304

Crystal Reports patch 22

(Oracle database vis ODBC in this case)

Server Environment

Windows Server 2016 (reports as Windows 10 in IIS Manager About box) - 64-bit

.NET Framework 4.5.2

Internet Information Services 10.0.16299.15

CrystalDecisions.Web, Version=13.0.3500.0, Culture=neutral, PublicKeyToken=692fbea5521e1304

Crystal Reports patch 22

All this works on development machine but on the server running Windows Server 2016, the very same code does not work and returns the error. This does not appear to be a 32-bit vs. 64-bit issue, which I did have but apparently resolved. The .NET FW ar eonly different by a minor rev # (IS THAT THE PROBLEM?).

The CrystalDecisions.Web.dll on the server that is used shows: 13.0.22.2668 inthe file properties. The exact same dll is in the GAC as the app bin subdirectory. Both 64-bit and 32-bit runtimes are installed on the server and show this revision as well.

N.B. I gave everybody world permissions on this entire application on this server to try and eliminate directory permissions as an issue. Obviously those will have to be tightened up.

I cannot get around this. Any help is appreciated.

[former_member563135]

Is it possible this is a bitted-ness problem? Should I be referencing a 32-bit or 64-bit ODBC profile for the CrystalReportViewer ??? it does not seem to care on my development machine.

[DellSC]

Did you download and install one of the runtimes? Which bit-ness of the runtime did you install (has nothing to do with the server itself). If you installed the 32-bit runtime on the server, you need to have a 32-bit application pool in IIS to run the application.

If you're trying to build an install through VS that includes the Crystal stuff, that doesn't work. There are too many dependencies along with registry settings and other configuration that requires the "official" install media from SAP.

-Dell

[former_member563135]

Not building an installer. This is just an xcopy install. I installed runtimes for 64-bit. I was gettting a type initializer error that was because 32-bit (and old, like patch #9 ) runtimes were on the box. After installing the correct runtimes, the initializer error went away (suggesting that the bitted-ness was correct). At this point 32 and 64 bit runtimes are side-by-side. The application server and the relevant pools are configured to support 32-bit applications.

The fact that it cannot load the rpt file is just weird since the file exists, for sure... No amount of jiggering the path-to-the-rptfile creation makes any difference. Furthermore, why is the path format changed by setting the ReportSource? Is that purposeful or indicative of a problem?

System.Web.HttpException (0x80004005): 'd:/inetpub/wwwroot/KDOTBLPTEST/Crystal/KDOTBLP_SIA_BATCH.RPT' is a physical path, but a virtual path was expected. at System.Web.Util.UrlPath.CheckValidVirtualPath(String path) at System.Web.Util.UrlPath.Combine(String appPath, String basepath, String relative) at System.Web.VirtualPath.Combine(VirtualPath relativePath) at System.Web.HttpRequest.MapPath(VirtualPath virtualPath, VirtualPath baseVirtualDir, Boolean allowCrossAppMapping) at System.Web.HttpRequest.MapPath(VirtualPath virtualPath) at System.Web.HttpServerUtility.MapPath(String path) at CrystalDecisions.Web.CrystalReportViewerBase.set_ReportSource(Object value) at CrystalDecisions.Web.CrystalReportViewer.set_ReportSource(Object value) at LBIS9.ReportMaker.CreateReport(String rptFileName, Object args, Boolean preview)

So apparently on one box this exception originated at System.Web.Util.UrlPath.CheckValidVirtualPath does not occur but it does on another.