在Windows 2003 R2服務器上的Delphi XE5 Isapi

情況：我在VMWare工作站的WIndows 7 Pro 64Bit下開發了DelphiXE5 ISAPI Webbroker應用程序。在編譯爲32位（DelphiXE5的默認設置）代碼的平臺上進行測試是成功的。該計劃通過HTTPS與Stamps.com建立聯繫，並使用Stamps.com SOAP Web應用程序購買郵資並創建帶有有效郵票（郵戳）的郵寄標籤。在Windows 2003 R2服務器上的Delphi XE5 Isapi

郵件標籤在郵票服務器上以PDF形式創建，他們將我發回的URL用於獲取PDF並將其保存在本地SQL Server數據庫中。這個提取使用INDY 10.6.0.5040（在Indy每Remy）完成。作爲該提取的一部分，INDY SSL組件必須加載和使用OpenSSL庫。這些在測試環境中加載OK。

然後我將程序（編譯爲32位）移動到Windows 64位2003 R2服務器。該服務器是在VMWare下運行的虛擬服務器。我確信實際的硬件是真正的64位。 OpenSSL庫不會在該服務器上加載。我嘗試了最新的32位庫和最新的64位庫。相同的結果...不加載。我嘗試了那些在測試中成功加載的。他們失敗了。使用Indy WhichFailedToLoad（）函數顯示「未能加載libeay32.dll」。有趣的是，我收到了與64位庫相同的信息。即使32位和64位的庫具有相同的名稱，所以我也得到相同的消息。現在，我的具體問題是....

莫不是一個默認的區域，該庫由加載和我將它們放在同一個目錄中我的程序的DLL並沒有改變任何東西？ Indy首先進行默認設置，如果它們存在，那就是它正在使用的那個。如果是這樣，有人知道可能是哪裏。我試圖追蹤INDY代碼，看看什麼是hapening，但它跳轉到彙編程序，我不是一個ms彙編程序員。我知道IBM在我的睡眠中的大型機彙編程序，但MS似乎是向下和向後對我:-)
對於德爾福專家在那裏....應該真的被編譯爲64位應用程序，並投入生產和然後使用64位庫？在測試環境中，我運行的是64位硬件，64位主機，64位客戶，32位編譯發生。 32位庫在那裏工作，似乎它應該在W2003服務器上的生產環境中工作，因爲這是識別的，除了操作系統版本。
它可能是IIS 8.5的權限問題，不會讓我的DLL讀取或加載OpenSSL庫？如果是這樣，有什麼提示？

我有DLL在腳本目錄以及庫。

有誰知道這可以得到一份工作作爲我的備份:-) ...真的！

來源

2015-06-14 Del

由於您的程序是32位，請確保您的IIS應用程序池設置爲32位。（IIS管理器=>應用程序池=>「選擇池」=>高級設置=>啓用32位應用程序：True） – whosrdaddy

我已經完成了。如果沒有啓用，ISAPI DLL根本不會加載。該程序運行良好..它只是這一塊失敗。 – Del

您的應用程序池用戶是否有權訪問SSL庫（如果您在networkService帳戶下運行，則您沒有本地訪問權限......） – whosrdaddy

如果您的程序是32位，它使用的DLL必須編譯爲32位。

至於OpenSSL dll的位置，在我的情況下，在Win2012 R2服務器上，我把它們放在C：\ Windows \ SysWow64 \ inetsrv中。

來源

2015-06-15 09:40:16 chadkops

是的，我明白了。這些庫是32位的，因爲它們在應用程序編譯爲32位應用程序時會在測試中加載並正常工作。他們只是不會加載Win2003服務器。我會檢查SYSWOW的圖書館在那裏也.. ..感謝擊中..我會讓你知道發生了什麼。 – Del

我沒有完全相同的服務器配置。但是，當我將它放在ISAPI DLL的目錄中時，它永遠不會拿起libeay32.dll。我將它移動到SysWow64 \ inetsrv，重新啓動IIS服務，它立即工作。謝謝@chadkops。 – Tony

在Windows 2003 R2服務器上的Delphi XE5 Isapi

回答

相關問題