I have a collection of csproj files that all refer to the same set of source files, but have slightly different target data making it so I need to keep the project files separate. E.g. there are WinPhone, XBox, Desktop, MonoTouch variants of the same project.
For things that really are duplicated, like the list of .cs files to compile, I'd like to consolidate the list into a single file so I don't keep having to make sure that all variations are kept in sync. I originally tried doing this by removing the sources from the .csprojs and putting them into a .targets file that got imported by all the csprojs, but that made the source files disappear from both VS and MonoDevelop.
My second attempt was by making the Desktop csproj file the primary one, and letting all the variations import that csproj with some conditional logic. This keeps the source files editable from the main csproj and they build into all flavors. Now Visual Studio understands what I was trying to do but MonoDevelop can't build it. In the MonoDevelop solution the iOS version of the core DLL is grayed out and says "(not built in active configuration)"
I've also tried xbuilding the csproj and solution, which seems to get past the problems that MonoDevelop has but hiccups on other things related to resolving monotouch assemblies. I had thought MonoDevelop used xbuild, but maybe not?
Since this works in the Windows msbuild it seems like it's either a bug or a not supported feature in Mono. Or maybe there's a better way to tackle the whole scenario... Thought I'd ask here.
For specifics,
My Core.iOS.csproj file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project
xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
DefaultTargets="Build"
ToolsVersion="4.0" >
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>10.0.0</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{AE37B15F-F4BE-48DE-9F20-F00A601EC89E}</ProjectGuid>
<ProjectTypeGuids>{6BC8ED88-2882-458C-8E55-DFD12B67127B};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<AssemblyName>Core.iOS</AssemblyName>
</PropertyGroup>
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="monotouch" />
</ItemGroup>
<Import Project=".\Core.csproj" />
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
</Project>
And my Core.csproj file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Project
xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
DefaultTargets="Build"
ToolsVersion="4.0">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>Core</RootNamespace>
</PropertyGroup>
<!-- Using AssemblyName's presence to check for whether this is imported. -->
<PropertyGroup Condition=" '$(AssemblyName)' == '' ">
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{FC495BD8-11B1-46B0-A9DE-F245A0CBEE94}</ProjectGuid>
<AssemblyName>Core</AssemblyName>
<SignManifests>false</SignManifests>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<!-- properties similar to Debug -->
</PropertyGroup>
<ItemGroup Condition=" '$(Platform)' == 'AnyCPU' ">
<Reference Include="System" />
<Reference Include="System.Core" />
</ItemGroup>
<Import Condition=" '$(AssemblyName)' == 'Core' " Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<ItemGroup>
<Compile Include="[...]" />
<Compile Include="[...]" />
</Project>
And, like I said, a variation of this seems to be working correctly when using VS Express for WinPhone and XBox360 projects. Is this something that should work? Is there a better way to do this?
Thanks,
Short answer:
This won't work because although MonoDevelop uses the MSBuild file format, it doesn't use the real MSBuild/xbuild engine for all project types yet. I'd suggest using links instead of an include.
Full background:
MonoDevelop has an old internal build engine that's derived from the SharpDevelop 1.0 build engine, i.e it predates the existence of MSBuild. We're in the process of migrating to MSBuild, but this has taken several stages, and is not yet complete.
A few years ago, MonoDevelop switched its project file format to a Visual Studio compatible subset of MSBuild. This was done by serializing/deserializing known MSBuild properties and items into MD's internal project model, but doing the build using the old build engine. This meant that any MSBuild projects that only used features accessible from the Visual Studio UI worked fine. However, it did not support the more advanced MSBuild features that are only accessible by hand-editing the MSBuild XML.
Later MD gained experimental support for using the xbuild/MSBuild build engine, but at the time xbuild was not mature, and it did not have MSBuild targets for all project types. It remained experimental, and build code for new project types (MonoTouch, etc) was written using the MD internal build engine.
Mono for Android needed to be supported in Visual Studio, so had to have MSBuild targets. Instead of writing and maintaining build code for two build engines, we finished up xbuild and MonoDevelop's MSBuild engine integration so it could be used for Mono for Android projects. However, we could not enable the xbuild build engine by default in MD, since many other project types did not yet have xbuild targets. Instead, we allowed project addins to force the use of the xbuild engine on a per-project-type basis.
This is essentially the current state - the xbuild engine is used for Mono for Android projects, and newer project types such as iPhone Binding projects and PLP projects, and is recommended for new project types. But older project types such as MonoTouch, MonoMac, ASP.NET etc have not yet been migrated at the time of writing.
Related
I have an ASP.NET Core application that I'm attempting to perform web deploy to a server and no matter what build configuration I select in the profile wizard, it always deploys multiple appsettings files as well as the PDB files for the DLLs. Anyone know what could be causing this?
If you want to exclude .pdb files for release publishing, then you may disable their generation during release build by adding next property to .csproj file (found this here)
<PropertyGroup>
<DebugType Condition=" '$(Configuration)' == 'Release' ">None</DebugType>
</PropertyGroup>
Regarding any configuration (or not) file, it will be published based on CopyToPublishDirectory attribute value. So again, you may use Condition attribute and have something like this (just an idea):
<ItemGroup Condition=" '$(Configuration)' == 'Debug' ">
<Content Update="appsettings.debug.json" CopyToPublishDirectory="Always"/>
<Content Update="appsettings.release.json" CopyToPublishDirectory="Never"/>
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' == 'Release' ">
<Content Update="appsettings.debug.json" CopyToPublishDirectory="Never"/>
<Content Update="appsettings.release.json" CopyToPublishDirectory="Always"/>
</ItemGroup>
But in general, it's better to depend on environment setting (Dev, Prod) when we are talking about configs.
So my team uses VS2013 right now and I just recently proved that I can run our project with VS2017. So I was wondering if there is a way I can push my changes to our master branch without my team noticing anything. This means if they open up their VS2013 they run the project just fine and, when I run it with VS2017 it runs fine too. (It won't do that right now because the 3rdParty libraries were compiled with msvc 1800 and with my project running at msvc 1900 it gives me linking errors)
Can I take advantage of MSBuild conditionals to do this?
<Choose>
<When Condition=" '$(Configuration)'=='Debug' ">
<PropertyGroup>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>.\bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
</PropertyGroup>
<ItemGroup>
<Compile Include="UnitTesting\*.cs" />
<Reference Include="NUnit.dll" />
</ItemGroup>
</When>
<When Condition=" '$(Configuration)'=='retail' ">
<PropertyGroup>
<DebugSymbols>false</DebugSymbols>
<Optimize>true</Optimize>
<OutputPath>.\bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
</PropertyGroup>
</When>
</Choose>
You should can use VS17 and your Team VS13. If you opening the project in VS17, don't upgrade your Windows SDK version and platform toolset and the team and you can build as usual, but you cannot use new C++ features, because the older VS13 compiler cannot compile them
Wix on windows 10 with mvs2013 or mvs2014 is not working.
I am getting the error:
Error The "GenerateCompileWithObjectPath" task could not be loaded from the assembly \WixTasks.dll. Could not load file or assembly 'file:///c:\WixTasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. SetupProject5 C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets
If i try to include WixTasks.dll to the project, when mvs2013 or mvs2014 crashes during the build. I include \WixTasks.dll to the C:\SourceControl\vs2015\SetupProject1\SetupProject1\SetupProject1.wixproj from the unpacked wix binaries folder:
C:\SourceControl
// C:\SourceControl\vs2015\SetupProject1\SetupProject1\SetupProject1.wixproj
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) .NET Foundation and contributors. All rights reserved. Licensed under the Microsoft Reciprocal License. See LICENSE.TXT file in the project root for full license information. -->
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>3.10</ProductVersion>
<ProjectGuid>0adbe89f-e1ce-4345-90e6-64b8304fa42f</ProjectGuid>
<SchemaVersion>2.0</SchemaVersion>
<OutputName>SetupProject1</OutputName>
<OutputType>Package</OutputType>
<WixToolPath>C:\SourceControl</WixToolPath>
<WixTargetsPath>$(WixToolPath)\wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)\WixTasks.dll</WixTasksPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' AND '$(MSBuildExtensionsPath32)' != '' ">$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
<DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="Product.wxs" />
</ItemGroup>
<Import Project="$(WixTargetsPath)" />
<!--
To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Wix.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
I was reading different online forums and examples the last two days. Also Pact books on wix by Nick Ramirez. Nothing is working.
Define the following MSBuild variables and everything should work.
<WixRootPath Condition=" '$(WixRootPath)' == '' ">$(MSBuildThisFileDirectory)Tools\wix\$(WixTargetVersion)\</WixRootPath>
<WixToolPath Condition=" '$(WixToolPath)' == '' ">$(WixRootPath)</WixToolPath>
<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(WixRootPath)Wix.targets</WixTargetsPath>
<WixCATargetsPath Condition=" '$(WixCATargetsPath)' == '' ">$(WixRootPath)sdk\Wix.CA.targets</WixCATargetsPath>
<WixTasksPath Condition=" '$(WixTasksPath)' == '' ">$(WixToolPath)WixTasks.dll</WixTasksPath>
<WixSdkPath Condition=" '$(WixSdkPath)' == '' ">$(WixRootPath)sdk\</WixSdkPath>
Just make sure the paths are right. These paths are for the wix 3.10.2 binaries which I checkout for my builds on the build machine.
I think the build tasks should be looking in the path defined by the WIX environment variable but I'm not 100% sure about that.
I think defining all the variables with the path you set should fix everything since the error mentions looking in C:\WixTasks.dll normally the path it looks for is something like $(WixInstallPath)WixTasks.dll but if $(WixInstallPath) isn't properly defined it will just be empty and default to C:\WixTasks.dll. You do define $(WixTasksPath) but I think it's getting overwritten for somereason...
Regardless, there's something wrong on your system right now but you can work around it this way probably.
EDIT: If the above doesn't work, download the wix binaries from here and extract them into a folder called "Wix" or whatever you want to call it. Then set your WixRootPath to be equal to that location.
I encountered this when using VS2015 and working on git branches that use different versions of Wix. (I'm upgrading to the latest Wix version but not all branches are there yet.)
You must terminate and restart VS if you switch between git branches that use different versions if Wix. VS holds some Wix files open, files that won't work under any other version of Wix. If you forget to do this your VS build will fail with the (quite cryptic) message of "The "GenerateCompileWithObjectPath" task could not be loaded from the assembly C:\Program Files (x86)\WiX Toolset v3.10\bin\WixTasks.dll"
The working solution from WiX Cookbook by Nick Ramirez, 2015, Chapter1 "Building a WiX installer from the command line", Example 4 "BuildMachineInstaller"
Download and unzip wix binaries file, for example from here.
1. Create some folder for your project, for example C:\SourceControl\own\box1 with file Product.wxs
2. Extract binaries to some folder, for example to C:\SourceControl\own\box1\tools\wix
3. start windows command line tool cmd and change to your project folder. Execute candle and light commands as folows:
C:\SourceControl\own\box1>C:\SourceControl\own\box1\tools\wix\candle *.wxs -o obj\
C:\SourceControl\own\box1>C:\SourceControl\own\box1\tools\wix\light obj\*.wixobj -o bin\CommandLineInstaller.msi
Anyway, if somebody could give some working example files and description how to make *.exe or *.msi with MSBuild or Visual Studio Build and wix, i would appreciate a lot. The other examples in Pact books are not working by pure copying, although are very useful for general understanding.
I've just come across this issue and found that at the top of the wix2010.targets file was the following property group.
<PropertyGroup>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Installer XML\3.11#InstallRoot)</WixInstallPath>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Installer XML\3.11#InstallRoot)</WixInstallPath>
When checking the referenced registry path there was no entry for 3.11 but there was one there for 3.10. and the installed version was reported as 3.10. So updating the property group to the following corrected the issue for me.
<PropertyGroup>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Installer XML\3.10#InstallRoot)</WixInstallPath>
<WixInstallPath Condition=" '$(WixInstallPath)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Installer XML\3.10#InstallRoot)</WixInstallPath>
Hope this helps.
I solved the problem by following these instructions:
Download WIX311.exe from https://github.com/wixtoolset/wix3/releases/tag/wix3111rtm
Download Votive2017.vsix from https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension
Remove any old WiX nuget packets from your solution/project
Follow these instructions (you can omit /quiet).
http://packagingstuffs.blogspot.com/2017/11/wix-toolset-311-silent-install-method.html
Content from the website above;
To Install:
Step1: Download the source from web and get the installer wix311.exe.
Step2: Run following command:wix311.exe /install /quiet /norestart
Step 3: Copy the Votive2017.vsix file (provided by vendor) to the local machine (e.g. %TEMP%)
Step 4: Run VSIXinstaller from its stored location
"%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Professional\Common7\IDE\VSIXInstaller.exe" /quiet
Good luck and best regards
I am using Visual Studio 2015, i have a solution with 2 different web applications. There exists One Solution and two projects under it. The files related to nuget are distributed as:
Packages Folder is in the Solution Directory
Package.config in each project directory
There is no nuget folder: nuget.config and nuget.exe in my solution.
My Project build and run fine in Visual Studio, but I am facing a problem when using VSTS Continuous Integration with Build Solution Step (which use a build definition that maps to one project) it gives:
This project references NuGet package(s) that are missing on this computer. Use
NuGet Package Restore to download them. For more information, see The missing file is
..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props.
This is MyProject.csproj file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>
</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{BBD26A49-D1F4-4391-9D60-2469433DEE0D}</ProjectGuid>
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>AdminUI</RootNamespace>
<AssemblyName>AdminUI</AssemblyName>
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
<MvcBuildViews>false</MvcBuildViews>
<UseIISExpress>true</UseIISExpress>
<IISExpressSSLPort />
<IISExpressAnonymousAuthentication />
<IISExpressWindowsAuthentication />
<IISExpressUseClassicPipelineMode />
<UseGlobalApplicationHostFile />
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
I noticed that it only tries to import the package that generated the error, but it doesn't explicitly import other packages, but it include them as references:
<Reference Include="WebGrease">
<Private>True</Private>
<HintPath>..\packages\WebGrease.1.5.2\lib\WebGrease.dll</HintPath>
</Reference>
<Reference Include="Antlr3.Runtime">
<Private>True</Private>
<HintPath>..\packages\Antlr.3.4.1.9004\lib\Antlr3.Runtime.dll</HintPath>
</Reference>
This also the end of the myProject.csproj file:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
</Target>
I am wondering why it gives this error, taking into consideration that this package is already installed in the previous step "Nugget Install". Why it can't find it? i have spent a lot of time on this issue!
Before you add the build task, you can add nuget install or restore task. This will restore/install the nuget packages on the build agent.
Actually, this worked for me:
Adding the mapping (repository configuration) to the packages folder in the solution
Repository Configuration
Nuget Install Config
Then, it worked like a charm.
Ensure the Package.config file you've mentioned exists in source control.
It may be that everything builds successfully on your machine because Package.config exists there but not in source control for when the continuous integration agent tries to download and build the project.
<MSBuild Projects="$(ProjectFile)" Targets="_WPPCopyWebApplication;"
Properties="OutDir=..\publish;Configuration=Release;Platform=AnyCPU" />
I am using above script to publish Asp.Net project. In the project settings, I have absolutely made sure debug symbols are generated in release mode. Still MsBuild is not generating the pdb files in the output.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>Full</DebugType>
<DefineDebug>false</DefineDebug>
<DefineTrace>true</DefineTrace>
<Optimize>true</Optimize>
<OutputPath>bin\</OutputPath>
<DocumentationFile>WebProject.xml</DocumentationFile>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
After looking at the Microsoft.Web.Publishing.targets source, I have found a variable (ExcludeGeneratedDebugSymbol) being set to True in Release mode. From the comments, it looks like they wanted to exclude symbols from WebSite project, but the condition is not properly set for WebApplication project.
So, I have decided to override my build scrip from the caller arguments and it worked like a charm. I have not yet ascertained any side affects it may cause or using the undocumented property for future stability, but it works for now.
From the Microsoft.Web.Publishing.target file
<!--For website we will always exclude debug symbols from publishing unless it is set explicitly by user in website publish profile-->
<ExcludeGeneratedDebugSymbol Condition="'$(ExcludeGeneratedDebugSymbol)'=='' And '$(_WebProjectType)' == 'WebSite'">True</ExcludeGeneratedDebugSymbol>
<ExcludeGeneratedDebugSymbol Condition="'$(ExcludeGeneratedDebugSymbol)'=='' And '$(Configuration)' == 'Release'">True</ExcludeGeneratedDebugSymbol>
<ExcludeGeneratedDebugSymbol Condition="'$(ExcludeGeneratedDebugSymbol)'==''">False</ExcludeGeneratedDebugSymbol>
I have updated my script as follows.
<MSBuild Projects="$(ProjectFile)" Targets="_WPPCopyWebApplication;"
Properties="OutDir=..\publish;Configuration=Release;Platform=AnyCPU"; ExcludeGeneratedDebugSymbol=false />
You could also updated your publish profile (.pubxml) file to include that property value. I had to do this today with the new build bits in TFS Build 2015 to have the web publishing include the .pdb files. See example contents of file with property added to bottom.
<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit http://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<SiteUrlToLaunchAfterPublish />
<publishUrl>C:\Publish</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<ExcludeApp_Data>False</ExcludeApp_Data>
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<ExcludeGeneratedDebugSymbol>false</ExcludeGeneratedDebugSymbol>
</PropertyGroup>
</Project>
You can put this directly in your *.csproj file, as the last property group section (right before the Import elements):
<PropertyGroup>
<ExcludeGeneratedDebugSymbol Condition="$(DebugSymbols) == true">false</ExcludeGeneratedDebugSymbol>
</PropertyGroup>