В Visual Studio 2010 создается файл .NETFramework, Version = v4.0.AssemblyAttributes.cpp, и можно ли это отключить?

Question

Я недавно обновился до 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, это вызывает проблемы. Поэтому любая информация об этом файле и о том, как я могу избежать его автоматического создания, будет высоко оценена. Спасибо!

Answer 1

Это общее для всех языков (в C #, VB и F # тоже есть что-то похожее).

Один из способов отключить его - переопределить цель GenerateTargetFrameworkMonikerAttribute следующим образом:

<!-- somewhere after the Import of Microsoft.somelanguage.targets -->
<Target Name="GenerateTargetFrameworkMonikerAttribute" />

в вашем файле проекта.

Answer 2

Взгляните на c: \ program files \ msbuild \ microsoft.cpp \ v4.0 \ microsoft.buildsteps.targets. Он содержит цель GenerateTargetFrameworkMonikerAttribute, которая генерирует файл. Элемент Condition определяет, когда он выполняется, значение GenerateTargetFrameworkAttribute является значением. Это всегда будет верно, если в настройках проекта запрашивается сборка / clr. Комментарий в цели очень вводит в заблуждение, шумиха по поводу предварительно скомпилированных заголовочных файлов не имеет ничего общего с целью цели.

[TargetFrameworkAttribute], который он генерирует в вспомогательном файле .cpp, важен, он сообщает CLR на машине, на которой запускается программа, какая минимальная версия .NET должна присутствовать для успешного выполнения программы. Его основное назначение - автоматический запуск установщика для нужной версии .NET, очень приятная функция.

LNK4221 распространен и не имеет зубов, его можно игнорировать. К сожалению, компоновщик не обеспечивает документированный способ подавления предупреждений, основная проблема заключается в том, что он не может быть достаточно конкретным, чтобы подавить только этого. Подавление вспомогательного файла .cpp потребует редактирования файла .targets и нарушения функции автоматической установки, я не могу этого рекомендовать.

Answer 3

Я решил эту проблему, выполнив следующие шаги:

1. Очистите решение
2. Закройте решение
3. Введите команду запуска %temp%, удалите всефайлы
4. Откройте решение, щелкнув файл решения проекта в папке, в которой был сохранен проект.

5. Выполните перестройку одного из проектов.Затем закройте Visual Studio 2010 (да, всю среду разработки), а затем снова откройте файл решения.

   Кажется, что при восстановлении воссоздается отсутствующий файл, но Visual Studio этого не замечает, поэтому вынеобходимо закрыть его и снова открыть, чтобы он снова увидел файл.

Answer 4

Во-первых, ответ @ 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, что имеет место в моем контексте.

Answer 5

Закрыть VS

Откройте каждый файл .vbproj с помощью блокнота и удалите следующую строку:

Все кончено!

Answer 6

Файл для встраивания атрибута сборки .NET TargetFrameworkMoniker. То есть (в будущем) поможет хостам корректно работать с соответствующим CLR. (Извините за неопределенность, я не могу вспомнить, чтобы кто-то еще был экспертом). То есть, на самом деле есть причина: -)

Я не знаю, почему есть предупреждение - изучаем его.

Dan / MSBuild