2013年4月30日

ASP.NET MVC - HTTP 錯誤 401.2 - Unauthorized

這篇也是小小品。

前幾天,朋友丟給我一個MVC的網站,說會發生401.2的錯誤,錯誤訊息如下

HTTP 錯誤 401.2 – Unauthorized

如下圖:

image

雖然錯誤訊息寫得很明顯,但還是找了很久,後來才發現,匿名驗證被停用了…

所以只要這樣改一下就好了,把停用改成啟用。

image

然後就正常了…

後記

當然,這只是其中的一個可能錯誤而已,但老實說,我找了好久XDD,所以紀錄一下,未來如果又遇到,還有地方可以找一下。

Entity Framework - 使用Code First刪除欄位時,出現"未套用自動移轉,因為這可能會造成資料遺失。"警告

這篇是小小的紀錄文。

這個問題的發生,主要是因為,當我們使用Code First時,從Entity移除了一個欄位;例如原本的Customer裡面有Tel欄位,而把Tel欄位刪除掉時,再去Update-Database就會發生這個警告,而就如小弟所說的,這其實是一個警告, 不算是錯誤,因為沒有警告,就直接把DB的Table內容砍掉,大家可能會想殺人XDD,所以這邊Entity Framework會提出警告。

警告訊息如下

未套用自動移轉,因為這可能會造成資料遺失。

畫面如下:

image

那要怎麼處理呢?

其實只要把指令改成Update-Database -Force就可以了,另外,如果想知道更詳細的,可以下Update-Database -Script -Force,這樣他會帶出T-Sql給使用者確認。

image

大致上就這樣了,總之,在使用前,還是要先確認一下,裡面有沒有重要資料喔!!

後記

結果是去裝了VS 2012語言包,才找到相關資料…中文資源真的好少阿QQ..

參考資料

2013年4月26日

Visual Studio - 將Source Code同步到GitHub

延續前一篇,我們已經透過Visual Studio把Source Code簽入到本地的Git裡面,而俗話說的好,狡兔有三窟 喔,不是,是檔案要多備份。所以這篇來介紹一下,如何透過Visual Studio,把本地端的Git簽入到鼎鼎大名的GitHub上。

( 這篇就不說明如何註冊GitHub了,如果有興趣的人,可以看這篇的前半段。 )

當註冊完後,就可以看到下面這個畫面,我們可以選擇New repository,來建立新的倉儲。

image

這裡有幾個需要注意的,基本上,名子自己開心就好,不過為了讓你(甚至別人)能看得懂,還是取一個看得懂的名子吧;接下來,只能選擇Public,如果要選擇Private則要額外付費;所以如果真的是不能對外的專案,建議用TFS雲端版吧( Team Foundation Service )。最後,如下紅字,千萬不能勾選。( 未來可能會改變,請自己注意tools的更新喔 )

要注意,目前如果勾選Initalize this repository with a README會讓Visual Studio出錯喔!!

image

完成之後,就把如下框框的位置給拷貝下來。

image

這時,我們回到Visual Studio裡面的Team Explorer,我們先按下"home”按鈕,就可以跳回首頁,然後在首頁的地方,選擇Commits。

image

這時候,會需要輸入Remote Repository的URL,如下圖,我們把剛剛拷貝的網址貼上去,並按下Publish。

image

然後會出現視窗,要你輸入GitHub的帳號密碼。

image

完成之後,就可以看到以下的訊息,告訴你已經完成了!!

image

這時我們回到GitHub上,並且刷新一下,就可以發現Code已經放上去了喔!!

image

就這樣,我們完成了這一個,喔,不是,完成了GitHub的部分了~

後記

其實小弟TFS和GitHub都滿喜歡的,GitHub通常小弟會建議放一些OpenSource的專案或是Demo,記得很久以前,有人曾給小弟建議,希望能把我寫的範例,放上去給大家參考,但那時候雖然有使用TFS,但畢竟TFS裡面的Code是沒辦法Public的,所以未來這部分的東西,就會透過GitHub來公開,也讓大家存取也方便;而TFS拿來當私有的專案則剛剛好,所以有需要的朋友們,也可以這樣劃分。

