otakuSiD
otakuSiD
assemblyattributes dev msbuild .net recompilation *teamcity *гавно

Ели вы столкнулись с проблемой перекомпиляции проектов, даже если сорцы не менялись — скорее всего проблема связана с AssemblyAttributes.cs файцлом, который генерит MSBuild.

Этот файл генерится всего с одной целью — добавить TargetFrameworkAttribute в вашу сборку. Но вместо того что бы по старинке добавить его в AssemblyInfo.cs средствами студии — MS решили пойти новым путем.

А проблема даже не с самим AssemblyAttributes.cs файлом, а с тем что он ложится в TEMP папку системы. А если папку почистить или поменять — файл пересоздасться и будет новее собранных ранее асембляек — тадам! вот и перекомпиляция.

А теперь накладываем на это TeamCity которая переопределяет TEMP в окружении на свою папку, которую чистит после каждого билда. И получаем постоянную перекомпиляцию проектов.

Лечится переопределением пути к AssemblyAttributes.cs файлу в проекте:

<PropertyGroup>
<TargetFrameworkMonikerAssemblyAttributesPath>$([System.IO.Path]::Combine('$(IntermediateOutputPath)','$(TargetFrameworkMoniker).AssemblyAttributes$(DefaultLanguageSourceExtension)'))</TargetFrameworkMonikerAssemblyAttributesPath>
</PropertyGroup>


blogs.msdn.com
stackoverflow.com
stackoverflow.com
max630
max630
msbuild Windows говно если файл инцлюдится из директории "бла-бла-Packages-блабла", как "бла-бла-packages-блабла", то что будет в переменной MSBuildThisFileDirectory, packages или Packages? Ответ — иногда то, иногда это
DarthRamone
DarthRamone
code msbuild /pr/ ? 
Похоже, я чего-то не догоняю:

<Target
		Name="VB6"
		Inputs="@(VBCompile)"
		Outputs="@(VBCompile->'$(OutputDirectory)%(Filename).dll')"
		DependsOnTargets="IDL"
	>

Таргет компиляет бейсико-код, кладет длл-ку в $(OutputDirectory) и имя тоже совпадает. Почему он при повторном билде не пропускает этот таргет, если Outputs по идее совпадает?
otakuSiD
otakuSiD
msvs dev msbuild blogs.msdn.com


Most of the important changes this release stem from MSBuild’s transition into Visual Studio:

— MSBuild and the VB/C# compilers are now available as a standalone package, Microsoft® Build Tools. This package is installed with Visual Studio 2013.
— We are simplifying MSBuild’s versioning story. Each version of Visual Studio will have a corresponding version of the Microsoft® Build Tools including MSBuild, the VB/C# compilers, and common tasks and targets that make up the 2013 Toolset. There will no longer be any sub Toolset versions. Visual Studio 2013 will exclusively use 2013 MSBuild and VB/C# compilers (assembly version 12.0) and the 2013 Toolset (ToolsVersion 12.0).
— The way MSBuild selects Toolset versions for command line builds is now identical to the way Visual Studio builds projects. If your projects build in VS, they will build from the command line. No more manually overriding Toolset versions and hunting down missing dependencies.
— MSBuild has a dependency on the latest Framework, .NET 4.5.1.
otakuSiD
otakuSiD
гавно code dev build msbuild 
<PropertyGroup>
    <VisualStudioVersion Condition=" '$(VisualStudioVersion)' == '' ">11.0</VisualStudioVersion>
    <CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\1.8\</CloudExtensionsDir>
  </PropertyGroup>


Явно указано что бы таргеты искал в папке для MSVS 2012. При сборке из под MSVS - все ок. Как только из NAnt дергаю MSBuild - оно упорно лезет в папку к MSVS 2010, сука.
Ясен пень что для MSVS 2010 нужных таргетов никто не ставил, и все валится с ошибкой:

Azure.ccproj(68,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.8\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Сталкивался кто с такой херней?