Allen's Blog: visual studio

顯示具有 visual studio 標籤的文章。顯示所有文章

2015年11月24日星期二

Solve the problem of Causing IIS Express Slow Down

[Chinese/中文]
最近我的Visual Studio 2013內建的IIS Express 實在跑太慢了，而且常常回報無服務回應的錯誤。根據此條目，看起來像是logger元件出問題。
為了解決此一問題，我們可以嘗試以下步驟：
1. 用系統管理員權限開啟命令提示字元視窗 (cmd console)
2. 輸入以下指令
(1) cd %systemroot%\system32\inetsrv\
(2) appcmd set config /section:urlCompression /doStaticCompression:True
(3) appcmd set config /section:urlCompression /doDynamicCompression:False
(4) appcmd set config /section:httpLogging /dontLog:True

[English]
Recently, my Visual Studio 2013's built-in IIS Express runs too slower and it often reports errors about no service response.
According to the thread, it seems logger component of IISExpress broken.
To fix the problem, we can try the following steps:
1. Open a cmd console with Administrator permission.
2. Type the subsequent commands:
(1) cd %systemroot%\system32\inetsrv\
(2) appcmd set config /section:urlCompression /doStaticCompression:True
(3) appcmd set config /section:urlCompression /doDynamicCompression:False
(4) appcmd set config /section:httpLogging /dontLog:True

Reference

Mike Volodarsky, "Getting Start with Appcmd.exe", Microsoft Developer Network. URL: http://www.iis.net/learn/get-started/getting-started-with-iis/getting-started-with-appcmdexe
"VS 2013 Professional - Web Dev Server (IIS Express) is very slow", Microsoft Developer Network. URL: https://social.msdn.microsoft.com/Forums/en-US/8e42baa5-38c7-4fef-b120-b0dd22ba8228/vs-2013-professional-web-dev-server-iis-express-is-very-slow?forum=visualstudiogeneral

2013年3月11日星期一

[.NET] 防止反組譯工具

由於.NET程式為了跨平台，導入CLR(Common Language Run-time)，讓所有.NET程式編成MSIL(Microsoft Intermediate Language)程式碼，使其在CLR上運作(簡單來說，就是MS版的JVM)。也正因如此，其編譯出來的程式碼，都有一定的規則可以做逆向工程，進行反組譯。

知名的反組譯工具有：.NET Reflector(要錢), ILSpy (筆者測試過，若程式碼不加以防護的話，用這套很容易把程式碼完全還原回來...) 以及Telerik的JustDecompiler

但是，在販賣軟體產品的開發人員，應該不想要讓自己的程式碼被輕易地破解吧？

就目前讀到的參考資料，可將防止反組譯方法分為以下：
1. 混淆保護(Obfuscating) ：將程式碼變數命名或是方法做混淆，或是加入無意義的文字，使其無法輕易破解。
此類工具較為知名的有微軟合作夥伴PreEmptive推出的Dotfuscastor (Community版本內建於Visual Studio，這個版本不用錢；但是Professional版要錢，此二版本功能差異請見此文章)
若想要使用此工具進行軟體保護的話，可見以下兩篇教學：
(1) Dotfucscator 使用者入門
(2) Obfuscation with Dotfuscator with Visual Studio 2010
2. Kernel等級的加密保護：使其無法用MSIL去讀取。代表工具：MaxToCode
3. 硬體鎖：採用硬體鎖的方式，避免程式盜用。(貌似跟反組譯無關)

參考資料
1. .NET反組譯工具：ILSpy, Telerik JustDecompile
2. 使用SuppressIldasmAttribute防止MSIL反組譯工具對組件進行反組譯
3. [.NET Concept][Security].NET程式保護機制概述 (Recommended)
4. MaxToCode

2012年2月23日星期四