當然,到這邊為止,也只是很初步的應用,Git整套系統其實是很強大的,未來有機會,小弟再慢慢介紹吧~~ ( 感覺越欠越多東西…Orz… )

參考資料

Visual Studio - 將Source Code簽入到Git ( Local篇 )

隨著時代的進步,Source Code已經不再是存放到硬碟這樣的單純;要如何返回到前一個版本,如何從改爛的Code裡面救回來,就變成一個很重要的課題。

早期,除了小烏龜外,還有整個超完善的TFS,而隨著時代的演進,Git的地位也越來越重,更是Open Source屆的首席版控軟體,而隨著Visual Studio的進化,到了UPDATE 2後,更Visual Studio也開始支援Git了!!

當然,開始之前,要先升級到Visual Studio 2012 Update 2,然後再去下面著個網址下載Visual Studio Tools for Git。

(補充:這邊只安裝了Visual Studio的接口,讓Visual Studio去控制Git命令,但如果Local沒有裝Git,則還是會沒辦法運作,有興趣的人,可以直接裝GitHub for Windows 或是 Gir for Windows)

http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c

image

如果懶得打網址,也可以從Visual Studio的擴充功能中找到。

image

但不管是怎樣找到,基本上還是會下載一個Microsoft.TeamFoundation.Git.Provider.msi檔案,當然,我們只要按兩下就可以開始安裝了。

image

然後急速的安裝,這樣就完成了。

開始本地端的簽入

在開始前,要先提醒一下大家,Git的版控機制和TFS是有點差異的。Git是分散式的版控,簡單來說,版控系統無所不在!!,我們在Local會有一套版控系統,我們會把Code簽入到Local端,也就是說,本機上面就有版本控制的功能,而當撰寫得差不多時,再同步到遠端( 例如GitHub上,GitHub也是每帳號一套和Local架構一樣的版控系統,只是放在GitHub的主機上 ),而這塊就和小烏龜或是TFS有點差異,小烏龜和TFS則必須要連線後( 也就是集中式的 ),才能進行版本控制的簽入動作;但Git則是分散式的。

所以我們可以想成這樣,利用Git可以在本地端進行簽入簽出,當完成後,在同步一份GitHub,而TFS和小烏龜,則必須要連線到Server後才能簽入簽出。

了解之後,我們就試著把第一個專案,簽入到Local的Git裡。

我們首先先開啟一個舊的專案 ( 也可以建立一個新的專案 ),然後從方案總管那邊,準備把整個方案加入至原始檔控制。

image

接下來,因為我們要使用Git,所以要選擇Git。

image

很快的Git Repository就已經建立完成了 ( 這裡的Repository指的是Git存放的地方,通常簡稱Repo )。

image

接下來,我們一樣可以從方案總管找到Commit的選項,按下去後,就可以順利簽入到Local端的版本控制。

image

接下來,就會跳到Team Explorer視窗,我們可以輸入一下註解,並且在Included Changes這邊確認,那些要簽入,如果有不要簽入的檔案,例如Packages整個目錄,就可以從Included Changes的視窗拖到Excluded Changes那邊。( 不簽入Packages的原因是因為使用了NuGet的自動還原機制,所以Packages就不用刻意簽入了,此外,如果有類似bin的目錄,也記住不要簽入喔。 )最後,按下Commit就可以順利簽入了。

image

完成後,就和一般的TFS圖示沒兩樣了。

image

到這邊,本地端的簽入就算完成了!!

我們下一篇,開始介紹,如何同步到遠端!!

後記

整個Git的架構和一般的TFS還有小烏龜是完全不同的,所以在使用上,雖然有UI的協助,但還是建議去看看指令的操作,這樣會比較容易了解整個架構喔!!

參考資料

2013年4月25日

