В Visual Studio 2010 создается файл.NETFramework,Version=v4.0.AssemblyAttributes.cpp, и можно ли это отключить?
Я недавно обновил до Visual Studio 2010. Теперь, когда я строю проекты, я получаю строку, которая гласит:
1> .NETFramework,Version=v4.0.AssemblyAttributes.cpp
Я узнал, что это результат нового движка сборки, msbuild.exe, но этот файл фактически создается автоматически и помещается в мой локальный временный каталог (c:\Documents and Settings\me\Local Settings\Temp). Кто-нибудь знает, почему этот файл создан, и могу ли я отключить его создание?
Кстати, мне кажется, в этом нет ничего полезного. Увидеть ниже:
#using <mscorlib.dll>
[assembly: System::Runtime::Versioning::TargetFrameworkAttribute(L".NETFramework,Version=v4.0", FrameworkDisplayName=L".NET Framework 4")];
И иногда, как сообщалось http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/15d65667-ac47-4234-9285-32a2cb397e32, это вызывает проблемы. Поэтому любая информация об этом файле и о том, как я могу избежать его автоматического создания, будет высоко оценена. Спасибо!
6 ответов
Это общее для всех языков (в C#, VB и F# тоже есть что-то похожее).
Один из способов отключить его - переопределить цель GenerateTargetFrameworkMonikerAttribute следующим образом:
<!-- somewhere after the Import of Microsoft.somelanguage.targets -->
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
в вашем файле проекта.
Взгляните на c:\program files\msbuild\microsoft.cpp\v4.0\microsoft.buildsteps.targets. Он содержит цель GenerateTargetFrameworkMonikerAttribute, которая генерирует файл. Элемент Condition определяет, когда он выполняется, значение GenerateTargetFrameworkAttribute является значением. Это всегда будет верно, если в настройках проекта запрашивается сборка / clr. Комментарий в цели очень вводит в заблуждение, шумиха по поводу предварительно скомпилированных заголовочных файлов не имеет ничего общего с целью цели.
[TargetFrameworkAttribute], который он генерирует в вспомогательном файле.cpp, важен, он сообщает CLR на машине, на которой запускается программа, какая минимальная версия.NET должна присутствовать для успешного выполнения программы. Его основное назначение - автоматический запуск установщика нужной версии.NET, очень приятная функция.
LNK4221 распространен и не имеет зубов, его можно игнорировать. К сожалению, компоновщик не обеспечивает документированный способ подавления предупреждений, основная проблема заключается в том, что он не может быть достаточно конкретным, чтобы подавлять только это. Подавление вспомогательного файла.cpp потребует редактирования файла.targets и нарушения функции автоматической установки, я не могу этого рекомендовать.
Я решил эту проблему с помощью следующих шагов:
- Чистый раствор
- Закройте решение
- Введите команду запуска
%temp%удалите все файлы - Откройте решение, щелкнув файл решения проекта в папке, в которой был сохранен проект.
Перестройте один из проектов. Затем закройте Visual Studio 2010 (да, всю среду разработки), а затем снова откройте файл решения.
Похоже, что при восстановлении воссоздается отсутствующий файл, но Visual Studio этого не замечает, поэтому вам нужно закрыть его и открыть заново, чтобы он снова правильно увидел файл.
Во-первых, ответ @Brian исправляет состояние, и я дал 4x+1 для других полезных ответов, которые помогли в быстрой диагностике и решении проблемы, с которой я столкнулся.
Хотел включить дамп проблемы, которую я диагностировал в моем контексте, основываясь на этом.
Эта функция синтезирует исходный файл на языке проекта, который создает assembly:атрибут в поток компиляции.
Этот файл / процесс необходим, когда WAS или другие хостинговые среды должны иметь возможность определять целевую среду и другие подобные случаи. Пример статьи MSDN (касающийся использования с WAS). Это только атрибут, поэтому он инертен и не о чем беспокоиться...
В случаях, когда такая уверенность не вступит в игру, это становится более интересным. Помимо избыточности, создания больших двоичных файлов и нагрева процессора, в TeamCity процедуры очистки при настройке для инкрементных сборок удаляют этот файл перед повторной сборкой. Однако, к сожалению, побочным эффектом является то, что проверка зависимостей сборки неверно делает вывод о необходимости перестройки, как показано в этом примере сообщения при включении регистрации с указанием /v:d[Etailed]: -
[CoreCompile] Входной файл "C:\BuildAgent\temp\buildTmp.NETFramework,Version=v4.0,Profile=Client.AssemblyAttributes.cs" новее, чем выходной файл "bin\Debug\DLLNAME.xml".
Суть в том, что CSC вызывается ненадлежащим образом (и в нашем случае от этого происходят существенные последующие эффекты)
Другие заметки:
Нужно заглянуть в MS Targets, чтобы увидеть, относится ли это только к конкретным профилям [как указано в ответе @AlainA] (мой конкретный случай - использование клиентского профиля.NET 4.0).
Как показано в приведенном выше сообщении, одна тонкость, которая может быть связана с этим, заключается в наличии или отсутствии документов XML, что имеет место в моем контексте.
Закрыть VS
Откройте каждый файл.vbproj с помощью блокнота и удалите следующую строку:
Все кончено!
Файл предназначен для встраивания атрибута сборки.NET TargetFrameworkMoniker. То есть (в будущем) поможет хостам корректно работать с соответствующим CLR. (Извините за неопределенность, я не могу вспомнить, чтобы кто-то еще был экспертом). То есть, на самом деле есть причина для этого:-)
Я не знаю, почему есть предупреждение - изучать его.
Dan / MSBuild