We are experiencing AppVeyor x64 build failures, and trying a suggestion to set PlatformToolset to DefaultPlatformToolset. The property value is undocumented, so we want to thoroughly test it.
We wired DefaultPlatformToolset into our AppVeyor configuration file:
test_script:
- cmd: >-
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptest.vcxproj
msbuild /t:CopyCryptestToRoot /p:PlatformToolset=DefaultPlatformToolset cryptest.vcxproj
cryptest.exe v
cryptest.exe tv all
The value DefaultPlatformToolset is causing AppVeyor failures. Here's from the log where we believe everything is correct: Build 1.0.129:
msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/2/2017 5:14:24 AM.
The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,37)" does not exist in the project, and will be ignored.
The target "_CollectPdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (45,70)" does not exist in the project, and will be ignored.
The target "_CollectMdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,38)" does not exist in the project, and will be ignored.
The target "_CopyMdbFiles" listed in an AfterTargets attribute at "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (52,71)" does not exist in the project, and will be ignored.
Project "C:\projects\cryptopp\cryptlib.vcxproj" on node 1 (Build target(s)).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): error MSB8020: The build tools for DefaultPlatformToolset (Platform Toolset = 'DefaultPlatformToolset') cannot be found. To build using the DefaultPlatformToolset build tools, please install DefaultPlatformToolset build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [C:\projects\cryptopp\cryptlib.vcxproj]
Done Building Project "C:\projects\cryptopp\cryptlib.vcxproj" (Build target(s)) -- FAILED.
Build FAILED.
How do we set PlatformToolset on the command line when using MSbuild to build the project?
None of these work. They produce similar errors as above.
> msbuild /t:Build /p:PlatformToolset=DefaultPlatformToolset cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset=$(DefaultPlatformToolset) cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset="$(DefaultPlatformToolset)" cryptlib.vcxproj
> msbuild /t:Build /p:PlatformToolset='$(DefaultPlatformToolset)' cryptlib.vcxproj
Here's another error when trying to do that silly MS XML quoting:
>msbuild /t:Build /p:PlatformToolset="$(DefaultPlatformToolset)" cryptlib.vcxproj
Microsoft (R) Build Engine version 4.6.1087.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1011: Specify which project or solution file to use because t
his folder contains more than one project or solution file.
'#34' is not recognized as an internal or external command,
operable program or batch file.
'#34' is not recognized as an internal or external command,
operable program or batch file.
And then there's this one:
> msbuild /t:Build /p:PlatformToolset=""$(DefaultPlatformToolset)"" cryptlib.vcxproj
Microsoft (R) Build Engine version 4.6.1087.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/2/2017 2:19:15 AM.
Project "c:\Users\Test\cryptlib.vcxproj" on node 1 (Build target(s)).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.p
rops(15,24): error MSB4115: The "exists" function only accepts a scalar value,
but its argument "$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\$(Pla
tformToolset)\Microsoft.Cpp.$(Platform).$(PlatformToolset).props" evaluates to
"C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\\Platforms\x64\Platform
Toolsets\"$(DefaultPlatformToolset)"\Microsoft.Cpp.x64."$(DefaultPl
atformToolset)".props" which is not a scalar value.
Regarding the error message's suggestion ... or right-click the solution, and then selecting "Retarget solution", we can't. This is remote, command line only. We are trying to figure out how to run VCUpgrade from the command line at How to run VCUpgrade before Appveyor build?
DefaultPlatformToolset is an MSBuild property which gets set in one of the platform .props files imported by the main project. At one point in a C++ project file there should be the line
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
which for instance for VS2017 ends up importing <msbuild installation>\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Default.props in turn, which sets the property using
<DefaultPlatformToolset>v140</DefaultPlatformToolset>
Since this is an msbuild property it is not known by Appveyor nor by cmd and as such you cannot reference it directly from within appveyor.yml. And even if it were known, you cannot refer to it using $(DefaultPlatformToolset) which is msbuild property expansion syntax whereas cmd's is of the form %ABC%. The errors you get are all because the PlatformToolset property gets set to e.g. the string 'DefaultPlatformToolset' whereas it needs to be set to the name of an actual available platform like v110 or v140 or v120_xp or ...
If you want to use DefaultPlatformToolset the easiest way is entering it in the project file. It can still be overriden from the commandline if needed. The alternative would be running msbuild and have it print it's value, then pass that using /p:PlatformToolset=. But that's not so nice for local development builds in Visual Studio.
For changing the project file, find the section(s) where the PlatformToolset is defined and change it to $(DefaultPlatformToolset) - this should come after the Microsoft.Cpp.Default.props import else the property might not yet be defined. To guard against the case where you're building for a platform which for some reason does not define DefaultPlatformToolset (something custom, or possibly old VS versions) set it to a sensible default first, before the Microsoft.Cpp.Default.props. Example:
<PropertyGroup Label="Globals">
<PlatformToolset>v100</PlatformToolset>
</PropertyGroup>
....
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
....
<PropertyGroup>
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
Here's another way to do it:
<!-- Use DefaultPlatformToolset after Microsoft.Cpp.Default.props -->
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<!-- Set DefaultPlatformToolset to v100 (VS2010) if not defined -->
<PropertyGroup Label="EmptyDefaultPlatformToolset">
<DefaultPlatformToolset Condition=" '$(DefaultPlatformToolset)' == '' ">v100</DefaultPlatformToolset>
</PropertyGroup>
<PropertyGroup Label="PlatformToolset">
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
It is also very important to ensure the Global property group elements are set before Microsoft.Cpp.Default.props is imported. If they are not set, then MSbuild assumes an Application is being built, and it ignores the ConfigurationType that comes later:
<PropertyGroup Label="Globals">
<ProjectGuid>{016d3861-ccd6-4a50-83b4-fe4e93bea333}</ProjectGuid>
<RootNamespace>mylib</RootNamespace>
<ConfigurationType>StaticLibrary</ConfigurationType>
</PropertyGroup>
...
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
...
<PropertyGroup>
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
</PropertyGroup>
Related
I am trying to build a dotnet 3.5 project solution file with VS Build tools 2017 in Jenkins. The project is compiling well with DotNet 3.5's MSBuild, but when I try the same activity with MSBuild Engine Version 15.9.21+g9802d43bc3, it is throwing MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
This is the command which I have used to compile dotnet 3.5 project.
cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin"
MSBuild.exe "%WORKSPACE%\WBR.sln" /p:Configuration=Debug /p:DeployOnBuild=True /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=True
Please find below Jenkins execution logs
C:\Users\Netadmin\.jenkins\jobs\FCRS\jobs\FCRS_VS\workspace>cd "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin"
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin>MSBuild.exe "C:\Users\Netadmin\.jenkins\jobs\FCRS\jobs\FCRS_VS\workspace\WBR.sln" /p:Configuration=Debug /p:DeployOnBuild=True /p:AllowUntrustedCertificate=True /p:CreatePackageOnPublish=True
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 8/19/2019 6:38:12 PM.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
Build FAILED.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
0 Warning(s)
1 Error(s)
The below pic is my jenkins workspace directory.
Any help would be great.
When you use command msbuild xx.sln, you are actually build the projects belonging to the solution.
According to your error message: One of the project's project file (xx.csproj) is not loaded cause the msbuild can't read the xml content well. You can try:
1.Open the xx.csproj file and make sure its format is:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
</Project>
2.Save it with UTF-8 encoding to avoid BOM be messed up
3.Backup and then delete the .suo and .csproj.user files
4.Otherwise, since it's a asp.net mvc project, you can create a same-name asp.net mvc project by vs2017, copy all the source files to the new project to migrate the project to VS2017
5.Make sure your build tools package install the web development workload:
6.Since it works well when using msbuild from .net3.5, you can install the .net framework 3.5 in your server and try calling the msbuild from C:\Windows\Microsoft.NET\Framework64\v3.5 instead of C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin when building .net 3.5 projects from vs2010.
I am working with a web application that was written using VS2015, and is being maintained using VS2017. I am trying to write another application to build the full web stack locally using the MSBuild API and other tools. In VS2015 or VS2017 the ASP.NET Web Application project will build successfully, but when running MSBuild programmatically, I keep getting this error:
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I have the following build packages installed in my app:
Microsoft.Build
Microsoft.Build.Framework
Microsoft.Build.Tasks.Core
Microsoft.Build.Utilities.Core
The standard advice I've seen in forums for this error is to install Visual Studio on the build server, but I am doing this locally and I do have Visual Studio installed. I've also read that MSBuild 15 does not come with the WebApplication.targets file. There is also a toolsVersion parameter on the constructor for Microsoft.Build.Execution.BuildRequestData that I've tried setting manually to 14.0 but it still seems like my app is trying to use MSBuild 15. (I do have MSBuild 14 installed.)
Questions:
Can I make this build run in MSBuild 14 programmatically without updating any csproj files?
Where can I get WebApplication.targets for MSBuild 15?
Solution:
Thanks in large part to #Leo-MSFT I was able to get this working. Here's how:
Uninstalled the VS2017 ASP.NET and Web Application Development workload, then reinstalled with all of its optional components. This downloaded the missing .targets file.
In my builder application, added this property to my instance of BuildRequestData to make MSBuild look in the folders used by v15, rather than using the folders used by v14.
["MSBuildExtensionsPath32"] =
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild"
Can I make this build run in MSBuild 14 programmatically without updating any csproj files?
MSBuildExtensionsPath32 is set internally by MSBuild. If you do not want update you .csproj file, you can try to override the value in your project file:
<PropertyGroup>
<MSBuildExtensionsPath32>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild</MSBuildExtensionsPath32>
</PropertyGroup>
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
But I'm not sure if it will introduce other error(Not tested).
Where can I get WebApplication.targets for MSBuild 15?
The path of WebApplication.targets for MSBuild 15 is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications
I'm updating an old Visual Studio extension for VS 2017. It compiles fine from Visual Studio and msbuild in debug and release on my local computer.
This is the msbuild command line I am using:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU"
However, on the build machine (TFS Build 2010) calling msbuild.exe with the same command line it fails with this error
In order to fix this I am trying to specify VSToolsPath. I've tried various things such as altering the VSToolsPath entry in the .csproj (which seems to not be taken into account since doing this had no effect) and also passing it on the command line:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU" /p:VSToolsPath=Packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\
This causes a very strange error:
CopyFilesToOutputDirectory:
Copying file from "obj\Release\SymCop.dll" to "bin\Release\SymCop.dll".
SymCop -> H:\src\tools\VisualStudioExtensions\Main\VxCop\source\SymCop\bin\Release\SymCop.dll
Copying file from "obj\Release\SymCop.pdb" to "bin\Release\SymCop.pdb".
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\source\SymCop\SymCop.csproj" (default targets).
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\VxCop.sln" (Build target(s)) -- FAILED.
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\build.proj" (default targets) -- FAILED.
Build FAILED.
0 Warning(s)
0 Error(s)
The actual extension project isn't appearing in the log at all, and there's no, y'know, errors. But the build returns as failed, the return code is non-zero, and the vsix project seems to not be built (its output is missing)
Hopefully someone has some suggestions
Thanks
Edit:
For those reading this in the future, the problem seemed to be that there was an <Import> further down in the same file which didn't care about my update to $(VSToolsPath).
Changing that import fixed it:
<Import Project="$(SolutionDir)\packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets"
/>
Visual Studio 2017 extension - VSToolsPath not working
I got the same result as you based on your scripts. After installed the NuGet package Microsoft.VSSDK.BuildTools to the project, the Microsoft.VSSDK.BuildTools.props will be imported in to project file, open the project file, you can find below Import:
<Import Project="..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props')" />
Then open this props file, you can notice below scripts snippet:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="VSSDK_NuGet_Configuration">
<ThisPackageDirectory>$(MSBuildThisFileDirectory)..\</ThisPackageDirectory>
<VSToolsPath>$(ThisPackageDirectory)\tools</VSToolsPath>
<VsSDKInstall>$(VSToolsPath)\VSSDK</VsSDKInstall>
<VsSDKIncludes>$(VsSDKInstall)\inc</VsSDKIncludes>
<VsSDKToolsPath>$(VsSDKInstall)\bin</VsSDKToolsPath>
</PropertyGroup>
</Project>
In this case, NuGet package override the value VSToolsPath with $(ThisPackageDirectory)\tools. So MSBuild will skip set the value setting in the next step in the project file:
<PropertyGroup>
<MinimumVisualStudioVersion>15.0</MinimumVisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
</PropertyGroup>
Because NuGet have already set the value $(VSToolsPath), the value of Condition="'$(VSToolsPath)' == ''" would be False. In addition, you can add a target to check if the value is set, like:
<Target Name="CheckVSToolsPath" BeforeTargets="Build">
<Message Text="$(VSToolsPath)"></Message>
</Target>
You will find this value is set to:
C:\Users\Admin\Documents\Visual Studio 2017\Projects\VSIXProject2\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\..\\tools
Summary above, the value of VSToolsPath was imported correctly, we do not need to passing it on the command line.
After in-depth investigation, I found the reason for the previous error "MSB4226: The imported project "(...)\VSSDK\Microsoft.VsSDK.targets" was not found." is that the MSBuild property of "VisualStudioVersion" not be set on the build server.
See below link for detail info Building a VSIX extension with the Visual Studio 2017 Build Tools:
something that a machine with the full Visual Studio 2017 does and that a machine with the Build Tools 2017 does if you open a developer command prompt. Since I was not using it, I passed it as a parameter to the MSBuild script. It can be defined too inside the .csproj file, something that previous Visual Studio versions did automatically but recent versions don’t.
So to resolve the error "MSBuild4226", you should pass the visual studio version on command line:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU" /p:VisualStudioVersion=15.0
After using this command line, the error MSBuild 4226 was resolved.
Hope this helps.
I resolved this problem in VS 2019 by https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#generatepathproperty
<ItemGroup>
<PackageReference Include="Microsoft.VSSDK.BuildTools" Version="16.10.1055">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
<Import Project="$(PkgMicrosoft_VSSDK_BuildTools)\tools\vssdk\Microsoft.VsSDK.targets" />
Our company just migrated our project from a TFS 2012 server to 2013 TFS server as well as our build controllers (2012 servers to 2013). I know within VS2013 MSBuild is now part of the application however I have a need to also reference older build machines that build some of our SSIS and SSAS projects as part of deployment. The challenge I have is these projects use Business Intelligence for 2008R2 and I cannot migrate the solution/projects forward.
Within my analytic's solution which was authored in VS2010 I have the following build command:
<Target Name="BeforeBuild">
<!-- Build SSIS Package-->
<Exec Command=""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "$(MSBuildProjectDirectory)\..\AnalyticsSSAS\AnalyticsSSAS.dwproj" /Build" />
</Target>
<PropertyGroup>
<PostBuildEvent>xcopy "$(ProjectDir)..\AnalyticsSSAS\bin\*.*" /y</PostBuildEvent>
</PropertyGroup>
When I try to run a build using the 2013 definition the build fails and states that the msbiuld taks EXEC is not recognized. I can open the solution and projects individually and build them (running 2010) with no issues 2013 wants to migrate the solution to which I can't do.
Here is the actual message generated in the build log file:
"f:\blds\26\DevCI\src\Analytics.sln" (default target) (1) ->
"f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\SSASBuild.csproj" (default target) (2) ->
(BeforeBuild target) ->
f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\SSASBuild.csproj(85,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "f:\blds\26\DevCI\src\Database\Dashboards\SSASBuild\..\AnalyticsSSAS\AnalyticsSSAS.dwproj" /Build" exited with code 1.
"f:\blds\26\DevCI\src\Analytics.sln" (default target) (1) ->
"f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\SSISBuild.csproj" (default target) (3) ->
f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\SSISBuild.csproj(84,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "f:\blds\26\DevCI\src\Database\Dashboards\SSISBuild\..\AnalyticsSSIS\AnalyticsSSIS.dtproj" /Build" exited with code 1.
I suspect from what I have read that MSBuild in VS2013 will not allow for a lower version of MSBuild v9.0 to be referenced without migrating the project to a newer version.
Has anyone seen this before and is there any workaround for this type of build?
-cheers
I think there are many solution, but the basic idea is to force using the old MSBuild version.
Custom Build Template (old style)
Add an MSBuild activity and set the ToolPath Property to the old version. You must expose a list of solutions to build as Template arguments.
Script (new style)
Write a post-build (or pre-build) script that invokes the proper MSBuild version with the path to the solution.
I have a Visual Studio 2010 SharePoint project. If I choose 'Package' from the project menu, a .wsp file is generated. How can I invoke the same build from command line (i.e. what /target is required for MSBuild)?
I got it to work, finally. The tricky part is the fact that the SharePoint targets do not exist when MSBuild loads the .sln file, you have to load the individual .csproj files.
set msbuild="C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
set config=Debug
set outdir="C:\out\"
%msbuild% /p:Configuration=%config% /m ../My.SharePoint.Project/My.SharePoint.Projectcsproj /t:Package /p:BasePackagePath=%outdir%
This is also a useful document here: http://msdn.microsoft.com/en-us/ff622991.aspx
"To generate packages when building in
TFS 2010, set the parameter
/p:IsPackaging=True on MSBuild"
Also to package project with msbuild you can use target Package:
Define new target "BuildAndPackage"
<Target Name="BuildAndPackage">
<CallTarget Targets="Build"/>
<CallTarget Targets="Package"/>
</Target>
Use new target in build process:
<Project ToolsVersion="4.0" DefaultTargets="BuildAndPackage">
But this approach not recommended because it may cause errors in TFS Build process..
Set the MSBuild's verbosity to 'maximum' and you should see what is called from the build console.
In VS2010 of course :)