Windows Azure - 在Web Site下使用Azure SQL Database來存放Session

6/23更新 - 新做法請看這裡!!

4/30更新 - 目前小朱前輩已經提供了小弟我一個更好的做法,所以這幾天會再修改一篇出來,這篇是2010年的作法,就請大家多見諒 ( 文章出來後,會在這篇加上連結 )

很早就想把這篇補齊,但一直沒機會,剛好最近,因為要講課,所以就順便把這篇給補起來,這樣大家如果要查詢,就比較方便…

相信如果有讀過這篇( p.s 現在官方強烈建議,不要再用Azure Storage當Cache了),那可能會知道,不管是Cloud Service或是Web Site,前面都會有用到Load Balance,當然,如果後面只有一個站台,那就沒甚麼差,但如果後面有兩台以上的站台來分流,那Session的議題就變得很重要了…

而Cloud Service很佛心的準備了內建Cache來解決這部分的問題 ( 不然用Azure Cache會貴森森… ),那Web Site呢!?其實除了貴森森的Azure Cache外,還有大家常知的…沒錯!!就是使用SQL Server來存放Session!!

當然,我們不會傻傻的Web放到Azure上,但卻把Session放在陸地上…所以,這篇的目的,就是要介紹,如何使用Azure的SQL Database來存放Session!! ( 嗯,或許大家會擔心效能上的問題,但根據可靠情報指出,目前Azure 上的SQL Database都是用SSD喔!! )

( 這篇原文出處於http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx )

準備SQL Database

首先,我們當然要先去SQL Database來開一個新的SQL Server,這邊我們是要測試,所以很快的快速創建就好。

image

接下來,我們直接進入管理的畫面吧;這邊要特別特別注意,我們要從SQL Database( SQL 數據庫 )這邊點下去,然後選擇服務器那邊的超連結。這樣做的原因很簡單,因為我們等下要在Master資料庫進行作業,所以如果點了前面的ASPNETSessionTest資料庫,那等下進入管理的介面,就會無法使用轉移到Master進行管理,所以我們要從Server的地方連進去。

image

接下來,選擇管理。(大家可以發現,這邊選的就不是什麼ASPNETSessionTest了,而是整台伺服器的名稱 )

image

預設SQL Database的防火牆是沒開放的,所以這邊要允許通過。

image

接下來,輸入帳號密碼,資料庫的部分可以空白不選。( 感謝好友Terry提醒~ )

image

如果是以前,我們在陸地上的時代,我們可能可以使用ASP.NET提供的ASPStateInstall.sql來建立ASPState,但在Azure的SQL Database,則沒那麼容易,因為SQL Database有許多的權限是不可以執行的,所以如果用原本的作法,會碰到釘子,所以我們要利用官方提供給我們的,修改過的版本。

下載位置在這邊

然後,我們就可以利用下載下來的這兩個sql,來建立必要的東西。

建立

當進入管理介面的時候,我們就可以點選選取資料庫。

image

我們這邊先使用master。

image

之後,我們選擇開啟,然後就可以選擇剛剛下載下來後的其中一個檔案ASPStateInstall.sql。

image

打開後,其實也就只有這樣,但不管怎樣,我們還是執行吧。

image

執行完成後,我們要切換到剛剛建立好的這個db (ASPState)。選擇資料庫後,就可以找到ASPState,然後點一下後,就會出現小圖可以選,選擇"摘要"後,就可以進去管理。

image

這邊的步驟,就和之前的一樣了。只是這次選擇了InstallSqlState.sql。

image

這次的東西就很多了,一樣按下執行。

image

到這邊,SQL Database就準備妥當了。

ASP.NET的修改( MVC同 )

其實修改非常的簡單…如下圖,只需要到Web.Config裡面的SessionState那邊,改成SQL Server的設定就可以了。

