在 .net framework 的 Web API 專案中.

安裝某些套件時, 會在 Startup.cs 中增加一行:

app.UseWebApi(config);

這個會在 WebApiConfig 的 Register 之後執行. 造成 WebApiConfig.Register 失效.

解決的方法是把 WebApiConfig.Register 的指令全部搬到 Startup.cs 之中, 放在 app.UseWebApi(config) 之後即可...

這大概是為什麼 .Net Core 之後的設定都在 StartUp.cs 裡面的原因..

花了一些時間 : (

1. 安裝 Failover-Clustering

Install-WindowsFeature Failover-Clustering –IncludeManagementTools

2. 建立 Cluster 用的帳號, 並加入管理員群組 (記得要換密碼

net user /add clustadm Sup33P@ssw0Rd!

net localgroup administrators clustadm /add

參考以下四篇文章, 有些地方可能要改一下, 有空來做一份中文版的.


https://www.mssqltips.com/sqlservertip/4951/deploy-a-windows-server-2016-failover-cluster-without-active-directory-part-1/
https://www.mssqltips.com/sqlservertip/4962/deploy-a-windows-server-2016-failover-cluster-without-active-directory--part-2/

https://www.mssqltips.com/sqlservertip/4991/implement-a-sql-server-2016-availability-group-without-active-directory-part-1/
https://www.mssqltips.com/sqlservertip/4996/implement-a-sql-server-2016-availability-group-without-active-directory-part-2/


這個也可以參考, 有很多指令碼, 可以省不少時間:

http://woshub.com/workgroup-failover-cluster-windows-server-2016/

今天因為一個客戶的專案, 試了一下用 Entity Framework 把 Store Procedure 包成一個 function. 被卡了一下, 發現要先 Compile  才會看到新增的 function,  記錄一下, 希望看到的人能省點時間 .....

1. 從資料庫更新模型


2. 選擇要匯入的 Store Procedure


3. 完成匯入匯入後, function 並不會生出來. 
 
 4. Compile 之後, 才會看到這個 function.
 
 


 

好像為了這個找了很多次 google, 每次都花了不少時間..

1. 新增功能角色
 
2. 新增管理服務
 
3. 安裝 Web Deploy 套件 
https://www.iis.net/downloads/microsoft/web-deploy

4. 完工..

參考: https://stackoverflow.com/questions/41386690/missing-import-web-application-option-in-web-deploy-3-6

AddPageDebugMessage 造成購物車變慢.

因為有發現主要時間是花在 Coupon 的處理, 研突了半天, 覺得之前丟出來的 Debug 訊息太多, 所以我想把所有 coupon 處理時丟出來的 Debug 訊息關掉, 一個一個慢慢打開來看看哪一個步驟造成問題. 突然發現它就好了.

後來想想, 應該是因為我們把 Debug 訊息合併成大字串造成的, 這個花費的總時間會以 coupon 數量的平方或三次方的速度成長.  當 Coupon 的數量變多時, 花費的時間會成長的很快. 因為要夠多上線的 coupon 才會造成這個問題, 所以之前的測試都沒有發現這類的問題.

購物車中有用到 AddPageDebugMessage 請改成成使用  arraylist 的版本. 理論上會是固定時間, 另外還有做了一個開關, 要用定參數才會開啟 AddPageDebugMessage 的功能.

這兩天發現的現象。有點不好找錯，所以紀錄一下
因為制式報名頁面使用 ajax form 物件，但 ios 的 safari 一直發生資料有送出，
但是送出後網頁就不跑success後面的 javascript，例如彈跳訊息及導到下個頁面
一開始debug的方向有點猜錯，所以花了點時間找問題
後來才注意到，原來他跑到 ajax error去了，不是 ajax success
直覺可能是 ContentType 的問題，因為預設是 text/html
結果 Response.ContentType 改 application/x-javascript, 就過了  (WTF)
我猜 application/json 應該也沒問題吧
------------------------------
經查證: application/json 比較正確 



 

注意事項 (為避免產出結果和預期有重大差異, 請詳讀以下內容):

1. 若後台有使用 HTML 編輯器, 以 CKEditor 現有功能為準. 編輯器所見內容和前台實際內容可能有差異, 此為無法避免之情況, 請僅慎使用, 建議以文字模式編輯, 以避免跑版.
2. 驗收以 Chrome, IE, Safari, Firefox 結案時間的最新兩個版本為準(IE 目前為 IE Edge 及 IE 11). 手機以前 10 大廠牌兩年內出版的手機為準.
3. Android 手機僅測試 Chrome, IOS 手機僅測試 Safari. 其它手機預設瀏覽器或 APP 內建流覽器不包括在驗收範圍之內.
4. 若需要文件, 除報價有說明外, 應另外計費, 若合約中包括程式檔案說明, 僅限我方建立之程式檔案, 引用之公開套件不另做文件說明.
5. 若客戶要求資安弱點掃瞄, 或通過特別認証, 應另外計費.
6. 本公司盡力維護程式品質, 但無法保証無 Bug, 上線前請完整測試. 若上線後才發現之 Bug, 本公司僅負責修復, 無法提供額外賠償.
7. 主機代管限制
    圖檔以經 Cloudfalre 為準. 若需更高品質可代為申請 amazon 的 CDN 服務.
    Email 不保証送達, 若需更高品質可代為申請 amazon 的 SES 服務.
    每月 1000 張訂單為限, 超過後要另外計算費用.
8. 網站代管, 資料備份以一天一次為準, 如需增加頻率, 另外協議後計價.
9. 搜尋建議使用 Google 的 site search(但偶爾會有廣告, 出現機率很小), 若要自行客製, 合約未明確規定時, 以各單元分開搜尋為準, 例如產品及新聞的搜尋結果會分成兩個搜尋結果頁面, 排序為依等定欄位排序, 比對方式為所輸入的文字明確比對.

由於早期網站都是VB.net寫的，若是直接換成 C#，就會耗費很多時間在轉換程式上
因此 ASP.NET 特別可以在同一網站同時寫 vb 跟 C#，方式是在 web.config compilation 加上設定

    <compilation debug="true" defaultLanguage="c#" targetFramework="4.0">

     <codeSubDirectories>

        <add directoryName="VB_Code"/>

        <add directoryName="CS_Code"/>

     </codeSubDirectories>

    </compilation>

也就是 VB.NET 的 code 就放到 ~\APP_Code\VB_Code 目錄
C# 的 code 就放到 ~\APP_Code\CS_Code 目錄
這樣做有兩點要注意
1.  Namespace 的命名，最好不要互相衝突, 要能夠區分出來
2.  VB_Code 與 CS_Code 放的位置有很大的影響, 因為牽涉到 compiler的先後順序，因為 VB_Code 在 CS_Code 在前面，所以 CS_Code可以叫用 VB_Code下的程式，但是 VB_Code 卻不能叫用 CS_Code 的程式，如果希望 VB_Code可以叫用 CS_Code的程式，就把設定換過來

    <compilation debug="true" defaultLanguage="c#" targetFramework="4.0">

     <codeSubDirectories>

        <add directoryName="CS_Code"/>

<add directoryName="VB_Code"/>

     </codeSubDirectories>

    </compilation>

缺點就是反過來 CS_Code不能使用 VB_Code的程式

基本上，若是舊的程式碼都在VB_Code 那就把 VB_Code 放到前面

2016 / 10 / 30 搬機房, 有幾件事沒有做好, 記錄一下:

1. Firewall 沒設定好, 下次要一中兩個人一起設定.

2. 有一個客戶的 DNS 等了一整天才生效, 要檢查所有網站的 TTL 和  Refresh 時間, 最好都在一個小時以內.

3. Email 主機: 有些客戶原來是用 msa.hinet.net 這個 SMTP, 搬到非 Hinet 的機房後就不能寄信了.

4. 某一個客戶的 DNS 沒改好, 因為在自已的 DNS Server 上面看到有記錄, 就誤判是我們代管的, 應該要用 Hinet 或 Google 來確認 NS Record 為何. 已刪除它的 DNS  記錄.

5. 202 的 .8 網路線沒插好, 主機開起來後, 要確認可以從每一個介面 Ping 出去.

6. 新 Firewall , 內部 IP 無法連到 Virtual Server: --> 要由內部 IP 連線到 Virtual Server 測試. 最好是在 hosts 上面都有 127.0.0.1 的設定.

7. 最好不要在下半年換機房, 比較忙, 客戶的活動也比較多.

8. Windows 的 DNS 若是直接修改 DNS 檔案. 因為 SOA 的序號沒有修改, 所以 Client 伺服器要手動重新讀取資料.

9. 要記得改 TWNIC 的 DNS Server設定.

對於網頁加速的問題，已經被廣泛的討論了
主要在於減少 request 數以及減低網路傳輸的時間
也因此發展出一些技巧或技術，例如 css sprite, 資料gzip 等
瀏覽器也把連線數限制從2條變成6條，以加快網頁顯示的速度
然而若要網頁能有本質上的提升，則是該把 HTTP 這個老通訊協定升級了
(目前是HTTP/1.1, 1999年)

由Google Chrome推廣的 SPDY 標準，已經改良並訂為 HTTP/2 的標準 (2015年初定案)
他的重點在於 (如果我理解得沒錯的話，歡迎指正)
1. http header 也可壓縮 (HTTP1.1 header 無法壓縮)
2. 一個 connection 可以傳輸多個Content (HTTP1.1 一個request 一個 content)
3. 可以 Server Push 資料
4. 可以向下相容 1.1
實測上，可以讓網頁載入速度提升約 30%

目前，大部分瀏覽器已經支援 HTTP/2 標準，然而 Server 端的步調就緩慢許多
微軟的 IIS 要到 10 才支援，目前只有 windows 10 才有
Windows Server則要明年 2016 才有支援
相反於微軟，其他非微軟的開發速度上就快多了 例如 Node.js

---------------------------------------------------------
測試上，可以用 Chrome 的開發模式 把 protocol 欄位勾選顯示



h2 就是 http/2