[英]Copy External Configurations to Local Projects in Visual Studio?
如果 Visual Studio 已經檢測到來自另一個項目的構建配置,那么在大約 50-100 個項目(相同的解決方案)中創建構建配置的最簡單方法是什么?
我們的團隊在幾個解決方案中使用了一組通用項目(命名空間只是“通用”)。 Common 命名空間有它自己的主解決方案和它自己的一組構建配置。 Common 的解決方案包含五個構建配置(“Debug-QA”、“Debug-Dev”等)。
每當在新解決方案(即“MyNewSolution”)中使用這些項目時,Visual Studio 都會顯示來自 Common 主解決方案的構建配置。 不幸的是,這些配置尚未在 MyNewSolution 或 MyNewSolution 的任何項目中創建。 這會在將構建配置添加到其他項目或將項目包含在這些構建配置中時產生問題,因為如果名稱已經存在,則無法創建構建配置(Visual Studio 認為它確實存在,感謝 Common包含的項目)。
我的目標是將相同的配置(即“Debug-QA”、“Debug-Dev”等)添加到 MyNewSolution 及其項目中,以便所有項目和解決方案匹配。 我能看到的唯一方法是在每個新項目上手動創建構建配置……這是一種折磨,因為 MyNewSolution 有大約 50-100 個項目。
僅供參考:我使用的是 Visual Studio 2012
這與其說是一個適當的解決方案,不如說是一種黑客攻擊,但您始終可以:
即使它不是一個非常可行的選擇,它也是一個很好的快速解決方案。
編輯:
如何從解決方案中手動刪除配置:
在文本編輯器中打開解決方案文件后,您將看到一個名為Global
的塊,其中包含部分。 SolutionConfigurationPlatforms
部分包含配置的定義。 還有一個名為ProjectConfigurationPlatforms
部分,其中分配了配置。 只需從兩個組中刪除對配置的引用即可。 如果您有更復雜的解決方案,則可能需要刪除其他引用。 這只是一個基本情況。
如何從項目中手動刪除配置:同樣,在文本編輯器中打開項目文件后,您將看到許多對要刪除的配置的引用。 C# 項目有一個以配置為條件的PropertyGroup
。 您可以簡單地完全刪除該組。 可能還有其他對文件周圍配置的引用,因此請確保正確清理所有內容。
如果出現問題,請確保您有文件備份。
如果目標配置的項目級自定義非常少,這可能是通過 MSBuild Import
元素導入到您的各個項目中的外部化配置來管理的最簡單方法。
為了允許特定於項目的覆蓋,此導入應放置在項目文件頂部附近。 例如:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\..\CommonConfig.targets" Condition="Exists('..\..\CommonConfig.targets')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
不幸的是,這需要您編輯所有項目文件一次以添加Import
. 但是,一旦完成,您就可以向導入的.targets
文件添加配置,並讓它自動傳播到所有項目。
我無法告訴您什么最適合您,但我可以根據經驗說,當您不讓 Visual Studio 編寫項目文件時,從舊解決方案空間創建包含 50 多個項目的新解決方案空間變得非常容易。 相反,您可以使用現成的第三方軟件,該軟件會讀取您提供的一些配置文件,並在幾秒鍾內生成解決方案和您需要的所有項目,所有這些都按照您需要的方式進行配置。
當您只想編譯公共項目時,相同的軟件也會生成獨立的“公共”解決方案。
當您設置項目時,正確的軟件將為您提供 makefile 提供的靈活性和功能,但您仍然可以在 Visual Studio 中完成您的工作。
我在這個角色中廣泛使用了 CMake,但用於 C++ 而不是 C#。 我對 CMake 很滿意; 我已經在 50 多個項目的環境中使用了它,這些項目的源代碼分散得非常廣泛,以至於我使用腳本來查找所有內容,以及一些作為預編譯 DLL 或 LIB 引入的第三方庫。 此外,根據我的經驗,我知道沒有什么能阻止某人為相同的源代碼同時維護他們自己手工制作的 VS 項目文件集,如果他們真的想要的話。 但當然,您可能希望自己購買最適合您環境的軟件。
將幾十個項目從手工制作的項目文件轉換為更像 makefile 的系統是一項重大的時間投資,但在需要多次重新配置或重新組合項目的環境中,我覺得投資回報相當快。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.