( 如果Web.Config沒看到SessionState,可以安裝ASP.NET Universal Providers,但查詢的時候可能會找到ASP.NET Universal Providers Core,其實Core是ASP.NET Universal Providers的底層核心,當安裝ASP.NET Universal Providers的時候,就會順便把ASP.NET Universal Providers Core裝起來,並且順便修改Web.Config;但如果直接裝Core,則不會協助幫忙修改Web.Config,變成要自己在Web.Config加上後面的那段程式碼。 )

image

這邊貼上原始碼,方便大家複製貼上。

    <sessionState mode="SQLServer"
    sqlConnectionString="Server=tcp:klm4dkemn2.database.windows.net,1433;Database=ASPState;User ID=sky@klm4dkemn2
    ;Password=P@ssw0rd;Trusted_Connection=False;Encrypt=True;"
    cookieless="false" timeout="20" allowCustomSqlDatabase="true" />

完成後,我們就可以用一些瀏覽器的工具,來查看Cookie裡面紀錄的Session ID。

image

透過我們建立起來的ASPSTATE這個資料庫,我們也可以從裡面看到,已經有對應的SessionID了,所以可以確定,這樣就已經把SESSION存放到DB裡面去了。

image

這樣就完成了~

後記

現在透過Web Site,其實整個機制就和一般使用IIS一樣的方便,而且Azure DB的效能也好很多,有興趣的朋友可以試驗看看喔!!

參考資料

2013年4月18日

SQL Server - 安裝StreamInsight 2.1

這幾天,因為公司的需求,所以研究了這一個國內極度冷門,而且還不是我領域的東西…( SQL Server領域…),不過雖然是屬於SQL Server領域,但這個東西還是屬於程式開發者的東西,所以公司非常的看重(!?)我的情況下,就把這個case丟給我了…,所以就順便紀錄一下。

對於StreamInsight有興趣的朋友,也可以參考官網

在開始前,小弟我先付上一張MSDN官網提供的架構圖,好的,我相信只有圖的狀況下,大家應該還是看不懂XDD,其實StreamInsight這個東西很簡單,就是一個input和一個ouput;而透過input來輸入不同的數據,經過中間的處理後,ouput成有用的東西!!

好,我相信以上解釋得很爛,所以舉個例子吧,比如有一個Azure的Server ( 硬要扯到Azure XDD ),我們要去監控目前的CPU使用率,當超過80%的時候,就Alert通知管理者。

CEP 的架構概觀

所以如上圖,我們的Input(左邊),可能就透過Azure提供的cpu數據,不間斷的每秒送出資料到StreamInsight(中間),而中間經過Linq的處理(是的,就是透過Linq來將資料處理),就可以把超過80%使用率的資料,送到管理者(右邊,可能存到db,或是寫到log檔)。

當然,這樣其實也沒甚麼,但StreamInsight真正神奇的地方是,輸入的資料是經過處理的,所以我們可以利用StreamInsight來取得五秒內cpu平均是多少,或是5秒內最高的使用率是多少(使用Linq去做篩選與計算),而最後,吐出這些資料!!

神奇嗎??但這篇不會提到怎麼寫這個程式…這篇只會提到安裝,所以有興趣的朋友們可以先參考官網,其實滿簡單的。

聽完心癢癢後,想要使用StreamInsight!?,但要注意的是,你必須要有SQL Server的金鑰,不然只能使用180天,而比較特別的是,雖然需要金鑰,但SQL Server 2012 執行個體是不需要安裝在電腦上。

如果有興趣,就去這裡下載吧!!

下載有分Client和Server端,我們當然是先下載Server端。

image

然後就一步一步安裝了~~

image

安裝到一半,就會出現讓人不知所措的畫面…Orz…其實StreamInsight 允許在同一部電腦上安裝多個版本。

而用來區分的方式,就是執行個體的名稱,最特別的是, 每個安裝的版本也都支援多個執行個體。

版本和執行個體名稱都是用來識別每個 StreamInsight 執行個體的安裝目錄和登錄機碼。 當您連接到 StreamInsight 伺服器時,也必須提供執行個體名稱。

所以,這邊要輸入一下執行個體名稱。

image

