Пользовательское правило сборки не работает после преобразования в VS2013
Мне нужно интегрировать устаревший проект VS2008 в мое решение VS2013. Этот проект использует некоторые пользовательские правила сборки, которые изначально работали после преобразования.vcproj в.vcxproj. Однако при выполнении новой проверки проекта, включая.vcxproj, файл проекта больше не может быть открыт.
Я отследил это до этой проблемы:
Файл проекта ссылается на пару пользовательских правил сборки, таких как:
<ImportGroup Label="ExtensionSettings">
<Import Project="..\..\..\tools\build\ms_mc.props" />
(8 similar lines follow)
</ImportGroup>
Тем не менее, файл ms_mc.props отсутствует, но есть файл ms_mc.rule. Если я преобразую решение VS2008 с VS2013 (и, вероятно, также, если я открыл его в VS2008, которого у меня нет), создается файл ms_mc.props (плюс файлы.targets и.xml). Однако, если я удалю этот файл и открою преобразованный проект VS2013, файл не будет создан.
Я понял, в старом.vcproj, соответствующие строки
<ToolFiles>
<ToolFile RelativePath="..\..\..\tools\build\ms_mc.rule" />
(8 similar lines follow)
</ToolFiles>
Почему VS2008 ссылается на файл.rule, а VS2013 импортирует файл.props без указания файла.rule? И что еще более важно: как я могу сделать эту работу снова?
Файлы.rule и.props добавлены для справки.
ms_mc.rule:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="MS MC"
Version="8,00"
>
<Rules>
<CustomBuildRule
Name="MS_MC"
DisplayName="Microsoft Message Catalogue Compiler"
CommandLine="mc [Verbose] [inputs] [RCIncludePath] [CIncludePath]"
Outputs="[$RCIncludePath]\$(InputName).rc;[$RCIncludePath]\$(InputName).h"
FileExtensions="*.mc"
ExecutionDescription="Compiling Message Catalogue $(InputName).mc"
>
<Properties>
<BooleanProperty
Name="Verbose"
DisplayName="Verbose"
Description="Gives verbose output. (-v)"
Switch="-v"
/>
<StringProperty
Name="RCIncludePath"
DisplayName="RC include file path"
Description="Gives the path of where to create the RC include file and the binary message resource files it includes. (-r [pathspec])"
Switch="-r [value]"
DefaultValue=".\"
/>
<StringProperty
Name="CIncludePath"
DisplayName="C include file path"
Description="Gives the path of where to create the include header file. (-h [pathspec])"
Switch="-h [value]"
DefaultValue=".\"
/>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
ms_mc.props (после преобразования в VS2013):
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup
Condition="'$(MS_MCBeforeTargets)' == '' and '$(MS_MCAfterTargets)' == '' and '$(ConfigurationType)' != 'Makefile'">
<MS_MCBeforeTargets>Midl</MS_MCBeforeTargets>
<MS_MCAfterTargets>CustomBuild</MS_MCAfterTargets>
</PropertyGroup>
<PropertyGroup>
<MS_MCDependsOn
Condition="'$(ConfigurationType)' != 'Makefile'">_SelectedFiles;$(MS_MCDependsOn)</MS_MCDependsOn>
</PropertyGroup>
<ItemDefinitionGroup>
<MS_MC>
<Verbose>False</Verbose>
<RCIncludePath>.\</RCIncludePath>
<CIncludePath>.\</CIncludePath>
<CommandLineTemplate>mc [Verbose] [inputs] [RCIncludePath] [CIncludePath]</CommandLineTemplate>
<Outputs>%(RCIncludePath)\%(Filename).rc;%(RCIncludePath)\%(Filename).h</Outputs>
<ExecutionDescription>Compiling Message Catalogue %(Filename).mc</ExecutionDescription>
</MS_MC>
</ItemDefinitionGroup>
</Project>
1 ответ
Я нашел этот пост для VS2010, в котором говорится следующее:
Пользовательское правило сборки - это функция сборки, представленная в VS2005. Он позволяет пользователям легко подключать сторонние инструменты для использования в процессе сборки. Пользовательское правило сборки определяется файлами ".rules".
и что более важно
В VS2010 из-за перехода на MSBuild информация в файле правил представлена тремя файлами: .XML, .props и.targets.
Это в основном означает, что файлы.XML,.props и.targets фактически не создаются VS2008; вместо этого они заменяют старый формат файла.rules, начиная с VS2010. Используя эту информацию, я теперь могу безопасно регистрировать эти новые файлы, не нарушая решения VS2008. Возможно, мне придется адаптировать новые файлы вручную, чтобы они работали, как и раньше, как также упоминалось в блоге.