[C#] Interface & Abstract

蒐集了一些資訊，提供給各位參考參考。

2011年12月29日星期四

[轉載] Function Pointer、Delegate和Function Object (C/C++) (template) (.NET) (C#)

Function Pointer(C)、Delegate(C#)和Function Object(C++)這三個是一樣的功能，所以在此一併討論。

詳全文請至：http://www.cnblogs.com/oomusou/archive/2007/05/02/734290.html

2011年12月27日星期二

[ASP.NET] MVC 3上，Session消失的問題與解決辦法

筆者因工作因素，不得不碰Microsoft MVC 3。雖然開發方便，不過他隱含的一些奇怪的Bug也不少。
身為一個網站開發人員，時常會用到Cookie與Session。奇怪的點就在於MS Visual Studio 2010在開發MVC 3時，有時候會為了某些奇怪因素，重新啟動你開發的Application。
目前普遍知道的重新啟動事件，可能會於以下情形發生：

從應用程式的 Bin 資料夾中加入、修改或刪除組件。
從 App_GlobalResources 或 App_LocalResources 資料夾中加入、修改或刪除當地語系化資源。
加入、修改或刪除應用程式的 Global.asax 檔。
在 App_Code 目錄中加入、修改或刪除原始程式碼檔。
加入、修改或刪除設定檔組態。
在 App_WebReferences 目錄中加入、修改或刪除 Web 服務參考。
加入、修改或刪除應用程式的 Web.config 檔。
防毒軟體剛好掃到Webconfig檔

然而，筆者最近發現兩個更奇怪的重新啟動狀況！

Application restarts on directory delete in ASP.net
檔案上傳後，在該Action內直接return RedirectToAction() ;

開發MVC 3 or ASP.NET網站人員應該都知道，在SessionState為InProc的設定下，任何重新啟動( or Application_start函數的呼叫)，將導致Session消失。

很不巧地，筆者剛好遇到上述第2種狀況，導致Session消失，Debug 10個小時才抓到此嚴重錯誤。
其實上面第 2種狀況，應該算是「 Bin 資料夾中加入、修改或刪除組件」，從下面程式碼便可知一二：

public ActionResult Access()
{
    // 取出剛剛上傳的檔名，這邊會發現取不到值
    string fileName = TempData["upfile"].ToString();
    /*                 
     *   處理的程式區段   
     */               
    return View();
}

[HttpPost]
public ActionResult Upload(HttpPostedFileBase file)
{
    //檢查是否有檔案上傳，有的話存檔
    if (file !=null && file.ContentLength > 0)
    {
        //放在執行檔目錄中Upload目錄底下
        string savedName = "./Upload/" + file.FileName;
        file.SaveAs(savedName);
        TempData["upfile"]=file.FileName;
    }            

    return RedirectToAction("Access");
}

從上述可知，由於我在檔案上傳時，"增加"了bin資料夾下的組件，導致Application_start()函數再次啟動，使得我的Session就這麼消失了。

為了避免這個錯誤一再重演，建議將Session State設定為StateServer或是SQL Server模式。

將Session State設定為State Server的方法，可看這篇「如何讓 ASP.NET 使用 Session 資料時不要再自動消失」，主要兩個步驟：
1. 啟動 aspnet_state.exe (ASP.NET State Service)
2. 在Web.config中，加入以下這段設定：

<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=localhost:42424"
cookieless="false"
timeout="20"/>
</system.web>
</configuration>

需要注意設定的Web.config檔案的出處。(不知道為什麼，筆者的View資料夾下剛好也有Web.config，若手誤設定到這個，執行會錯誤喔！)

為了追求開發出來的程式不因Application重新啟動而造成不穩定狀況 (例如：筆者遇到的檔案上傳導致無法儲存Session的問題，也是透過部署的方式，立刻解決！)。

我們通常會需要用到部署，至於設定部署功能，請跟著筆者這樣子做：

請先安裝好IIS 6/7
若是使用ASP.NET 4.0，ASP.NET 4.0的安裝程式，不會連同IIS一起設定，因此，請按照此方法設定。
從IIS中，設定好網站目錄 or 虛擬目錄。
設定單鍵發行功能，方法請看如何使用 Visual Studio 2010 的「單鍵發行」功能 (MsDeploy)

另一個可能發生的問題，則是在負載平衡的 Web 伺服陣列環境執行 ASP.NET Web 應用程式時，如果使用 SqlServer 或 StateServer 工作階段模式，工作階段狀態可能會遺失。
解決辦法在微軟的「PRB：如果您使用 SqlServer 或 StateServer 工作階段模式，Web 伺服陣列中的工作階段狀態會遺失」，剛好遇到這類問題的使用者，可以看一看。

Reference

2015年11月24日 星期二