接下來,請翻出SQL Server的金鑰吧~~

image

接下來,我們要勾選以下兩個,剛勾選使用Windows服務的時候,預設會使用 Windows NetworkService 帳戶當做此服務的登入帳戶,當然,之後也可以自己去改;第二我們要把目前使用者加入到StreamInsight User群組(真實的群組為StreamInsightUsers$MyInstance MyInstance為剛剛給的實體名稱。),這樣這個群組中的使用者才可以連接到發行的 StreamInsight 伺服器。

image

然後就開始安裝了。

image

基本上,安裝的速度,絕對比小弟我重新下載SQL Server的iso,去尋找金鑰的時間還來的快…,但安裝完後,目前StreamInsight需要使用到SQL Compact Edition 3.5來當作中繼資料存放區,所以還要安裝一下SQL Compact Edition 3.5 sp2。

image

至於這個東西要去哪裡找呢?其實安裝玩StreamInsight時,就會自動地把msi也準備好了,大家可以到C:\Program Files\Microsoft StreamInsight 2.1\Redist找到msi,不過比較詭異的是,要安裝x64..還要先安裝x86版本- -…

另外,內附的版本是英文版,不過目前也幾乎沒用到SQL CE了,所以我也懶得特別去找中文版…

image

於是,我們先安裝x86版本…

image

接下來安裝x64版本…

image

到這邊,就算完成了!!

後記

很抱歉,最近真的忙到翻掉,所以沒空把這個範例在整理上來,如果對此有興趣的人,可以去參考官網,目前都有中文的喔。

參考資料

2013年4月2日

Windows Azure - 在Cloud Service中,使用多個Instance會導致IIS Express錯誤

這個問題,卡了我超級無敵久,可以說從去年12月開始,就出現了這個問題,直到最近,才終於請Microsoft的CSS部門的Michael幫忙解決…

至於為什麼會發生這個問題,老實說,也沒辦法還原了,只能歸咎,可能因為平常裝了太多測試版本的東西而導致。

這個錯誤大致上是這樣子的,平常我們在本地端使用Cloud Serivce開發時,會啟用IIS Express並帶起模擬器,平常使用都沒問題,但當我們啟用超過一個instance的時候就會發生錯誤;如下圖設定時,再啟用模擬器的時候,就會發生錯誤。

image

當設定一個instance以上,並啟用偵錯的時候,正常應該是開開心心的看到模擬器起來,但這次的問題就是,模擬器雖然起來了,但是IIS Express報錯了…

會出現 IIS Express Worker Process 已經停止運作…然後任何的錯誤訊息都不給我 ( 翻 )。

IIS Express Work Process Error

當然,這個過程,其實也找了很久,而且如果開模擬器來看,也會發現兩個Role阿,很正常啊。

Azure Computer

但實際上,如果有真的去測試,會發現,只會進到一台Role,死都不會進入到另外一台Role…後來抽絲剝繭,終於發現一個明顯的錯誤,如下圖;我們可以發現,原本啟用兩個Instance,應該會出現兩個站台才對,但這邊才出現一個站台。

IIS IP Error

或許這樣感覺不出來,所以我用Azure的VM,建立了一台正常的機器來比對;如以下兩張圖…可以發現到甚麼!?嗯,沒錯,第一個是少了站台,第二個是IP位置不同!!?

IIP IP Correct 1

IIP IP Correct 2

當然,我產生的第一個疑問是,為什麼正常的機器上,IP位置是127.255.0.0和127.255.0.1,後來查了文發現,原來現在的Azure SDK已經改成127.255.0.0和127.255.0.1的方式來區分不同的站台,而非以前用port來區分 ( 據說是1.5就改了,完全沒注意阿= =||| );另外,雖然站台的ip不同,但瀏覽器還是會顯示出127.0.0.1。

當發現這個問題,當然就是又驚又喜,想說已經查出問題,可以解決了,但實際上,根本沒那麼簡單QQ…

