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.
Related
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?
I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the 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.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)
I am using VS 2013 to build a webservice. When it is built, the Web.config file is being renamed "{projectname}.dll.config".
There is a step, _CopyAppConfigFile where it gets renamed, showing in the Output window. I can work around this, by setting the web.config to be copied always, this results in two files, web.config and x.dll.config, which I can live with, but I'd like to avoid it completely if anyone knows how.
EDIT: Looks like this is a result of a MSBuild file, located at:
C:\Program Files\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets
I can recreate this in a default install of Visual Studio 2013 in a C# ASP.NET MVC project. I noticed it because I am starting to transition to Visual Studio 2013, but our build server is still on Visual Studio 2012; our setup project was failing after one of my commits because the superfluous config file that I had harvested on my machine was not being generated on the build server.
This appears to be a discrepancy between the way things worked in the previous version of MSBuild 4.0 / Visual Studio 2012 and the new version MSBuild 12.0 / Visual Studio 2013.
In Visual Studio 2013, the $(ProjectConfigFileName) property is initialized to Web.config [1], which is copied to $(AppConfig) [2], which causes _CopyAppConfigFile to run [3], resulting in an unnecessary config file being named and copied over to the bin directory.
In Visual Studio 2012, the process is similar, except that its version of Microsoft.WebApplication.targets is missing this part that's in the 2013 version:
<!-- Instruct ResolveAssemblyReferences in MS.Common.targets to generate suggested binding redirects. -->
<PropertyGroup>
<AutoUnifyAssemblyReferences>false</AutoUnifyAssemblyReferences>
<AppConfig Condition="'$(AppConfig)' == '' And Exists('$(ProjectConfigFileName)')">$(ProjectConfigFileName)</AppConfig>
</PropertyGroup>
The key is that AppConfig line. Since that AppConfig reference is missing in the 2012 version, then _CopyAppConfigFile doesn't run under Visual Studio 2012, resulting in the intended behavior (i.e., the file is not copied).
In Visual Studio 2013, it looks like they added this line so that the build process could offer to fix up binding redirects for you by double-clicking on them in the Errors list in Visual Studio. When Microsoft added this, it seems no one noticed that it resulted in an extra config file being generated and copied to the output folder. So it seems to me as if it is a bug (but a mostly harmless one, since the config file is superfluous) in the new build process in Visual Studio 2013. Since it was conflicting with the Visual Studio 2012 build process on my build server, I added an extra post-build step to blow away the extraneous file:
<Target Name="AfterBuild">
<Delete ContinueOnError="true" Files="$(TargetPath).config" />
</Target>
And then you can feel better knowing that it's not a problem with your particular project or system setup, it's just the way Visual Studio 2013 does things now.
File locations referenced above:
[1] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
[2] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets
[3] C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.CurrentVersion.targets
I think you have the wrong project type. Did you create it as a web project? Is this in your csproj file?
{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}
From
http://www.mztools.com/articles/2008/mz2008017.aspx
349c5851-65df-11da-9384-00065b846f21 = Web Application
fae04ec0-301f-11d3-bf4b-00c04f79efbc = C# Project
Hth,
Ojf
Have been trying to build a solution which contains a number of projects and keep getting a recurring error.
I have managed to get the build to partially succeed but always get the error shown below:
C:\Builds\1\MBS.Payments.Forms.Mvc\MBS Payment Forms MVC\Sources\MBS.Payments.Forms.Mvc\MBS.Forms.Payments.Web\MBS.Forms.Payments.Web.csproj (979): 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.
I have navigated to the file in which the error is being generated where this code is highlighted:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Currently I have both Visual Studio 2010 Premium and a evaluation version of Visual Studio 2012 Ultimate installed, I am currently working on this application in Visual Studio 2010.
below is the code block in which the erroneous code is found:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
Please could anyone advise on why this error is being generated and how it could be resolved.
Check the two locations:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
and
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications
Do either of these have the .targets file present? Personally I find it in both, but I'm guessing you don't (at least according to the error it's not in the v11.0 folder).
Your condition checks for VisualStudioVersion and VSToolsPath properties to see if they are missing, then sets them. One or both of these must be set already or it would be pointing to the v10.0 folder.
According to http://blogs.msdn.com/b/webdev/archive/2012/08/22/visual-studio-project-compatability-and-visualstudioversion.aspx, this is probably caused by opening the project in VS2012.
To fix, I'd either get a v11 copy of the .targets (there are some changes between the two from what I can see, maybe it wasn't correctly installed when you did the setup?) or revert to using the v10 version.
If using Visual Studio 2013 or newer and TFS 2010, you can edit your Build Definition to include a new MSBuild argument.
/p:VisualStudioVersion=10.0
As CryoFusion87 pointed out, the solution that worked for me was to remove the whole <PropertyGroup></PropertyGroup> tag and its content.
This tag is added to support opening projects from VS 2010 and VS 2012. See more in here: http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx
I am now using VS 2013 and this is not needed.
the <PropertyGroup></PropertyGroup> tag gets added to the project file when you open it in Visual Studio 2012, I was able to open the project file in a text editor, remove the PropertyGroup and it built successfully
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.