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.