Develop Reference

MSBuild ignoring /p:BuildProjectReferences=false on Azure build server

I've a solution with three projects in it: 2 C# WPF projects and 1 WIX project to create an installer. I've set up a build pipeline on Azure DevOps that references our own build server so I have access to the OS.
I want the Wix installer project to be dependant on the two C# projects for my local test builds but for the Azure Pipeline, I need to build the C# projects first and sign the executables before creating the MSI installer with the WIX project (that needs to be signed, too).
The problem is that the build server ignores "/p:BuildProjectReferences=false" (which should force msbuild to NOT build the dependencies) while my local computer does not when I run the exact same command line on both:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" Solution.sln /p:AppxBundle=Always /p:UapAppxPackageBuildMode=StoreUpload /p:RunWixToolsOutOfProc=true /p:BuildProjectReferences=false /target:Installer /m:4 /p:Platform="x64" /p:Configuration="Release"
Extra info
I tried with and without Rebuild option (/target:Installer:Rebuild)
The build server fetches the git repository so it's exactly the same project on both sides.
Both Visual Studio installations are VS 2019 build version 16.11.14
Both Wix Toolset installations are version v3.11.2.4516
Any ideas how to get the build server to not build the dependencies?

Well this is embarrassing. Apparently I had some change on my local computer that wasn't committed yet. So code on both platforms wasn't the same...
The fix was a change in the *.sln file
Project("{930C7802-8A8C-48F9-8165-68863BCCD9DD}") = "Installer", "Installer\Installer.wixproj", "{A9EDFE69-D273-42EE-97EA-469C3434AEDC}"
ProjectSection(ProjectDependencies) = postProject
{C784B33D-1E8D-41EF-97C2-983CA9A5B693} = {C784B33D-1E8D-41EF-97C2-983CA9A5B693}
{B6E37FA9-64CF-491B-B268-9D115AABC6B2} = {B6E37FA9-64CF-491B-B268-9D115AABC6B2}
EndProjectSection
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WPFProject1", "WPFProject1\WPFProject1.csproj", "{C784B33D-1E8D-41EF-97C2-983CA9A5B693}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WPFProject2", "WPFProject2\WPFProject2.csproj", "{B6E37FA9-64CF-491B-B268-9D115AABC6B2}"
EndProject
I removed the 'ProjectSection' in the first project (Installer). This resulted in the code being built completely in Visual Studio but not for the Azure Pipelines because of the use of the /p:BuildProjectReferences=false param in the pipeline build command.
The two WPF projects still exist as depedencies in Installer project.
I hope this helps someone someday (or myself in a future project)

Error VSSDK1001: Unable to find Microsoft.VisualStudio.CommandTable.VSCTCompiler type

