Подтвердить что ты не робот

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

Недавно я обновился до Visual Studio 2010. Теперь, когда я создаю проекты, я получаю строку, которая гласит:

1>  .NETFramework,Version=v4.0.AssemblyAttributes.cpp

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

Во-первых, ответ @Brian устраняет это условие, и я выпустил 4x + 1s для других полезных ответов, которые помогли быстро диагностировать и решить проблему, которую я испытал.

Требуется включить дамп проблемы, которую я диагностировал в моем контексте на основе этого.

Эта функция синтезирует исходный файл на языке проекта, который создает в поток компиляции атрибут 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, чтобы узнать, применимо ли это только к профилю участника (как указано в ответе @AlainA) (в моем конкретном случае использовался профиль клиента .NET 4.0)

  • Как показано в приведенном выше сообщении, одна тонкость, которая может быть задействована, - это наличие или отсутствие XML-документов, что имеет место в моем контексте.

Ответ 5

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

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

Dan/MSBuild

Ответ 6

Закрыть VS

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

Это более!