找到這個問題後,小弟我第一個想到的就是,既然是IIS Express的問題,那能不能從Visual Studio的建置過程Log,查到一點蛛絲馬跡,結果翻到眼睛快脫窗,終於找到這行,下圖可能沒有全部擷取到畫面,但細節大概是這樣。

Starting process 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\v1.8\Debugger\WindowsAzureDebugger.exe' with arguments '"C:\Program Files\IIS Express\iisexpress.exe" /trace:error /config:"C:\Users\San.Sky\AppData\Local\dftmp\Resources\6413450b-a6af-4534-a5ae-9b3775b20072\temp\temp\RoleTemp\applicationHost.config" /site:"deployment18(23).WindowsAzure1.MvcWebRole1_IN_0_Web"'...
'WaIISHost.exe' (Managed (v4.0.30319)): 已載入 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Net.Http\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Net.Http.dll',並略過載入符號。模組已最佳化,並已啟用 [Just My Code] 偵錯工具選項。
Starting process 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\v1.8\Debugger\WindowsAzureDebugger.exe' with arguments '"C:\Program Files\IIS Express\iisexpress.exe" /trace:error /config:"C:\Users\San.Sky\AppData\Local\dftmp\Resources\4ef06da0-aee0-46cc-a10b-3fa06f73b6ef\temp\temp\RoleTemp\applicationHost.config" /site:"deployment18(23).WindowsAzure1.MvcWebRole1_IN_1_Web"'...

偵錯

所以可以上面看到,IIS Express的建置指令… ( Orz…也順便把IIS Express的建置過程給學會了… );而也從這邊看到,IIS Express的設定檔位置。

所以繼續追進去,把裡面的一些log看過一遍 ( 眼睛又脫窗了一次… ),這次,終於發現,設定檔有錯誤了!!如下圖。

applicationHost Error

正確的應該是長這樣。

applicationHost Correct

燈燈燈,所以可以發現,是在建置過程中,產生的設定檔發生錯誤;而為了證實,真的是這個設定檔的問題,我還把整個產生出的IIS Express設定拷貝一份,並且重新用IIS Express來Run一次,結果發現是可以的!!

後來我又把錯誤的設定檔用IIS Express跑一次,就產生了IIS Express的錯誤,所以,真正發生錯誤的點就是IIS Express的設定檔,而原因就是因為兩個站台用到同樣的IP和Port!! ( 我要用紅色字,代表我的激動XDD )。

所以我們來整理一下發生錯誤的原因,當Visual Studio開始偵錯的時候,會產生給IIS Express用的兩個設定檔,而不知道甚麼原因,設定檔的內容,都是指向port 81和localhost,所以用一個Instance起得來,但用兩個Instance,就會因為IP和Port相衝,而產生錯誤!!!

好,知道原因後,我懷疑是不是Azure SDK封裝Cloud Service的問題,但經過測試,和移到正常的機器測試等等,都沒有問題;所以可想而知!!!!

是的…我卡關了XDDDD

後來也是過了好幾個月後,問了Michael,後來Michael也查到一些資料,解法是要註冊碼去改值

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\10.0\SP的值改為10。

如下圖。

image

改完後,很神奇的,就沒發生了…,就這樣,雖然不知道原因,但至少解決了多年的困擾…

後記

後面連結,有給一些國外針對此問題的解法和看法,還有整個Azure模擬器的建置過程( 我還沒看就是了XDD,有空再來補成一篇 );當然,這個問題,有可能歸咎於小弟我安裝了過太多的Azure SDK,或是裝來裝去,裝了一堆的CTP、Beta、等等開發中版本,才發生這樣的問題,但這個過程還是滿有趣的,所以也在這邊記錄下來。

最後,過了半年,很多朋友也覺得我很神奇XDD,案發現場能保留那麼久…但說真的,我相信只要不放棄,就一定可以找到原因 ( 至少是解法~~ ),所以,如果有發現問題,也不要輕易放棄喔!! ( 其實是我懶得重灌= =… )

參考網址