I am attempting to update a Visual Studio extension to be compatible for installation in Visual Studio 2017. I have followed the steps and notes in each of the following pages (and others I've searched):
https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/extensibility/faq-2017.md#can-i-build-a-vsix-v3-with-visual-studio-2015
http://www.visualstudioextensibility.com/2017/01/10/its-time-to-change-the-vsix-manifest-of-your-extension-to-v3-for-visual-studio-2017-compatibility/
I originally encountered a separate issue noted in this post, which has been resolved. Now, the project (and extension) continue to build successfully locally, but it is failing on our TFS build server with the following error:
"d:\example\myproj\MyProj.csproj" (Rebuild target) (25:7) ->
d:\example\myproj\packages\Microsoft.VisualStudio.Sdk.BuildTasks.14.0.14.9.23\tools\VSSDK\Microsoft.VisualStudio.Sdk.Common.targets(67,5): error VSSDK1001: Unable to find Microsoft.VisualStudio.CommandTable.VSCTCompiler type in 'd:\example\myproj\packages\Microsoft.VisualStudio.Sdk.BuildTasks.14.0.14.9.23\tools\VSSDK\bin\VSCT.exe' Assembly. [d:\example\myproj\MyProj.csproj]
Has anyone else had any experience with this error to advise me as to why our build server is having this issue?
Additional note: I'm running Visual Studio 2015 (update 3) on both my local machine and on the build server in question.
UPDATE (1/7/2019)
The issue appears tied to the version of MSBuild.exe that is executed.
By default, our build server uses the version of MSBuild associated to the highest installed version of .NET (MSBuild version 4.7.3062.0, in our case).
This version throws the error (VSSDK1001) from my original post.
If I manually perform the build using MSBuild version associated with VS 2015 (MSBuild version 14.0.27522.0), the error is eliminated and the build succeeds. I have been, so far, unable to force TFS to use the desired MSBuild.exe version...

Error VSSDK1001: Unable to find Microsoft.VisualStudio.CommandTable.VSCTCompiler type
You should add a nuget restore task before you build task in your TFS definition.
When you build in the local via Visual Studio, Visual Studio have two options to restore nuget packages automatically when we build the project:
But, when you build on the TFS server, there is no such options to restore those nuget packages automatically. So we need add a task nuget restore before we build the project/solution:
Add a task, search nuget and add it into the agent job, select restore in the Command:
Configure this nuget restore task correctly and set it before your build task.
Note: You can also add a NuGet Tool Installer task to specific version of NuGet.
Hope this helps.

The resolution to this required updating the ToolPath property in the build process template used by our build definition, similar to what is described in this post.
In our case, our build process template contains the "Run TfsBuild for Configuration Folder" step, and I needed to update the ToolPath property to a value of "C:\Program Files (x86)\MSBuild\14.0\Bin"

Microsoft.CSharp.Core.targets missing

I am building a webservice project on a TFS2017 Update 3 with build tools 2017. I get the following error
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(322,5):
Error MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
What steps do I need to take to fix this error?

In my case, opening the existing Solution file (with .sln extension), it installed all the missing dependencies.
Otherwise check for missing target packages at nuget.org manually and install them (e.g. MSBuild.Microsoft.VisualStudio.Web.targets).

As per this GitHub issue, you'll need to set $(RoslynTargetsPath).
If MSBuild is installed on the machine and your tests run in a Visual Studio Developer Command Prompt, then you shouldn't need to do anything. However, MSBuild 15.0 no longer places itself in the registry which makes it impossible for MSBuild to find itself. This is because of a mandate by Visual Studio where you can have multiple side-by-side installations. MSBuild in this case would be installed once per Visual Studio instance. MSBuild now finds itself by looking at environment variables set by the VS command prompt.
If you want to fully redistribute MSBuild via a combination of our packages and all of the other packages needed to do full project evaluation, you will have to set RoslynTargetsPath before you load projects. You could argue this is an issue with NuGet since all packages' <contentFiles /> go to the the root of your output directory and you can't specify a subdirectory for certain packages.

If you're coming to this page from google/duckduckgo after trying to figure out why you're getting a similar message in Ubuntu 20.04, maybe this can help: https://askubuntu.com/a/1231973/1073658 (tl;dr apt install mono-roslyn from mono-project's repo)

First suggest you directly use msbuild command on the build agent with TFS build service account. This will narrow down if the issue is related to your agent environment or your TFS build definition.
According to your error info, the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets is looking the path of Visual Studio 2017.
However, for Build Tools the path is different should be C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn
Seems you haven't installed VS2017 on your build agent. This maybe the root cause of the issue.
The simplest solution is installing VS2017 on your build agent. Note, you need to reconfigure the build agent or restart build agent service to capture those new capabilities. Otherwise you need to change the corresponding import section in your .csproj project files.

I updated to TFS2018 and the problem got solved.

Restoring all Nuget Packages in a Visual Studio 2015 Solution

I have read many of the answers on SO and NuGet (and the Internet in general, really), but I can't seem to overcome the problem I am having with NuGet package restore in Visual Studio 2015. I have the following scenarios.
Solution A Structure
--Project A
If I open and build Solution A I see the dialog box that shows the nuget package restore progress and the solution builds successfully.
Solution B Structure
--Project A
--Project B
However, assuming that I have never built Solution A (i.e. fresh pull from TFS), if I open and build Solution B I see the dialog box that shows the nuget package restore progress, but the build fails because Project A fails to build.
What appears to be happening is that that NuGet is restoring the packages for Project B, but not for Project A thus the build failure. To the point, if I look at the references for Project B all of the NuGet references have resolved, but the references for Project A are still broken.
A few points:
I have disabled source control integration for NuGet so I am not checking in the Packages folder.
Each project has its own packages.config file
The build order in Solution B is Project A then Project B
Thoughts would be greatly appreciated.

By default, NuGet creates the solution's packages folder in the solution root, and each project references its package DLLs to that "local" packages folder. In your example, if you open the .csproj file for Project A, you'll probably see that the reference path is something like ..\packages\[package name]\[etc].
So when you do a fresh pull from TFS and build solution B, Project A can't find its DLLs because c:\workspace\Solution A\packages doesn't exist yet (or whatever the absolute path is on your machine).
To correct this, use a shared package folder, created at c:\workspace\packages. To do this, you have to add an additional node to the NuGet.config in each solution (see https://docs.nuget.org/consume/nuget-config-file for details; I am also assuming you have a NuGet folder at c:\workspace\Solution A\.nuget):
<config>
<add key="repositorypath" value="..\..\packages" />
</config>
I used a relative path here, but you can use an absolute path as well, and the documentation says you can use %HOME% as well.
Do this, then restart Visual Studio. The next time you open the package manager, it should ask you if you want to restore missing packages, and assuming you click yes, it will put them in the new location. The last step is to edit the .csproj file and change all instances of ..\packages to ..\..\packages (or you can uninstall and reinstall the package, but I find editing the .csproj a lot faster).

To restore nuget packages do following steps:
Change target framework in project properties
Clean project
Set previous target framework
Rebuild project
I hope, it will help.

Taken from OPs question
howcheng's answer is generally correct with some caveats. After implementing the changes howcheng suggested, I was able to build all of my solutions locally using a central 'packages' folders that all projects look at, regardless of solution. The problem that I ran into though was that when I checked these changes in to TFS, my CI build kicked off and failed!
My CI Build Definition builds both Solution A and Solution B as part of the default XAML process template, not a .proj file. The errors that I was seeing seemed to indicate that Solution A was restoring its packages, but Solution B was not. If I logged onto the build server and opened Solution B in VS 2015 everything worked fine; after Googling for a couple of hours I came across this article which ended up leading me to my answer.
I am developing in Visual Studio 2015 but I am using TFS 2013 for source control and builds. Despite the fact that I have Visual Studio 2015 installed on the build server, MSBuild still references the version of NuGet that shipped with TFS 2013 and NOT with the version included with VS 2015. Once I ran nuget update -self from the TFS Tools directory my build worked correctly.

Could not load file or assembly 'Microsoft.ReportViewer.Common, Version=11.0.0.0

I recently upgraded my n-tier solution from .NET 3.5 vs 2008 to 4.5 visual studio 2012. Every thing went fine apart from crystal reports and I had to install new runtime crystal reports for visual studio 2012 from the following link http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_13_0_5.exe.
After installing the above package I had to resolve some deprecated function and properties of
CrystalViewer and after that reports rendering properly in development environment (Windows 7 64 bit, SQL Server 2005, Visual Studio 2012). When I deployed the package in test environment windows server 2008 R2
the Application failed to load by throwing error
Could not load file or assembly Microsoft.ReportViewer.WebForms, Version=11
I managed to resolve ReportViewer.WebForms error by copying the DLL
from C:\Program Files (x86)\Microsoft Visual Studio 11.0\ReportViewer to bin folder of solution and set property copylocal = true and deployed the package. After that I received the error Could not load file or assembly 'Microsoft.ReportViewer.Common, Version=11.0.0.0 . I tried to search that DLL on my machine but couldn't. when project is running in visual studio, In Debug-> Windows->Module the file is not listed however in global assembly cache that file is installed but I don't know how its installed to global cache and from where . I found one solution that I had to install ReportViewer.msi from microsoft package but if i install this package it asks me to install SQL Server 2012 which I dont wan't. Could any one help me to resolve this issue. Thanks

Dont know if this is good to anyone, but search all these dlls:
Microsoft.ReportViewer.Common.dll
Microsoft.ReportViewer.ProcessingObjectModel.dll
Microsoft.ReportViewer.WebForms.dll
Microsoft.ReportViewer.WinForms.dll
Microsoft.ReportViewer.DataVisualization.dll
You find them in C:\Windows\assembly\GAC_MSIL\..., and then put them in the references of your project.
For each of them say: local copy, and check for 32 or 64 bit solution.

You can install the Microsoft Report Viewer 2012 Runtime and change your references so they point to the ones installed by the runtime.
http://www.microsoft.com/en-gb/download/details.aspx?id=35747
I have installed the runtime without it asking for SQL Server 2012. Before installing try uninstalling any previous versions of report viewer.

As Microsoft.ReportViewer.2012.Runtime has Microsoft.ReportViewer.WebForms, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.ProcessingObjectModel libraries, just run this command on PM Console:
Install-Package Microsoft.ReportViewer.2012.Runtime
Note : If you want to completely remove the old Microsoft.ReportViewer.xxx references, you can remove them from Manage NuGet Packages>Installed Packages menu and then remove the related lines from packages.config file in your project. After that it will not comeback again during building of the project.

Could not load file or assembly 'Microsoft.ReportViewer.Webforms'
or
Could not load file or assembly 'Microsoft.ReportViewer.Common'
This issue occured for me in Visual studio 2015.
Reason:
the reference for Microsoft.ReportViewer.Webforms dll is missing.
Possible Fix
Step1:
To add "Microsoft.ReportViewer.Webforms.dll" to the solution.
Navigate to Nuget Package Manager Console as
"Tools-->NugetPackageManager-->Package Manager Console".
Then enter the following command in console as below
PM>Install-Package Microsoft.ReportViewer.Runtime.WebForms
Then it will install the Reportviewer.webforms dll in "..\packages\Microsoft.ReportViewer.Runtime.WebForms.12.0.2402.15\lib" (Your project folder path)
and ReportViewer.Runtime.Common dll in "..\packages\Microsoft.ReportViewer.Runtime.Common.12.0.2402.15\lib". (Your project folder path)
Step2:-
Remove the existing reference of "Microsoft.ReportViewer.WebForms".
we need to refer these dll files in our Solution as "Right click Solution >References-->Add reference-->browse ".
Add both the dll files from the above paths.
Step3:
Change the web.Config File to point out to Visual Studio 2015.
comment out both the Microsoft.ReportViewer.WebForms and Microsoft.ReportViewer.Common version 11.0.0.0 and Uncomment both the Microsoft.ReportViewer.WebForms and Microsoft.ReportViewer.Common Version=12.0.0.0. as attached in screenshot.
Microsoft.ReportViewer.Webforms/Microsoft.ReportViewer.Common
Also refer the link below.
Could not load file or assembly 'Microsoft.ReportViewer.WebForms'

You can download the nuget package too.

I had the same problem for Winforms.
The solution for me is:
Install-Package Microsoft.ReportViewer.Runtime.Winforms

Simply install Microsot.ReportViewer.2012.Runtime nuget package as shown in this answer https://stackoverflow.com/a/33014040/2198830

Add Microsot.ReportViewer 2010 or 2012 in prerequisite of setup project then it first install Report Viewer if it's not present in "C:\Windows\assembly\GAC_MSIL..." and after installing, it installs set up project

In my case, the 'Microsoft.ReportViewer.Common.dll' assembly is not required for my project, so I simply removed all references (Project -> Add Reference... -> ...) (all requirements from Publish tab the VS2013 removed automatically) and all works properly.

I Had the same problem.
The solution for me is:
You must have the same version of: Microsoft.ReportViewer.ProcessingObjectModel registred in C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel,
like you have registraded in web.config in developer server:
In my case i was only registred the 13. version in my prodution server and i have the 12. version in developer server.
the solution is install the version 12. in the prodution server too
the version 12. :
https://download.microsoft.com/download/A/1/2/A129F694-233C-4C7C-860F-F73139CF2E01/ENU/x86/ReportViewer.msi
Then now i have the version 12. in the prodution and the report work fine.
*** Remember to reset your IIS after instalation

I resolved this problem, searching the dll's file in C:\Windows\assembly\GAC_MSIL\ and copied to bin directory of the proyect deployed. That work for me.

Although rather late, but you can manually download the required DLLs from nuget at the following link:
https://www.nuget.org/packages/Microsoft.ReportViewer.Runtime.Common/12.0.2402.15
Open the file .Rar Archive, extract the dlls and copy them manually to the bin folder of your publish.
This solution worked for me. Hope that helps !!

I solve it by download the reportviewer.exe and install it.
After the installation, all related assemblies will be available in C:\Windows\assembly\GAC_MSIL, then you can refer it in web config