The unsuccessful request and what this refers to can be traced in the Network tab of the browsers Developer Tools (F12). If the browser in which the preview is opened cannot access the aspnet_client folder, then a blank preview dialogue will open. If the application is notĭeployed in the IIS default website, then the aspnet_client directory can be copied to the corresponding website.
The resources (HTML, JavaScript and CSS) which the Web GUI needs for the preview of reports. Naturally, the installer would need to make the same choice, either during the install (if you're using a unified installer) or when you build the installer itself (if you have separate 32-bit and 64-bit installers).Service pack 26 and above are currently incompatible with all Thinkwise products.įor the Web GUI, the Crystal Reports installation creates a new directory to IIS with the name aspnet_client. In that case, you can just reference the 32-bit version for your development work, and then configure your build script to pick the correct version of the DLL depending on whether you're building a 32-bit or 64-bit binary. NET Framework abstracts away platform-specific differences extremely well that's how they can offer an "Any CPU" targeting option.Īside from that, if I am allowed to speculate (because I have no particular experience with Crystal Reports), I imagine that the public interface is identical for both the 32-bit and 64-bit DLLs. If you write good code that follows standard idioms and recommended practices, adding 64-bit support later (if it ever does prove to be of some benefit for your case) would be a fairly trivial operation. Since you'll only be building a single binary, this would greatly simplify development and distribution efforts, not only in terms of figuring out which DLLs to reference, but also the amount of code you need to test and the distribution process itself. So to do this, you just set your project to target x86 platforms, and reference 32-bit DLLs exclusively. Visual Studio itself is an excellent example: it's still 32-bit code, but runs fine even on 64-bit versions of Windows, thanks to WOW64.
Lots of applications are deployed this way. It's entirely seamless, and there are virtually no compatibility problems to speak of. This is because all 64-bit versions of Windows include a special subsystem ( Windows-on-Windows, or WOW64) that runs 32-bit code. You can build and distribute only a 32-bit version (x86) and it will still run on all machines, regardless of whether they are running a 32-bit or 64-bit version of Windows. Most line-of-business applications (which I can assume is what you're building, since you're generating reports from it) do not really benefit from being 64-bit. You might re-consider whether you really need a 64-bit version of your application. I know this isn't technically an answer to your question, but since it still remains unanswered even after having set a bounty, I thought I might suggest it anyway…
0 kommentar(er)
