I have searched a lot on the web and I couldn't find a proper solution to this, just workarounds. I wonder whether either VS2015 or WindowsSDK installation is broken.
Here is the thing:
I get issue building (in link phase) and the VS environment reports can't find the Resource Compile executable (rc.exe)
TRACKER : error TRK0005: Failed to locate: "rc.exe". The system cannot find the file specified.
I searched around on my machine and found the binary in:
C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64
So the quick workaround was to add that path to PATH and everything works fine. But I am not really happy about it as I am sure the Windows SDK installer (or VS) should handle this nicely.
If I look into VS IDE -> Project -> Properties -> Configuration Properties -> VC++ Directories and look at "Executable Directories" I am expecting to find the right path in there. So I inspect it by opening MACRO (bottom right) and filtering for WindowsSDK_ExecutablePath: there I see
$(WindowsSDK_ExecutablePath) = C:\Program Files (x86)\Windows Kits\10\bin\x86
$(WindowsSDK_ExecutablePath_arm) = C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\arm
$(WindowsSDK_ExecutablePath_arm64) = C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\arm64
$(WindowsSDK_ExecutablePath_x86) = C:\Program Files (x86)\Windows Kits\10\bin\x86
$(WindowsSDK_ExecutablePath_x64) = C:\Program Files (x86)\Windows Kits\10\bin\x64
As you can see the intel architecture folders point to a generic location (not SDK version specific) that of course doesn't have those binaries. Interestingly enough the ARM folders are correct.
I am trying to understand what has corrupted those folders...
I can guess it's the SDK installer as in the UAP.props file located in
$(WindowsSDKDir)/DesignTime/CommonConfiguration/Neutral/UAP/10.0.16299.0/
I can see this
<WindowsSDK_ExecutablePath_x86>$(WindowsSdkDir)bin\x86;</WindowsSDK_ExecutablePath_x86>
<WindowsSDK_ExecutablePath_x64>$(WindowsSdkDir)bin\x64;</WindowsSDK_ExecutablePath_x64>
although I am not 100% sure as this is post-install so it could be VS changing that.
Any ideas? Suggestions? Anyone who had the same issue and managed to find a proper fix instead of workarounds?
Right, not sure if this is the right one but digging a bit on the issue brought me at this point. What I have found is this strange block of xml code in
$(WindowsSDKDir)\DesignTime\CommonConfiguration\Neutral\UAP\10.0.16299.0\UAP.props
that looks like this:
<PropertyGroup Condition="'$(VisualStudioVersion)' != '' and '$(VisualStudioVersion)' <= '14.0'">
<WDKBinRoot>$(WindowsSdkDir)bin</WDKBinRoot>
<WindowsSDK_ExecutablePath_x86>$(WindowsSdkDir)bin\x86;</WindowsSDK_ExecutablePath_x86>
<WindowsSDK_ExecutablePath_x64>$(WindowsSdkDir)bin\x64;</WindowsSDK_ExecutablePath_x64>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '' or '$(VisualStudioVersion)' > '14.0'">
<WDKBinRoot>$(WindowsSdkDir)bin\10.0.16299.0</WDKBinRoot>
<WindowsSDK_ExecutablePath_x86>$(WindowsSdkDir)bin\10.0.16299.0\x86;</WindowsSDK_ExecutablePath_x86>
<WindowsSDK_ExecutablePath_x64>$(WindowsSdkDir)bin\10.0.16299.0\x64;</WindowsSDK_ExecutablePath_x64>
</PropertyGroup>
Correct me if I am wrong but that doesn't seem to do anything in case you have VS2015 (which is 14.0)
So I appended this after that block:
<PropertyGroup Condition="'$(VisualStudioVersion)' == '14.0'">
<WDKBinRoot>$(WindowsSdkDir)bin\10.0.16299.0</WDKBinRoot>
<WindowsSDK_ExecutablePath_x86>$(WindowsSdkDir)bin\10.0.16299.0\x86;</WindowsSDK_ExecutablePath_x86>
<WindowsSDK_ExecutablePath_x64>$(WindowsSdkDir)bin\10.0.16299.0\x64;</WindowsSDK_ExecutablePath_x64>
</PropertyGroup>
With that change all works. I wonder why this file is populated this way. If you look at the end it includes arm and desktop.arm props. I also wonder if I can create a property file separate to this generic UAP.props.
Of course this fixes only this specific SDK version, you will have to do it for every version installed and, if you install a new one.
Related
I had a few minutes this morning to try to figure out why Visual Studio 2017 rebuild all of my projects in the solution every time I try to run the project. I think I know why this is happening but I'm not sure how to fix it.
I saw these articles:
http://michaelscodingspot.com/2017/04/28/visual-studio-keeps-rebuilding-projects-no-good-reason/
https://ofekshilon.com/2015/08/16/visual-studio-projects-that-just-keep-rebuilding-or-how-quantum-mechanics-mess-up-your-build/
Which got me to turn up build logging.
I now see that VS is looking for PDB files in the OBJ directory and since they are not there(1), VS thinks the project needs to be rebuilt.
3>Project '****.Common' is not up to date. Missing output file 'C:\*******\***\****.Common\obj\Debug\***.****.Common.pdb'.2>Build started.
1) The PDB files are not in the OBJ directory for the assembly projects. They are in the BIN directory. Note that in the main "executable" web project the PDB files are in both the OBJ and BIN directories.
So now I need to make visual studio do one of the following:
Put a copy of the PDB in the OBJ directory for all projects
Make VS check in the BIN directory for the PDB
I did some search but haven't been able to figure out a good set of search terms to find the answer to this one.
Note this is a project that has been developed using VS2012, VS2015, VS2017 and maybe some before 2012, so this might be part of the problem.
This was an issue with assembly project that had been created in older versions of Visual Studio (the projects created in VS2017 don't have the problem).
The workaround I found was to change this part of the .csproj file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<OutputPath>bin\Debug\</OutputPath>
...
</PropertyGroup>
to:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<OutputPath>obj\Debug\</OutputPath>
...
</PropertyGroup>
Note that you can make this change in "Properties / Build" under "Output" by editing "Output path". Also note that this is apparently a workaround because I didn't need to do this to the VS2017 projects. If I go and exhaustively try to figure out the differences between the proj files, I'll update this answer.
There were a few other content items set to "Copy Always" which also forces the whole project to rebuild. I changed those to "Copy if Newer".
I can publish without issues in Visual Studio 2010 but when I attempt to publish with Visual Studio 2013 I am getting this message:
The target "MSDeployPublish" does not exist in the project. \Source2\Web Projects\SubService\subservice\subservice.csproj 0 0 subservice
Can anyone tell me what I need to do to resolve this? It's happening with 2 different projects.
For what its worth;
I had the same issue. Fresly installed Windows 8.1 machine, only installed Visual Studio 2013 (+update1) + Azure SDK's . Create new Web Api Project boom build error -
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
note the v10.0. This is the default fallback when no MSBuild parameter "VisualStudioVersion" has been set. Prior to VS2012 the paths to the target files were hardcoded. Other solutions for this bugs say to remove the following from your csproj which is added for backward compatibility:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But removing this fixes your builds but breaks the publish feature with the original posters error:
The target "MSDeployPublish" does not exist in the project
Note: I have all Azure related SDK parts installed from the web platform installer.
I have resorted to re-adding the above XML part to my csproj file but changing the 10.0 part to 12.0 (=vs2013)
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">12.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
This might break backward compatibility but finally made my Visual Studio 2013 compile the code & made the publish feature work again.
If you don't want to install visual studio on build server, you can use this NuGet package with portable version of the targets: https://www.nuget.org/packages/MSBuild.Microsoft.VisualStudio.Web.targets and modify your csproj file to include it like this:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.12.0.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />
Solution originally posted here: Where is MsDeployPublish located?
(in my case it was already MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0).
after 4 hours I found a post not directly related to this but I took a blind shot and it worked:
Install from "Web Platform Installer" I installed the "Windows Azure SDK for .Net (VS 2013)" and that worked !
I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.
Deploying a Web Application Project from VS2010 RTM causes an error in MSBuild. It complains that the PipelinePreDeployCopyAllFilesToOneFolder target cannot be found.
Is there any way to further diagnose this?
Thank you.
I had the same problem and when I looked in the .csproj file for my web application I had the following lines...
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '8.0'" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="'$(Solutions.VSVersion)' == '9.0'" />
I guess this happened since I had recently upgraded from VS2008 to VS2010. So it looks like the during the conversion process it got all screwed up. To fix it I just replaced those lines with ...
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
After that everything worked as it should.
I've seen the answer given by brodie in several places online, which is strange to me because this task (PipelinePreDeployCopyAllFilesToOneFolder) is not even contained in this target (Microsoft.WebApplication.targets):
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
If you actually go and find this file (on an x64 machine it's in C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, or the version 12.0 equivalent if you're using VS2013) and open it in a text viewer, you'll see it's not there..
It's actually contained in the file that Sayed Ibrahim Hashimi mentions, which is the Microsoft.Web.Publishing.targets file (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets).
So to get this into your MSBuild/.csproj file, include the following:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
Do you have Visual Studio 2010 installed on the machine where you are trying to build? If so then look for a file located at %Program Files(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets it should have that target. If it doesn't then those files may have been corrupted and probably reparing your VS 2010 install should fix it.
I think the Web Deployment targets/tasks are shipped with VS itself and not the .NET framework, so you need VS installed (or you can manually configure the machine)/
Even though this is an old post It still provided some great help!
My setup is using a remote host for Automation of a project built in VS2013.
The remote host doesn't contain all the VS2013 targets when you solely install MSBuild 12.0 and this resulted in the 'Microsoft.Web.Publishing.targets' file not existing.
To get around this target error I had to copy the files from my local VS2013 path and copy this to the remote host in the equivalent location.
I've just upgraded a project from VS2008 to VS2010 but I'm still targeting the 3.5 framework.
In my project file I have a custom task to run SGEN to generate my XmlSerializers.dll. However the version of sgen being run targets the 4.0 framework. As a result, when I run my application I get the error message:
"Could not load file or assembly 'XXXX.XXXX.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
The Sgen task looks like this:
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="#(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
</SGen>
</Target>
There's the ToolPath="$(SGenToolPath)". How do I make it run the version that targets 3.5?
There's a similar question here but it doesn't help me much.
I have solved this by manually configuring the ToolPath to point to the old (version 2.0.50727.3038) version of sgen.exe
On my machine, this is in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I changed the ToolPath attribute to be:
ToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
and this solved the problem.
It seems, by default, it's running the new 4.0 framework version in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
Hope this helps somebody else.
MSBuild uses the registry to get the path to the v3.5 tools. The MSBuild tasks that require v3.5 SDK tools will fall back to the v4.0 path if the path to the 3.5 tools can't be identified - look at the logic used to set the TargetFrameworkSDKToolsDirectory property in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.NETFramework.props if you're really interested.
You can diagnose and fix this problem as follows:
Install Process Monitor and set up a filter to monitor registry access by msbuild (Event class: Registry, Process Name: msbuild.exe, all types of result).
Run your build.
Search Process Monitor for a RegQueryValue access matching "MSBuild\ToolsVersions\4.0\SDK35ToolsPath". Note that this could be be under either "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" or "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft".
If you have a look at this key in the registry, you'll see that it aliases another registry value, e.g. "$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86#InstallationFolder)"
Shortly after this, you'll probably see a "NAME NOT FOUND" result. If you look at where the expected key should be, you'll see that they don't match the key being requested (missing hyphens and possibly no key ending with "-86").
It should be clear what you need to correct. I chose to export the incorrect keys, edit the .reg file and run it to create the correct keys.
One cause of invalid registry entries could be a bug with the Microsoft SDK v7.1 installation:
http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources
I found this to be the easiest way and it works with: <GenerateSerializationAssemblies>On</ GenerateSerializationAssemblies>
<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>
The problem is $(SGenToolPath) isn't set by MSBuild. If you use $(TargetFrameworkSDKToolsDirectory) then it will attempt to resolve the path based on $(TargetFrameworkVersion).
Its helpful to make use of tags for printf() style debugging. Add the following temporally.
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<Message Text="SGenPath: $(SGenPath)" Importance="high"/>
<Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
<Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>
#Craig - Did you manually install the 7.0A framework on your build machine. If so, your problem may be your registry settings and not msbuild. Take a look at LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath and make sure the reg key that is referenced there is valid. (Hint: Make sure the -x86 is there only if the -x86 key exists.)