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.
Related
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)
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"
I have been pulling my hair for the past couple days trying to figure out how set up a CI/CD process just to build a simple WPF solution and create the MSI setup file ("artifact") using Azure DevOps Pipelines. I have tried using Build VS Installer to accomplish this. My main problem is that I don't know exactly what am I doing wrong or what steps I am missing and I can't find clear instructions on this anywhere.
Here's what I've tried:
Using the Hosted 2017 agent pool and the basic .NET Desktop Template. Problems:
Create .msi file(s) from VS Installer project(s) as last task or before publishing artifact):
2018-11-28T22:57:56.3186071Z DEBUG: Aggregated: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com
2018-11-28T22:57:56.3211382Z Now running (C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.com) with Arguments ("D:\a\1\s" /Build "release|any cpu" /Out "D:\a\1\b\BuildInstaller_Log_20181128225756.txt")
2018-11-28T22:58:54.0015320Z Done running DevEnv process. Success = True.
2018-11-28T22:58:54.1169279Z ##[warning]No .MSI files were found, please check your build-configuration. If this is expected, you might consider to use the default Visual Studio Build task instead of this custom Installer task.
2018-11-28T22:58:54.1434410Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
Creating my own build agent as outlined in the documentation. I have Visual Studio Community 2017 with the VS Installer Projects extension installed on that server. I followed the steps from this related answer. Results:
2018-11-29T17:46:03.9813075Z DEBUG: Aggregated: System.Object[]\devenv.com
2018-11-29T17:46:04.4346060Z ##[error]Cannot retrieve the dynamic parameters for the cmdlet. The specified wildcard character pattern is not valid: System.Object[]
2018-11-29T17:46:04.4716416Z ##[section]Finishing: Create .msi file(s) from VS Installer project(s).
I also tried DevEnv Build from the market place instead of the DutchWorkz one and still couldn't get an .msi file. Can someone please show me some clear steps on how to achieve this simple goal?
I was able to figure out why I was getting the specific error message below and wanted to share in case it helps anyone out in the future.
DEBUG:
Aggregated: System.Object[]\devenv.com
[error]Cannot retrieve the dynamic parameters for the cmdlet. The specified wildcard character pattern is not valid: System.Object[]
The issue was that I had two versions (Professional and Enterprise) of Visual Studio 2017 installed on my private build server. Once I removed one of them, everything worked great. Not sure if there's a way to get it working with both installed, but I didn't need both.
Microsoft Visual Studio Installer Projects extension is present in windows-latest runner. Find more here
In short, use an agent with windows-latest vmimage and build via devenv.exe instead of MSBuild.
I am developing simple Asp.net MVC 5 app which is working ok and visual studio 2015 can build it without any issues, but when i use MSBuild.exe command line tool it shows alot of errors which relates to typescript files compilation (primarily from node_modules folder).
I am trying to use Jenkins CI tool to automate my deployment routine, in order to do so i have to build my app using MSBuild.exe.
My project has tsconfing.json file in the root folder which contains following lines to exclude node_modules folder (it is inside #AngularComponents folder):
"exclude": [ "Scripts/**", "WrittenScripts/#AngularComponents/**" ]
But somehow MSBuild.exe command line tool just ignores it during build.
Does anyone have any ideas how to configure it to take into account my tsconfig? or tell MsBuild to not to build my node_modules folder?
Thank you in advance!
I finally figured it out.
First of all i have to use this MsBuild:
1) C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe;
Secondly, for some reason msbuild messed up my tools version 4.0 so I need to pass additional parameter to msbuild:
2) /tv:14.0
Thirdly, my typescript files have some /// references to node_modules\#types folder and for some reason it shows me any errors but not related to the reference one.
3) so i have to run npm install to recover #types packages.
After these steps msBuild builds successfully without any errors.
Thanks for all!
Windows 2012 R2 build server, TeamCity 8.1.2, nuget.exe 2.8.1
After enabling and testing a build configuration that involved a regular full build clean followed by a NuGet restore, we enabled incremental VCS updates and have enabled NuGet update on our build configuration. The build configuration now fails with this error during NuGet update:
[Step 1/4] update: Updating NuGet packages for OurSolutionName.sln
[22:20:10]NuGet command: D:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe update D:\TeamCity\buildAgent\work\52034b1c4c1ab5f5\OurSolutionName.sln -Verbose -RepositoryPath D:\TeamCity\buildAgent\work\52034b1c4c1ab5f5\packages
[22:20:10]Starting: D:\TeamCity\buildAgent\temp\agentTmp\custom_script9174264003705363137.cmd
[22:20:10]in directory: D:\TeamCity\buildAgent\work\52034b1c4c1ab5f5
[22:20:10]Scanning for projects...
[22:20:10]The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TypeScript\Microsoft.TypeScript.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. D:\TeamCity\buildAgent\work\52034b1c4c1ab5f5\proofs\MvcRouting\MvcRouting\MvcRouting.csproj
[22:20:11]Process exited with code 1
[22:20:11][Step 1/4] Step Update nuGet packages (NuGet Installer) failed
The key is the \v10.0\ in the MSBuild path. I looked at the csproj file mentioned in the error, and it uses the standard compatibility logic to determine the Visual Studio version and set the paths appropriately, only falling back to 10.0 if VisualStudioVersion is null. I checked in the solution file and I have confirmed that the VisualStudioVersion is 12:
Microsoft Visual Studio Solution File, Format Version 12.00
Visual Studio 2013
VisualStudioVersion = 12.0.30110.0
Any ideas why NuGet update doesn't seem to be picking up the correct Visual Studio version?
The VisualStudioVersion will be defined when you build from within Visual Studio. On the build server it will not be defined by default.
You should be able to set it through an environment variable on the machine or in Team City. Or just update your project so it fallsback to version 12 instead.
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">12.0</VisualStudioVersion>
NuGet does not read anything from the solution itself. It just uses it as the base directory from which to find any packages.config files that exist in any subdirectory below the solution.