I have an existing msbuild script that's been working for a long time and it WAS working today, but all of a sudden my ItemGroup that searches for files recursively is no longer getting translated. I simplified the script below which still doesn't work:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Main" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Main">
<ItemGroup>
<CsProjFilesLoad Include="C:\Temp\**\*.csproj" />
</ItemGroup>
<Message Text="CsProjFilesLoad: #(CsProjFilesLoad)" />
</Target>
</Project>
This is what gets printed
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.19
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\Temp>msbuild "Build.xml" /t:Main
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 02/08/2020 07:51:51 AM.
Project "C:\Temp\Build.xml" on node 1 (Main target(s)).
Main:
CsProjFilesLoad: C:\Temp\**\*.csproj
Done Building Project "C:\Temp\Build.xml" (Main target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.35
I'm very confused at why the ItemGroup is no longer returning me a semi-colon list of the csproj files. Can anyone provide any insight? I rebooted my machine in case some environment thing went wacky but still no luck. I can run the same script on another machine and it works perfectly fine like this:
C:\Temp>msbuild "Build.xml" /t:Main
Microsoft (R) Build Engine version 12.0.40629.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 2/8/2020 8:04:12 AM.
Project "C:\Temp\Build.xml" on node 1 (Main target(s)).
Main:
CsProjFilesLoad: C:\Temp\Sample\Sample.csproj
Done Building Project "C:\Temp\Build.xml" (Main target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.04
so obviously some weird thing has occurred on my machine. Any advice would be much appreciated.
It turns out one of the directories in my file structure was locked/couldn't be accessed and instead of msbuild displaying an error it just didn't translate to what it could access.
What caused this was I deleted my workspace from Azure, deleted all the files in that folder structure but one of the .vs folders didn't delete as it was in use by Visual Studio, I ignored that and recreated the same workspace without deleting that .vs folder. That's when I started encountering the error. Just for grins I deleted the workspace again, closed visual studio, deleted the entire folder structure and re-downloaded everything from source control and that resolved the issue.
Related
So I was updating ASP.Net codebase from the target framework of 4.5 to 4.8 because Visual Studios complains that 4.5 is no longer supported. It builds locally; however, this broke the TeamCity build. So I moved the VS build step to use VS 2015 in TeamCity and installed VS on my local machine. I then copied the MSBuild v14.0 files to the TeamCity server.
But I still get this message:
3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
But that file does exist and I can see it.
So why is the build saying in can't find the file that obviously exists?
I have read in some other stackoverflow post to update the <Import in the csproj but I think mine looks correct?
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
Any hints or direction would be appreciated.
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.
So, I'm trying to build a project I just installed Visual Studio to build this specific project (it is in vb6 so I needed to use the Visual Basic tools extension because i had Visual Studio 2015 installed). I have no programming knowledge on this area, only web.
And when I try to build it it gives me this error:
------ Build started: Project: Proyecto1, Configuration: Debug x86 ------
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(3812,5):
error MSB3030: Could not copy the file "obj\Debug\Proyecto1.exe"
because it was not found. Done building project "Proyecto1.vb6proj" --
FAILED.
Build FAILED.
Then I click on the error and it send me to that piece of code
<!-- Copy the build product (.dll or .exe). -->
<Copy
SourceFiles="#(IntermediateAssembly)"
DestinationFolder="$(OutDir)"
SkipUnchangedFiles="$(SkipCopyUnchangedFiles)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
Retries="$(CopyRetryCount)"
RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
UseHardlinksIfPossible="$(CreateHardLinksForCopyFilesToOutputDirectoryIfPossible)"
Condition="'$(CopyBuildOutputToOutputDirectory)' == 'true' and '$(SkipCopyBuildProduct)' != 'true'">
<Output TaskParameter="DestinationFiles" ItemName="MainAssembly"/>
<Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>
</Copy>
<Message Importance="High" Text="$(MSBuildProjectName) -> #(MainAssembly->'%(FullPath)')" Condition="'$(CopyBuildOutputToOutputDirectory)' == 'true' and '$(SkipCopyBuildProduct)'!='true'" />
I already saw the existent questions for this problem and the solutions didn't worked for me.
In my case it was like #Hans says it was my Antivirus fault (Avast) I disabled it to test if that was the problem, deleted the bin and debug folders and re-opened the solution and it worked perfectly.
P.D. Remember to add you solution folder to your antivirus exclusions.
I'm attempting to build a project using MSBuild (v4.0) on a 64-bit machine. For some reason, MSBuild is attempting to load a 32-bit extension, and I cannot figure out why. I've reduced the problem to the smallest set in order to demonstrate the issue.
Using the following MSBuild project file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Target Name="test">
<Message Text="bin path: $(MSBuildBinPath)" />
<Message Text="extensions path: $(MSBuildExtensionsPath)" />
<Message Text="extensions path (x86): $(MSBuildExtensionsPath32)" />
<Message Text="extensions path (x64): $(MSBuildExtensionsPath64)" />
</Target>
</Project>
I get this output:
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 8/27/2010 9:56:35 AM.
Project "D:\5\test.proj" on node 1 (default targets).
test:
bin path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319
extensions path: C:\Program Files (x86)\MSBuild
extensions path (x86): C:\Program Files (x86)\MSBuild
extensions path (x64): C:\Program Files\MSBuild
Done Building Project "D:\5\test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
MSBuild obviously knows about the 32bit and 64bit extensions path, and from the binary path it seems clear that I'm running the 64-bit MSBuild.exe, but for some reason it believes that extensions should be loaded from Program Files (x86) instead of Program Files. This is causing me trouble, as I have an extension that I need loaded, that MUST be loaded correctly in a 32bit/64bit process, and it will not load (MSBuild is attempting to load the 32bit version in a 64bit process).
Why?
I filed a bug on Microsoft Connect, and it was closed as "By Design", with this explanation:
You're exactly right -- this has changed, and strictly speaking, it's wrong now. However, this was a conscious decision. The reason it was changed was that very many extensions (such as .targets files) installed by other products are only installed in the 32 bit program files location. They did not anticipate 64 bit scenarios, but generally would work just fine in 64 bit MSBuild. When a user runs 64 bit MSBuild, which is quite common now because it's the default for Team Build 2010, MSBuildExtensionsPath would have in the past resolved to the 64 bit Program Files as you expect. However this meant that all those .targets files were not longer found and the build failed. It was not practical to get all those products to fix their setup authoring, especially since it had already shipped to customers. So we made the change to make MSBuildExetnsionsPath always point to the 32 bit location. Almost nobody seems to really want the 64 bit location, and those people can change to MSBuildExtensionsPath64. It was really a question of the least bad option here.
I accept the evidence, but I disagree with the conclusion. I believe that authors of broken installers deserve to have their extensions not work on 64-bit machines.
This is already cross-posted at MS Connect:
https://connect.microsoft.com/VisualStudio/feedback/details/560451
I am attempting to override the property $(MSBuildExtensionsPath) when building a solution containing a C# web application project via msbuild. I am doing this because a web application csproj file imports the file "$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets". This file is installed by Visual Studio to the standard $(MSBuildExtensionsPath) location (C:\Program Files\MSBuild). I would like to eliminate the dependency on this file being installed on the machine (I would like to keep my build servers as "clean" as possible). In order to do this, I would like to include the Microsoft.WebApplication.targets in source control with my project, and then override $(MSBuildExtensionsPath) so that the csproj will import this included version of Microsoft.WebApplication.targets. This approach allows me to remove the dependency without requiring me to manually modify the web application csproj file.
This scheme works fine when I build my solution file from the command line, supplying the custom value of $(MSBuildExtensionsPath) at the command line to msbuild via the /p flag. However, if I attempt to build the solution using the MSBuild task in a custom msbuild project file (overriding MSBuildExtensionsPath using the "Properties" attribute), it fails because the web app csproj file is attempting to import the Microsoft.WebApplication.targets from the "standard" Microsoft.WebApplication.targets location (C:\Program Files\MSBuild). Notably, if I run msbuild using the "Exec" task in my custom project file, it works. Even more notably, the FIRST time I run the build using the "MSBuild" task AFTER I have run the build using the "EXEC" task (or directly from the command line), the build works.
Has anyone seen behavior like this before? Am I crazy? Is anyone aware of the root cause of this problem, a possible workaround, or whether this is a legitimate bug in MSBuild?
Steps to Reproduce:
1) Create a new empty solution in MSVS 2008 (Fake.sln)
2) Add a new C# web application to the solution (WebApplication1.csproj)
3) Close MSVS
4) Copy the contents of "C:\Program Files\MSBuild\" to a directory called "MSBuildExtensions" in the directory containing your solution.
5) rename the directory "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications" so that WebApplication1.csproj will not be able to import Microsoft.WebApplication.targets from that location.
6) Create a custom MSBuild project file called "TestBuild.proj" in the same directory as the solution. It should have the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="BuildMSBuild">
<PropertyGroup>
<MSBuildExtensionsPath>$(MSBuildProjectDirectory)\MSBuildExtensions\</MSBuildExtensionsPath>
<BuildThis>Fake.sln</BuildThis>
</PropertyGroup>
<Target Name="BuildMSBuild">
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);" Targets="Clean" />
<MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);"/>
</Target>
</Project>
7) execute "msbuild TestBuild.proj" from a MSVS command prompt (note: the build may succeed the first time, but will fail if you run more than once)
Did you try setting the environment variable MSBuildExtensionPath in the CMD prompt and then running your build?
For example:
C:\> SET MSBuildExtensionsPath=C:\My\MSBuild\Extensons
Then on this project file:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text='MSBuildExtensionsPath="$(MSBuildExtensionsPath)"' />
</Target>
</Project>
you will get the following output:
c:\Users\chuckeng\Desktop\ConsoleApplication1>"C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe" my.proj
Microsoft (R) Build Engine Version 3.5.30729.4926
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 6/25/2010 1:04:05 PM.
Project "c:\my.proj" on node 0 (default targets).
MSBuildExtensionsPath="C:\My\MSBuild\Extensons"
Done Building Project "c:\my.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
This works from v4.0 as well. Although, support is generally better in v4.0 for things like this. And, v4.0 is 100% backward compatible (bugs not withstanding). So, you can build your v3.5 and prior projects with v4.0. Just select ToolsVersion 3.5.
msbuild my.proj /tv:3.5
Hope this helps...
Chuck England
Visual Studio
Program Manager - MSBuild
This is a bug in MSBuild 3.5 but it is fixed in MSBuild 4.
If you can, switch to MSBuild 4 (you still can compile your 3.5 projects), otherwise you'll have to override the property in the project file.
It works fine if you override MSBuildExtensionsPath directly in the web app .csproj file.
<PropertyGroup>
<MSBuildExtensionsPath>C:\Users\madgnome\Desktop\msbuild</MSBuildExtensionsPath>
<!-- It works too with relative path -->
<!--<MSBuildExtensionsPath>..\msbuild</MSBuildExtensionsPath>-->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Don't know if this might help anyone in the future, but I was able to use the following at the top of my file and it works as I would expect in both 32 and 64 bit build environments.
<PropertyGroup>
<MSBuildExtensionsPath Condition=" '$(MSBuildExtensionsPath64)' != '' ">$(MSBuildExtensionsPath64)</MSBuildExtensionsPath>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>