Visual Studio 2010 — vs10 C ++ $ (MyLibrary) против% (MyLibrary)
Мы используем переменную окружения, чтобы указать путь к библиотеке, которую мы используем. В большинстве случаев это указывает на выпущенную версию, но иногда на версию для разработчиков.
Во всяком случае, это работает нормально, когда я использую $(MyLib)/path;%(AdditionalIncludeDirectories) для создания приложения C ++, но я не могу открыть ресурсы проекта. Тем не менее, когда я использую %(MyLib)/path;%(AdditionalIncludeDirectories) оно работает.
Теперь, в чем разница?
Я думал, что правильный путь заключается в использовании $(EnvVar) но для редактора ресурсов это не похоже на работу. И если $(EnvVar) правильный путь, то почему Visual Studio использует %(AdditionalIncludeDirectories) и не $(AdditionalIncludeDirectories)
Я получаю ошибку: fatal error RC1015: cannot open include file 'afxres.h'.
Решение
Вы используете% (item) для ссылки на элемент метаданных MSBuild. Использование $ (AdditionalIncludeDirectories) не сработает, если у вас также есть переменная окружения с таким именем. Так %(MyLib)/path должен разрешить просто /path,
Вы можете положить echo %(MyLib)/path в событии предварительной сборки, чтобы проверить это.
Этого, вероятно, достаточно, чтобы перестать сбивать с толку rc.exe, компилятор ресурсов. Это очень старая утилита SDK, восходящая к Windows 1.0. Он довольно темпераментный, очень требователен к параметрам командной строки и кодировке текста файла .rc. Имейте в виду, что это произошло в эпоху задолго до того, как Windows начала поддерживать прямую косую черту в качестве разделителя пути, все должны были использовать обратную косую черту еще в 1986 году.
Так что используйте "$(MyLib)\path" вместо этого, включая двойные кавычки, чтобы вы не путали его, когда MyLib содержит встроенные пробелы И вы предпочитаете вместо этого использовать страницу свойств проекта, так что есть некоторые шансы, что кто-то еще может выяснить, как правильно построить проект через 2+ года.
Другие решения