版本說明
在介紹之前先給個試驗環境的說明:
- VS Enterprise 2017 V15.9.20
- QT VS Tools 2.4.3
- QT Qt 5.12.0
爲什麼要用VS來調試Qt Creator的工程？
作爲專用型的IDE，大部分的場景下Qt Creator足夠用，而且對我自己來講我更喜歡Qt Creator，因爲其有着更簡潔的窗口，原生編輯器的字體高亮，舒服簡潔的目錄組織，更容易被讀懂的工程配置（.pro）。可以說，Qt Creator更懂Qt，誰讓是一個爹媽生的呢。雖然大多時候Qt Creator都挺好，它也是我絕大部分的時間裏用來開發Qt工程的環境，但是總有一些另外：
糟糕的調試體驗
這裏主要說Qt Creator + Cl編譯器的體驗，在使用Qt Creator + MingW的編譯器以下部分非關鍵性問題會有些改善，但痛點問題的體驗好不到哪去。Qt Creator在使用有點性格冷淡且高深（是否性冷淡我就不知道了，高深是因爲家裏管的嚴，大家都不找它玩）的調試器時，調試體驗很糟糕。小慢且不說，還能忍受（煩的時候吧，其實也不太能忍，影響我揮刀斬bug的快感）。主要有兩個問題，變量查看和單步調試。
- 變量查看。變量的查看只能在固定框中查看，不能就地查看就不能忍了，太影響效率，有時還會解析不出變量值。在調試數據量大的容器時問題就更大了，調試過程異常卡頓，而且只能查到有限的數據量，有時甚至直接放棄解析變量的值。
- 單步調試。單步調試會有代碼跳轉不按照期望的執行的情況，比如我想單步進入函數，但是調試不知道跑到了哪裏，代碼沒有任何的跳轉。注意，這裏的不是進入了庫的二進制，因爲調試進入庫的二進制也會跳轉到彙編。
分析工具支持弱
Qt Creator幾乎沒有分析工具，除了編輯器基本的代碼審查外，其他什麼也沒有。每當你遇到一起奇怪的bug時，你會想念VS的分析工具。比如我當前想分析一下CPU的使用情況。
怎麼用VS來調試Qt Creator的工程？
其實一句話就能解決的問題，第一步給VS安裝Qt插件，第二步使用插件解析.pro文件，第三步編譯工程，第四步解決當前版本VS基本必出的bug——關於QMeta…的linker錯誤，解決辦法就是把Crtl + Shift + F查找所有 “Q_Object” 宏，Ctrl + X ，Ctrl + V，保存所有，編譯，打完收工。最後這個bug是VS中Qt插件的bug，到我目前使用的版本中仍然沒有得到解決。如果就是爲了讓VS可以調試Qt Creator的工程這已經夠了，不過作爲一個有追求的工程師，下面將講解下在使用VS調試Qt Creator工程遇到的其他問題。
其他問題
VS複用build路徑
在Qt Creator中做了一個很好的示範，在編譯項目時，會在項目的同級目錄中生成默認的build路徑，以實現過程文件、可執行文件和代碼分別存放，這有利於代碼的管理。當轉到VS來調試Qt Creator工程時，使用VS的Qt插件來打開.pro文件來解析，默認的生成路徑則完全不同，而且代碼和過程文件、可執行文件都放到了項目目錄。既然我們只是使用VS來調試下Qt Creator的工程，自然不希望調完原來的項目文件夾就被污染了，我們希望複用Qt Creator的默認build路徑。
先來看一下Qt Creator生成的默認build路徑，以Debug模式生成的路徑爲例，如下圖：
然後在VS中右擊項目選擇properties，根據上圖，一層層地來設置對應的路徑以達到複用的目的：
- 指定ui_xxx.h文件位置，在Qt User Interface Compiler的Output Directory配置ui_xxx.h文件所在的目錄，即build-xxx-Debug（可以直接配置絕對路徑，下同）。
- 指定moc_xxx.h，moc_xxx.cpp文件位置，分別在Qt Meta-Object Compiler的Include和Output Directory配置moc_xxx.h和moc_xxx.cpp文件所在的目錄，即build-xxx-Debug/debug。
- 指定qrc_xxx.cpp文件位置，在Qt Resource Compiler的Output Directory配置qrc_xxx.cpp文件所在的目錄，即build-xxx-Debug/debug**。
- 指定xxx.dll和xxx.exe文件位置，在General的Output Directory配置xxx.dll和xxx.exe文件所在的目錄，即build-xxx-Debug/debug。
- 指定moc_xxx.obj、xxx.obj、xxx.pdb文件位置，General的Intermediate Directory配置moc_xxx.obj、xxx.obj、xxx.pdb文件所在的目錄，即build-xxx-Debug/debug。
- 另外還有一個特別重要的目錄Working Directory，這個路徑用來指定在IDE啓動程序時進行路徑訪問的默認位置。在我試驗的工程中，沒有使用Qt Creator的默認Working Directory，而是設置Working Directory爲.pro所在位置，而VS的Qt插件解析**.pro會在其同級目錄生產.vcxproj文件。所以Debugging中的Working Directory恰好是$(ProjectDir)，而這個宏展開就是.pro所在目錄。如果使用Qt Creator的默認Working Directory**，這裏也需要改成build-xxx-Debug/debug。
指定了上面的目錄後再次運行程序，發現已經複用了Qt Creator的做法——代碼和過程文件、可執行文件的分離，VS還是會在代碼目錄生成一些必要的VS配置，如**.vcxproj**文件、x64\Debug\qmake文件下的一些文件等，這已經無傷大雅了。
C++ IntelliSense警告去除
VS的IntelliSense是一個不錯的工具，詳細的介紹見微軟官方文檔Visual C++ IntelliSense 功能，順便說一句，中文的哦。簡單總結就是這個VS用來自動補齊代碼，並能根據收集的信息給出警告標註的工具。
在用VS來調試Qt Creator的工程時，其會給Qt工程標註大量刺眼的紅色警告，提示找不到包含的頭文件，以及找不到一些宏定義。這不影響編譯，因爲在編譯所需要查找的Include路徑已經在C/C++和Linker的Additional Include Directories給出了。這裏多插一句，兩個Additional Include Directories分別是自己代碼文件夾中擁有的頭文件和三方庫的頭文件三方庫的頭文件頭文件不在我們的項目中，我們只需要可以訪問到即可，如Qt庫的一些頭文件，同時需要指定動態連接庫的位置。
好，回到正題，如何去掉這些大量的警告呢？只需要在VC++ Directories的Include Directores中指定**$(Qt_INCLUDEPATH_)和代碼工程中所有用到的.h文件的路徑**即可。因爲該屬性默認只包含了Windows SDK的Include路徑和VC的Include路徑，而IntelliSense工具以此路徑爲依據，這是IntelliSense本身設計上欠考慮的地方，不夠插件也沒有及時地做匹配。雖然這些警告並不影響編譯，但是如果你使用VS來寫Qt工程，你會發現很需要這個IntelliSense功能。當然，作爲一個有追求的工程師，我也不容許這樣的警告出現在我的工程裏。也許你還會看到一些，比如E2512From qcompilerdetection.h 1349，且隨他去吧。據說是IntelliSense的bug，升級一下VS就好了，我樂見這麼歸因，雖然我已經把VS2017
上面的更新更完了，還是沒有解決，無傷大雅就任它去吧。