Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
The build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
Related
I have ASP.NET Core 2.2 app and I've been developing with VS2017, when I started using VS2019 the first thing that happened was the sln stopped building with error pointing to my .csproj files, for example
Severity Code Description Project File Line Suppression State
Error NETSDK1022 Duplicate 'Content' items were included. The .NET SDK includes 'Content' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultContentItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'plugin.json' ForkMeRibbon C:\Program Files\dotnet\sdk\3.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.targets 316
The cause is that in my csprojs I have certain .json files I need to be included at build time, so I have these lines in my .csproj file like below which worked fine with VS2017, but VS2019 complains. After I deleted these lines and everything worked in VS2019.
<ItemGroup>
<Content Include="plugin.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
Then however after I checked my code into github, the build servers of Azure Pipeline, AppVeyor and Travis CI are not happy, they complain that my "plugin.json" file is not found. After some struggling, I was able to fix the build for AppVeyor by changing image: Visual Studio 2017 to image: Visual Studio 2019 in the yml file.
It seems like the build servers are configured with VS2017-ish configurations, unless you tell it to use VS2019 compatible configurations it will not copy over my json file thus causing errors. So far all Windows builds are fine, but the Linux and macOS builds on Azure Pipeline and Travis CI are not, for example here is a failed build on Travis, and message error MSB3030: Could not copy the file "bin/Debug/netcoreapp2.2/plugin.json" because it was not found.
Has anyone else run into this issue and how did you solve it?
I have a solution running on VS 2017 15.7.4 on Windows 7 and works on 6 machines.
On this new machine (same like the others), I am getting the following when I am trying to compile:
The command ""C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "C:\Projects\MySolution\Source\ "" exited with code 1
Could not find file 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\packages.config'.
We tried showing detailed build log, but that wasn't helpful
We rebuilt the machine and same error persisted.
This is a corporate machine with local admin right user account. I am suspecting that the local admin rights might not be implemented properly.
Any suggestions?
NuGet with MSBuild Trying to locate the package.config in VS IDE
folder
Please try to give the full path to the packages.config file:
"C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "<YourProjectPath>\packages.config" -source "C:\Projects\MySolution\Source\"
After hours of investigation, it turned out that the project name is the problem.
The project name (and the namespace) are as follow: MyCompany.MyProject.CMD
(CMD is actually real).
This project was compiling for ages on all machines, however, it didn't do on this particular machine.
We deleted the whole folder structure and recreated it and even formatted the machine.
We tried creating a new project from scratch and calling it the same name - Didn't compile
We tried creating a new project from scratch and called it a different name - Worked!
So solution was changing the project name to MyCompany.MyProject.SomethingElse sorted out the problem. I didn't add CMD as part of the project name, but I will never do and I will pass this to my kids as well.
I didn't want to investigate why it didn't work but CMD resembles the name of the Windows console, would that be the reason? I don't care to know.
So, we were using 2013 TFS dlls in our projects (namely TeamFoundation.Client, TeamFoundation.VersionControl.Client, and TeamFoundation.Common). I recently upgraded the project to use 2017 versions of the above mentioned dlls (We have VS2017). I am getting them from the below folder.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer
After upgrading, when I build my solution, I get the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets(56,5): warning : Resolved file has a bad image, no metadata, or is otherwise inaccessible. The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
I am not familiar with MSBuild so not sure how to proceed.
The error takes me to the following line in the MSBuild code:
GetDependsOnNETStandard Condition="'$(_RunGetDependsOnNETStandard)' == 'true'"
References="#(_CandidateNETStandardReferences)">
<Output TaskParameter="DependsOnNETStandard" PropertyName="DependsOnNETStandard" />
</GetDependsOnNETStandard>
There is an outstanding issue with Visual Studio 2017 and DependsOnNETStandard that should hopefully be resolved in 15.8
I just encountered the same problem today when upgrading a project that was originally created VS 2015 and upgraded to VS 2017.
It looks like the upgrade of the projects misses a few elements in the XML that it needs.
If you edit the csproj files of the effected projects and add
<DependsOnNETStandard>false</DependsOnNETStandard>
to the top PropertyGroup like so:
<PropertyGroup>
...
<DependsOnNETStandard>false</DependsOnNETStandard>
</PropertyGroup>
It should resolve the issue. It did for me.
Details of the issue and discussion around it can be found at:
https://github.com/dotnet/sdk/issues/1544
According to your error log info, seems you are trying to build locally through Visual Studio or MsBuild command not TFS build.
Suggest you to use the latest version of dlls, Microsoft.TeamFoundationServer.Client and also upgrade your Visual Studio 2017 to latest version. For The system cannot find the path specified. issue try to
Clean All Projects.
Unload All Projects
Reload All Projects.
ReBuild Solution
Another way is :
Close the solution
Delete bin folder
Delete all obj folders
Open solution and build
If all of above still not work, suggest you add a more detail log and sample code for troubleshooting.
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
When building a CLR Storedprocedure Project using MSBuild on our build server (Team City) we're getting the following error:
error MSB4019: The imported project
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SqlServer.targets"
was not found. Confirm that the path
in the declaration is
correct, and that the file exists on
disk
I've checked to see if the file exists on disk and sure enough it doesn't. I've checked on my own machine and it does exist.
I don't really want to start copying over files manually to the build server.
Here's the line from the csproj file which is being imported to the proj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildToolsPath)\SqlServer.targets" />
Here's the line from the proj file which is being run by our Team City Server:
<Import Project="..\$(ProjectName).csproj"/>
My question is really:
Where does this file comes from? Is it part of the Visual Studio install for example.. Or is there some re-distribution package somewhere to allow me to compile this project on our build server?
Thanks
BTW.. if i just copy the file onto the Build server it does actually work.
Dave
Looks like it's part of the v2.0 framework install that gets moved into the v3.5 directory after that's added. You can either reinstall v2.0 of the framework or manually copy the file out of the v3.5 folder.
Up to Visual Studio 2012, the SqlServer.targets was deployed on the .NET Framework's msbuild.exe location, like
c:\Windows\Microsoft.NET\Framework\v4.0.30319\
c:\Windows\Microsoft.NET\Framework\v3.5\
c:\Windows\Microsoft.NET\Framework\v2.0\
In modern versions, from Visual Studio 2013 on, the MSBuild tool is included with Visual Studio, and the MSBuild.exe and .targets files are deployed in their own folder. For example fo Visual Studio 2013:
c:\Program Files (x86)\MSBuild\12.0\Bin\
(NOTE: 12.0 is the "internal" version number of VS2013)
IMPORTANT NOTE: SqlServer.targets only exists if you install SQL Server Data Tools in your Visual Studio Deployment.