Недавно я обновился до 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, это вызывает проблемы. Поэтому вся информация по этому файлу и то, как я могу избежать его автосоздания, будет высоко оценена. Спасибо!
Это общее для всех языков (С#, 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. Комментарий в цели очень вводит в заблуждение, hoopla о прекомпилированных файлах заголовков не имеет ничего общего с целью цели.
Значок [TargetFrameworkAttribute], который он генерирует в вспомогательном файле .cpp, имеет важное значение, который сообщает CLR на компьютере, на котором запущена программа, какая минимальная версия .NET должна присутствовать для успешного выполнения программы. Его основное использование заключается в автоматическом запуске установщика для требуемой версии .NET, очень приятной функции.
LNK4221 распространен и не имеет зубов, вы можете его игнорировать. К сожалению, компоновщик не обеспечивает документированный способ подавления предупреждений, основная проблема заключается в том, что он не может быть достаточно конкретным, чтобы подавить только этот. Подавление хелпера .cpp потребует редактирования файла .targets и разбивает функцию автоматической установки, я не могу этого рекомендовать.
Я решил эту проблему со следующими шагами:
%temp%, удалите все файлыСделайте перестройку в одном из проектов. Затем закройте Visual Studio 2010 (да, вся среда разработки), а затем снова откройте файл решения.
Кажется, что rebuild, воссоздает недостающий файл, но Visual Studio его не замечает, поэтому вам нужно закрыть его и снова открыть, чтобы он снова мог видеть файл снова.
Во-первых, ответ @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-документов, что имеет место в моем контексте.
В файле есть встроенный атрибут TargetFrameworkMoniker.NET. То есть (в будущем) помогают хостам правильно работать с соответствующей CLR. (Извините за неопределенность, я не могу вспомнить, что кто-то еще является экспертом). То есть, для этого есть причина: -)
Я не знаю, почему там предупреждение - глядя в него.
Dan/MSBuild
Закрыть VS
Откройте каждый файл .vbproj с помощью блокнота и удалите следующую строку: < TargetFrameworkProfile/ >
Это более!