Downloaded Cpp-Winrt PhotoEditor Sample from GitHub
Failed on Buld
1- Updated Nugget package for Win2D
2 -Retargeted project for latest SDK
No changes made just tried to build it out of the box.
Final lines of build where the error is
\windows.system.profile.profilesharedmodecontract\2.0.0.0\windows.system.profile.profilesharedmodecontract.winmd
1>Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.17763.0\windows.system.profile.systemmanufacturers.systemmanufacturerscontract\3.0.0.0\windows.system.profile.systemmanufacturers.systemmanufacturerscontract.winmd
1>Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.17763.0\windows.system.systemmanagementcontract\6.0.0.0\windows.system.systemmanagementcontract.winmd
1>Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.17763.0\windows.ui.viewmanagement.viewmanagementviewscalingcontract\1.0.0.0\windows.ui.viewmanagement.viewmanagementviewscalingcontract.winmd
1>Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.17763.0\windows.ui.xaml.core.direct.xamldirectcontract\1.0.0.0\windows.ui.xaml.core.direct.xamldirectcontract.winmd
1>C:\Program Files (x86)\Microsoft Visual Studio 2017 Enterprise\Common7\IDE\VC\VCTargets\Microsoft.Windows.CppWinRT.targets(255,9): error MSB3075: The command "mdmerge.exe #D:\Development\Projects\Sample Peojects\Winrt\PhotoEditor\Windows-appsample-photo-editor-master\x64\Debug\PhotoEditor\mdmerge.rsp" exited with code 5. Please verify that you have sufficient rights to run this command.
1>Done building project "PhotoEditor.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Any help much appreciated
Thanks
This issue is not resolved by the latest Winrt Update either. Only way to resolve is rollback winrt Nugget in Visual Studio.
As far as am aware, any Winrt project template will not build, until you go into Nugget and roll back your winrt version. I used the one just before the latest, builds fine.
Nugget saved the day.
It seems that MsBuild versions 14 does not generate the licenses.licx file when used "manually". When we compile our code from visual studio (v2017), everything works fine, but when done manually, from a batch file, the license file is not generated, and clearly our build fails, because the file is not found.
We use the following command:
msbuild.exe [project_path] /verbosity:normal /t:rebuild /tv:14.0 /p:Configuration=Release,Optimize=true,Platform=AnyCPU,OutputType=Library
I tried every solution on the internet, I've installed .net SDK for windows 7, 8 and 10, and still no luck.
Does anybody have an idea why?
Thank you in advance
UPDATE:
My description was not totally correct. The thing is msbuild does not output the [assembly_name].dll.licenses file. The licenses.licx exists under the "My project.." correctly.
We found that vs 2017 has MsBuild version 15 installed under "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\msbuild.exe" and not under "C:\Program Files (x86)\MSBuild\15.0\bin" like the previous version 14.
By using the version 15, the issue no longer occurs.
The issue is the following:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2863,5):
error MSB3086: Task could not find "AL.exe" using the SdkToolsPath ""
or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the
SdkToolsPath is set and the tool exists in the correct processor
specific location under the SdkToolsPath and that the Microsoft
Windows SDK is installed
I've tried various laborious solutions found on the web, but finally I managed to solved the issue like this:
Go to C:\Windows\Microsoft.NET\Framework\v4.0.30319\
Open with a text editor the file Microsoft.Common.targets
Search for "al.exe" in the file at step 2 and replace the "ToolPath" and "ToolExe" fields with the actual path of the "al.exe" file.
I have setup the two fields at step 3 in the following way:
ToolPath="C:\Program Files (x86)\Microsoft
SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\"
ToolExe ="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\al.exe"
Thanks.
You should register variables before MSBuild call:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat
I use psake, it registers vars automatically.
Alternative solution - add a param:
msbuild.exe "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools"
You need to check the path of "msbuild.exe"
I solved the same problem by changing the path
from
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
to
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin
I need to sign a LOB/enterprise app (built as APPX) for Windows Phone 8.1 for internal distribution. I tried to use MSBuild SignFile task:
<Target Name="SignAppxPhone" AfterTargets="_CreateAppxPackage">
<SignFile
CertificateThumbprint="$(CertificateThumbprint)"
SigningTarget="$(AppxPackageOutput)"
TargetFrameworkVersion="v4.5" />
</Target>
I am getting the following error:
error MSB3482: An error occurred while signing: Data at the root level is invalid. Line 1, position 1.
What's wrong?
MSBuild SignFile task only supports PE files (*.exe, *.dll) and XML, unfortunately. APPX files or CAB files are not supported. I looked in Reflector at the latest version of Microsoft.Build.Tasks.v12.0.dll -- shipped with Visual Studio 2013 Update 3 RC, built on 6/25/2014. It's been reported to Microsoft 6 years ago.
https://connect.microsoft.com/VisualStudio/feedback/details/347731/msbuild-signfile-task-fails-with-cab-files
A reasonable workaround is to <Exec> signtool.exe directly:
<Target Name="SignAppxPhone" AfterTargets="_CreateAppxPackage">
<Exec Command=""$(SignAppxPackageExeFullPath)" sign /fd SHA256 /sha1 $(CertificateThumbprint) /t http://timestamp.verisign.com/scripts/timstamp.dll "$(AppxPackageOutput)"" />
</Target>
How do you get the path to SignTool.exe when using Visual Studio 2012?
In Visual Studio 2010, you could use
<Exec Command=""$(FrameworkSDKDir)bin\signtool.exe" sign /p ... />
Where $(FrameworkSDKDir) is
"c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\"
But in Visual Studio 2012, $(FrameworkSDKDir) is
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\"
and SignTool is in
"c:\Program Files (x86)\Windows Kits\8.0\bin\x64\"
Is there a way of getting the path to this directory other than hard coding (I've tried FrameworkSDKDir and WindowsSDKDir, but both point to the v8.0A directory).
(I am aware of the SignFile MSBuild task, but I can't use that as it doesn't accept certificate passwords.)
I just ran into the same issue. Running the build from a Visual Studio 2012 Command Prompt worked, but it was failing in the IDE. Looking for a detailed or diagnostic log led me to What is the default location for MSBuild logs?, which told me that Visual Studio can't give the diagnostic information I really needed.
Here's what I finally did to fix it.
Open a normal Command Prompt (not the Visual Studio Command Prompt), and run msbuild from that by fully-qualifying the path to MSBuild (%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe). This finally gave me the same error message (error code 9009) that I had been receiving in Visual Studio 2012.
Then, run the same build using "diagnostic" logging (which shows all property and item values) by appending the /v:diag switch.
From this output, I learned that it does have some new properties that I could use to get the location of signtool.exe (excerpt below):
windir = C:\Windows
windows_tracing_flags = 3
windows_tracing_logfile = C:\BVTBin\Tests\installpackage\csilogfile.log
WindowsSDK80Path = C:\Program Files (x86)\Windows Kits\8.0\
WIX = C:\Program Files (x86)\WiX Toolset v3.7\
So, my solution to this problem was to add the following to my *.targets file:
<SignToolPath Condition=" Exists('$(WindowsSDK80Path)bin\x86\signtool.exe') and '$(SignToolPath)'=='' and '$(PROCESSOR_ARCHITECTURE)'=='x86' ">$(WindowsSDK80Path)bin\x86\signtool.exe</SignToolPath>
<SignToolPath Condition=" Exists('$(WindowsSDK80Path)bin\x64\signtool.exe') and '$(SignToolPath)'=='' and '$(PROCESSOR_ARCHITECTURE)'=='AMD64' ">$(WindowsSDK80Path)bin\x64\signtool.exe</SignToolPath>
Hope this helps you, too. I included the preamble of how I got to this point because there are other properties available that may be better suited for your purposes.
Ok, because this was the first hit on google for "SignTool.exe not found on buildserver", I will add additonal Info for VisualStudio 2015 and Windows 10 Enterprise 64bit.
I had to add the ClickOnce Publishing Tools in VisualStudio Setup:
After this you find signtool.exe in
c:\Program Files (x86)\Windows Kits\8.1\bin\x64\
c:\Program Files (x86)\Windows Kits\8.1\bin\x86\
c:\Program Files (x86)\Windows Kits\8.1\bin\arm\
With Visual Studio 2017 installed it is found in
C:\Program Files (x86)\Windows Kits\10\bin\arm\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\arm64\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe
And with Visual Studio 2017 15.7.4 the Path changed again according do the selected Windows 10 Kit you install.
You will get the path generic by starting the Developer Command Prompt for Visual Studio 2017
and type in
where signtool.exe
The following is a more generic approach that can be used to find and set the SignToolPath variable based upon the build machine's specific configuration; by reading the registry:
<PropertyGroup>
<WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<SignToolPath Condition="'$(SignToolPath)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolPath>
</PropertyGroup>
This assumes that $(Platform) resolves to one of arm, x86, or x64. Replace the $(Platform) macro with the appropriate directory otherwise.
EDIT (2017.07.05):
Here is an updated <PropertyGroup> that defers to the new Windows 10 Kit and coerces the ($Platform)=='AnyCPU' to x86:
<PropertyGroup>
<WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<SignToolPath Condition=" '$(SignToolPath)' == '' And '$(Platform)' == 'AnyCPU' ">$(WindowsKitsRoot)bin\x86\</SignToolPath>
<SignToolPath Condition="'$(SignToolPath)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolPath>
</PropertyGroup>
Resolve-Path "C:\Program Files*\Windows Kits\*\bin\*\signtool.exe"
Output:
Path
----
C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\arm\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe
Since for me, today (20/07/2020), all previous suggestions failed, although most of them worked in the past, I have decided to publish a more comprehensive approach, which also addresses later Windows 10 SDKs locations, while still using older ones as fallbacks.
<PropertyGroup Label="UserDefinedVariables">
<!-- Get Windows SDK root folder-->
<WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
<!-- Evaluates the most recent Windows SDK folder containing SignTool.exe -->
<!-- add new versions here, duplicating following line -->
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.18362.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.18362.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.17763.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.17763.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.17134.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.17134.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.16299.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.16299.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.15063.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.15063.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.14393.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.14393.0\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == '' And '$(Platform)' == 'AnyCPU' ">$(WindowsKitsRoot)bin\x64\</SignToolFolder>
<SignToolFolder Condition="'$(SignToolFolder)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolFolder>
<!-- Now we should be able to calculate SignTool.exe fullpath -->
<SignToolExe Condition=" '$(SignToolFolder)' != '' ">$(SignToolFolder)SignTool.exe</SignToolExe>
</PropertyGroup>
<!-- Finally, I would suggest you add the following lines to your project file because they will be quite usefull when things go wrong (and they will) -->
<!-- Send indivual compile bessages to MSBuild output so you check the value of each variable -->
<Target Name="ShowUserDefinedVariables" BeforeTargets="BeforeBuild">
<Message Importance="High" Text="WindowsKitsRoot = $(WindowsKitsRoot)" />
<Message Importance="High" Text="SignToolFolder = $(SignToolFolder)" />
<Message Importance="High" Text="SignToolExe = $(SignToolExe)" />
</Target>
This approach I'm using just relies on the standard build events:
powershell -Command "(Resolve-Path \"C:\Program Files (x86)\\Windows Kits\\10\\bin\\*\\x64\" | Select-Object -Last 1).Path" > stpath
set /p STPATH=<stpath
del stpath
"%STPATH%\signtool.exe" sign ..........
It will cope with new paths as new Windows SDKs get installed and pick the latest one.
I assume that signtool is being used to sign the executables or dlls. With Visual Studio 2019, there is a Developer command line which offers both Developer Cmd and Developer Powershell. Both of these options can resolve the signtool automatically without worrying about the current Windows SDK.
If we want to use the Developer Powershell from the native powershell then we just need to import the module for Developer Powershell. To import the module we need to run the following line in native powershell:
&{Import-Module "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"; Enter-VsDevShell 5ee267ff}
where 5ee267ff varies for each machine. You can find it out in the Properties of Developer Powershell shortcut.
Once the module is imported we can resolve signtool even from native powershell. In the end we can add a script in the post build event of a project such that this script imports the Developer powershell and then we can simply use signtool for signature.