2012年4月25日 星期三

google chrome 遇到 javascript 的 new XMLDocument()相容性有問題

今天有一個系統, 使用 ajax 做2個下拉框的聯動. 原始碼如下:
var oXML = new XMLDocument(xURI, function() {
 ....
 }); 

發現上面的寫法似乎只有google chrome 會出錯,所以改寫成下列的寫法:
var xmlhttp = new window.XMLHttpRequest();
xmlhttp.open("GET", xURI, false);
xmlhttp.send(null);
var xmlDoc = xmlhttp.responseXML;
...


結論: 增加一個 browser 的判斷 ie/non-ie 就解決了. 也許也可以用 jQuery 來試看看, 反正是小功能, 可以正常跑出結果就好了.

2012年4月16日 星期一

C# upload file runat client 的範例

網路上 runat=server 的範例太多,
今天學習的進度是,c#上傳檔案,不是透過runat="server" 的寫法.:

using System.IO;


public bool UploadFileCollection()
{
bool returnValue=false;
string uploadPath=GetFileUploadPath() + "\\";
try
{
//HTTP Context to get access to the submitted data
HttpContext postedContext = HttpContext.Current;
//File Collection that was submitted with posted data
HttpFileCollection Files = postedContext.Request.Files;

HttpFileCollection uploadFiles = Request.Files;
for (int i = 0; i < Files.Count; i++)
{
HttpPostedFile postedFile = Files[i];

// Access the uploaded file's content in-memory:
System.IO.Stream inStream = postedFile.InputStream;
byte[] fileData = new byte[postedFile.ContentLength];
inStream.Read(fileData, 0, postedFile.ContentLength);

// Save the posted file in our "data" virtual directory.
//postedFile.SaveAs(uploadPath + postedFile.FileName);
string filename;
filename = String.Format("{0}{1}", Guid.NewGuid().ToString("N"), Path.GetExtension(postedFile.FileName));
postedFile.SaveAs(uploadPath + filename);

// Also, get the file size and filename (as specified in
// the HTML form) for each file:
Response.Write("<li>" + postedFile.FileName + ": " + postedFile.ContentLength.ToString() + " bytes</li>");
returnValue=true;
}
}
catch (Exception ex1)
{
throw new Exception("Problem uploading file: " + ex1.Message);
}

return returnValue;
}

2012年4月2日 星期一

萬一你的系統使用了 WebDB3 元件, 可是主機無法註冊COM+元件

萬一你的系統使用了 WebDB3 元件, 可是執行環境的主機無法註冊COM+元件, 或是元件裝的上去可是沒有作用, 該怎麼辦?


客戶主機: Win2008 R2 (64位元) + IIS 7.5



無法安裝的畫面:



結論:
把那一堆呼叫 webDB3 的程式碼修改回來使用傳統寫法.

Classic ASP Script Error Messages No Longer Shown in Web Browser by Default

結論: 要看到錯誤訊息, 要先在 IIS 7 裡的 "ASP" 設定 "將錯誤傳送到瀏覽器" 為 True, 並且在 "錯誤網頁" 裡設定 "顯示詳細錯誤".


In earlier versions of IIS, error messages from classic ASP scripts were sent to a Web browser, by default. Because these error messages might reveal sensitive information to malicious users, IIS 7 disables this feature by default. When your classic ASP scripts encounter an error in IIS 7, you receive the following error message by default:

An error occurred on the server when processing the URL. Please contact the system administrator.

If you are the system administrator please click here to find out more about this error.

You can customize the ASP script error message, and also determine whether to return the script errors to a Web browser. Note: As a best practice for security, you should only enable sending ASP script error messages to a Web browser on a development or test computer; returning script error messages to a Web browser can unintentionally expose more information than you intended to show.

Working with User Access Control

You need to make sure that you follow the steps in this document by using an account that has full administrative permissions. This is best accomplished by using one of two methods:

  • Log in to your computer by using the local administrator account.
  • If you are logged in using an account with administrative permissions but that is not the local administrator account, open all applications and all command prompt sessions by using the "Run as Administrator" option.

These above conditions are required because the User Account Control (UAC) security component in Windows Vista and Windows Server 2008 will prevent administrative access to IIS 7’s configuration settings. For more information about UAC, see the following documentation:

Customizing Classic ASP Error Messages

The configuration settings that you use to customize these settings are in the following list:

scriptErrorMessage
This is an optional string attribute that specifies the error message that will be sent to the browser when specific debugging errors are not sent to the client.
scriptErrorSentToBrowser
This is an optional Boolean attribute that specifies whether the writing of debugging specifics to the client browser is enabled.

You can configure these settings by using IIS Manager. To do so, open IIS Manager and navigate to the site or application where you want to enable or disable script messages, and then double-click the ASP feature.

In the list of ASP features, configure the Script Error Message and Send Errors To Browser options.

You can also configure these settings by using the command-line tool AppCmd.exe with the following syntax:

appcmd.exe set config "Default Web Site" -section:system.webServer/asp /scriptErrorMessage:"An error occurred."
appcmd.exe set config "Default Web Site" -section:system.webServer/asp /scriptErrorSentToBrowser:"False"

More Information

For additional information about the options that are available for classic ASP debugging, see the following page in the IIS configuration reference on the Microsoft IIS.net Web site:

http://www.iis.net/ConfigReference/system.webServer/asp

As an alternative to returning ASP script error messages to a Web browser, you can enable Failed Request Tracing on your server. For example, you could add a rule to trace HTTP 500 errors automatically, which the ASP engine generates when an error occurs. By analyzing the output in the Failed Request Tracing logs on your server, you can pinpoint the source of classic ASP errors. As an additional security note, Failed Request Tracing logs are not available to Web browsers, so the troubleshooting information is only available on your server. If you use Failed Request Tracing, it will also let you troubleshoot unmonitored classic ASP errors in detail without having to reproduce the errors.

Facebook 留言板