Given:
Visual Studio 2019 Web API .Net Core 3.1
Wix Toolset 3.1.1
Windows 2016 Azure DevOps 2019
All I'm trying to do is use Wix Toolset to create an .msi file for a very simple WebAPI project.
If I run the SetupProject it works perfect:
2> C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe -d"DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\\" -dSolutionDir=C:\apps\Solution1\ -dSolutionExt=.sln -dSolutionFileName=Solution1.sln -dSolutionName=Solution1 -dSolutionPath=C:\apps\Solution1\Solution1.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\apps\Solution1\SetupProject1\ -dProjectExt=.wixproj -dProjectFileName=SetupProject1.wixproj -dProjectName=SetupProject1 -dProjectPath=C:\apps\Solution1\SetupProject1\SetupProject1.wixproj -dTargetDir=C:\apps\Solution1\SetupProject1\bin\Release\ -dTargetExt=.msi -dTargetFileName=SetupProject1.msi -dTargetName=SetupProject1 -dTargetPath=C:\apps\Solution1\SetupProject1\bin\Release\SetupProject1.msi -dWebApplication1.Configuration=Release -d"WebApplication1.FullConfiguration=Release|AnyCPU" -dWebApplication1.Platform=AnyCPU -dWebApplication1.ProjectDir=C:\apps\Solution1\WebApplication1\ -dWebApplication1.ProjectExt=.csproj -dWebApplication1.ProjectFileName=WebApplication1.csproj -dWebApplication1.ProjectName=WebApplication1 -dWebApplication1.ProjectPath=C:\apps\Solution1\WebApplication1\WebApplication1.csproj -dWebApplication1.TargetDir=C:\apps\Solution1\WebApplication1\bin\Release\netcoreapp3.1\ -dWebApplication1.TargetExt=.dll -dWebApplication1.TargetFileName=WebApplication1.dll -dWebApplication1.TargetName=WebApplication1 -dWebApplication1.TargetPath=C:\apps\Solution1\WebApplication1\bin\Release\netcoreapp3.1\WebApplication1.dll -out obj\Release\ -arch x86 Product.wxs
2> C:\Program Files (x86)\WiX Toolset v3.11\bin\Light.exe -out C:\apps\Solution1\SetupProject1\bin\Release\SetupProject1.msi -pdbout C:\apps\Solution1\SetupProject1\bin\Release\SetupProject1.wixpdb -cultures:null -contentsfile obj\Release\SetupProject1.wixproj.BindContentsFileListnull.txt -outputsfile obj\Release\SetupProject1.wixproj.BindOutputsFileListnull.txt -builtoutputsfile obj\Release\SetupProject1.wixproj.BindBuiltOutputsFileListnull.txt -wixprojectfile C:\apps\Solution1\SetupProject1\SetupProject1.wixproj obj\Release\Product.wixobj
2> SetupProject1 -> C:\apps\Solution1\SetupProject1\bin\Release\SetupProject1.msi
However, if I run it in Azure DevOps the DeEnvDir is undefined causing build to get hung (I'm guessing). I let it run for 12 minutes to be sure.
d"DevEnvDir=Undefined if not building from within Visual Studio"
Compile:
C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe -d"DevEnvDir=*Undefined if not building from within Visual Studio*" -dSolutionDir=C:\agent2\_work\4\s\ -dSolutionExt=.sln -dSolutionFileName=Solution1.sln -dSolutionName=Solution1 -dSolutionPath=C:\agent2\_work\4\s\Solution1.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\agent2\_work\4\s\SetupProject1\ -dProjectExt=.wixproj -dProjectFileName=SetupProject1.wixproj -dProjectName=SetupProject1 -dProjectPath=C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj -dTargetDir=C:\agent2\_work\4\s\SetupProject1\bin\Release\ -dTargetExt=.msi -dTargetFileName=SetupProject1.msi -dTargetName=SetupProject1 -dTargetPath=C:\agent2\_work\4\s\SetupProject1\bin\Release\SetupProject1.msi -dWebApplication1.Configuration=Release -d"WebApplication1.FullConfiguration=Release|AnyCPU" -dWebApplication1.Platform=AnyCPU -dWebApplication1.ProjectDir=C:\agent2\_work\4\s\WebApplication1\ -dWebApplication1.ProjectExt=.csproj -dWebApplication1.Proje...
Windows Installer XML Toolset Compiler version 3.11.2.4516
Copyright (c) .NET Foundation and contributors. All rights reserved.
This is because there is no environment variable for $(DevEnvDir) when you build your solution in azure devops. You can try to define the DevEnvDir environment variable on your build server or add it into variables for build definition.
About defining variables, please view this document. Here is a ticket with similar issue you can refer to .
Related
Given:
Visual Studio 2019 Web API .Net Core 3.1
Wix Toolset 3.1.1 (latest)
Wix Toolset Extension for Visual Studio 2019
Windows 2016 Azure DevOps 2019
All I'm trying to do is use Wix Toolset to create an .msi file for a very simple WebAPI project.
The build works perfectly locally of course, but when it runs in Azure Builds I get following error because an extra folder is getting added (win-x64)
Here's a snippet of build script in Azure Pipelines:
- task: VSBuild#1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:PublishProfile=FolderProfile'
configuration: '$(buildConfiguration)'
ication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'
Link:
C:\Program Files (x86)\WiX Toolset v3.11\bin\Light.exe -out C:\agent2\_work\4\s\SetupProject1\bin\Release\SetupProject1.msi -pdbout C:\agent2\_work\4\s\SetupProject1\bin\Release\SetupProject1.wixpdb -cultures:null -contentsfile obj\Release\SetupProject1.wixproj.BindContentsFileListnull.txt -outputsfile obj\Release\SetupProject1.wixproj.BindOutputsFileListnull.txt -builtoutputsfile obj\Release\SetupProject1.wixproj.BindBuiltOutputsFileListnull.txt -wixprojectfile C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj obj\Release\Product.wixobj
Windows Installer XML Toolset Linker version 3.11.2.4516
Copyright (c) .NET Foundation and contributors. All rights reserved.
C:\agent2\_work\4\s\SetupProject1\Product.wxs(28): error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'. [C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj]
##[error]SetupProject1\Product.wxs(28,0): Error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\WebApplication1.exe'.
C:\agent2\_work\4\s\SetupProject1\Product.wxs(31): error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\appsettings.json'. [C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj]
##[error]SetupProject1\Product.wxs(31,0): Error LGHT0103: The system cannot find the file 'C:\agent2\_work\4\s\WebApplication1\bin\Release\netcoreapp3.1\win-x64\publish\appsettings.json'.
Done Building Project "C:\agent2\_work\4\s\SetupProject1\SetupProject1.wixproj" (default targets) -- FAILED.
Done Building Project "C:\agent2\_work\4\s\Solution1.sln" (default targets) -- FAILED.
Build FAILED.
I'm trying to build a VS project in CentOS. I installed dotnet-sdk-2.2 via yum install dotnet-sdk-2.2.
When executing dotnet msbuild myproj.vcxproj I get:
Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
mtproj.vcxproj(19,3): error MSB4019: The imported project "/Microsoft.Cpp.Default.props"
was not found. Confirm that the path in the <Import> declaration is correct, and that the
file exists on disk.
Googling results with many solutions but for Windows. what can I do to resolve this over Linux/CentOS?
According to your error message it's a C++ project.
Please check this document,the dotnet CLI only supports .NET / .NET Core / .NET Standard projects.
C++ projects are part of the visual studio tooling (c++ workload). The dotnet CLI doesn't contain the visual c++ compiler or the necessary windows SDKs. So it's not supported to build C++ projects directly using dotnet msbuild in Windows, not to speak of CentOS.
To build C++ projects in linux, you can try g++ compiler, you can find many related info about how to use it online.
Also, maybe you can try using GCCBuild to build vcxproj files in Linux. It simple uses same structure of vcxproj but uses GCC to compile and build. Thanks to Roozbeh.
Is there some way to add the Node JS Tools for Visual Studio (NTVS) test adapter to a VSTS hosted agent?
The Visual Studio docs on hosted agent mention "Node.js Tools 1.0 for Visual Studio 2015" in the list for the "Hosted" agent, but the "Hosted VS2017" has no mention of any Node.js Tools
So how can you use the test adapter?
refer to these steps to run test on Hosted VS 2017 agent.
Modify project file (njsproj)
:
<!--<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>-->
<VSToolsPath>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0</VSToolsPath>
Copy NodeJsTools folder in C:\Program Files (x86)\Microsoft Visual Studio\2017\[Community, professional or enterprise]\Common7\IDE\Extensions\Microsoft to your ntvs folder
Add these files to source control and check in changes
Queue build with Hosted VS 2017 agent.
Build definition steps:
NPM install (Working folder: $(Build.SourcesDirectory)\NodejsConsoleApp1)
Visual Studio Test task (Test assemblies: NodejsConsoleApp1\NodejsConsoleApp1.njsproj; Search folder: $(System.DefaultWorkingDirectory); Test platform version: Visual Studio 2017; Path to Custom test adapters: NodejsConsoleApp1\ntvs
Yep there are similar question out there, but they are not related to VS 2017:
Visual Studio Build - Azure 2.9 SDK
MSBuild MSB4096 error with Azure SDK 2.9.1
I've recently upgraded from VS 2015 to VS 2017. On my local dev computer everything works fine and the Azure application (with Azure SDK 2.9.6) builds and starts.
But on the TeamCity server (MS Build Tools 2017 - Tool version 15.0) I get the following error:
MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\Windows
Azure Tools\2.9\Microsoft.WindowsAzure.targets" was not found. Confirm
that the path in the declaration is correct, and that the
file exists on disk.
The build server/MSBuild tries to find the Microsoft.WindowsAzure.targets in the directory:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\Windows Azure Tools\2.9\
But it is actually in the directory:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\[VisualStudioVersion]\MSBuild\Microsoft\VisualStudio\v15.0\Windows Azure Tools\2.9\
[VisualStudioVersion] can have the following values "Community", "Professional" ,"Enterprise"
Yes, I've the build tools installed (https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15 ).
Yes, I already copied the whole Windows Azure Tools folder to BuildTools\MSBuild\Microsoft\VisualStudio\v15.0, but then I get another error in my F# project:
MSB4057: The target "GetTargetFrameworkProperties" does not exist in
the project.
It seems like the new MS Build Tools 2017 doesn't work properly with Windows Azure. Are there any workarounds yet? Or is the only option to switch back to an older MSBuild?
The new standalone BuildTools currently don't support Windows Azure targets.
So if you want to use the new MSBuild 2017 with Azure SDK you have to install a full VS 2017 installation on your build server.
Note: You may have to restart the TeamCity (agents) in order to recognize the MSBuild path. After running a build you can see the used MSBuild paths in the tab 'parameters':
MSBuildTools15.0_x64_Path: C:\Program Files (x86)\Microsoft Visual Studio\2017\[VS_VERSION]\MSBuild\15.0\bin\amd64
MSBuildTools15.0_x86_Path: C:\Program Files (x86)\Microsoft Visual Studio\2017\[VS_VERSION]\MSBuild\15.0\bin
[VS_VERSION] can be Community, Professional or Enterprise
I still got the GetTargetFrameworkProperties error from the F# project, this was resolved by adding the flag:
/p:VisualStudioVersion=15.0
to the MSBuild task.
For more information see https://github.com/Microsoft/msbuild/issues/1888
I use Visual Studio 2012 and this is the only version of Visual Studio I have installed. I need to build certain C++ projects with the v90 platform toolset (of Visual Studio 2008), but I can't install Visual Studio 2008.
I understand it is possible to use the v90 platform toolset by installing Windows SDK 7.0. How exactly is it done? If I simply use the web installer of 7.0 SP1, I still don't see v90 as one of the possible platform toolsets.
It is possible, but apparently requires some maneuvering and will not support building MFC applications. The following assumes that VS2012 update 4 is installed, but neither VS2010 nor VS2008 are installed.
Download the x86 DVD of SDK 7.0 SP1 (GRMSDK_EN_DVD.iso). Mount the ISO or extract its contents, and manually install the MSI files from the following folders under the Setup folder:
WinSDK (this may fail, it's ok)
WinSDKBuild
WinSDKInterop
WinSDKTools
WinSDKWin32Tools
vc_stdx86
vc_stdamd64
winsdk_intellidocs
WinSDKIntellisenceRefAssys
WinSDKNetFxTools
Download the x86 DVD of SDK 7.1 (GRMSDK_EN_DVD.iso). Mount the ISO or extract its contents, and manually install the MSI files from the same folders listed above (except winsdk_intellidocs, which doesn't exist).
Go to C:\Program Files (x86)\Microsoft Visual Studio 9.0. Copy the following files from Common7\IDE to VC\bin:
msobj80.dll
mspdb80.dll
mspdbcore.dll
mspdbsrv.exe
Now you should be able to choose the v90 platform toolset in Visual Studio 2012 and build with it.
Explanations (and sources):
Individual MSI installation is based on the second workaround from this connect report.
The requirement for both 7.0 and 7.1 is based on this question (both VS2010 and VS2008 are required to use v90 in VS2012!). SDK 7.1 is not needed if you have VS2010.
DLL/EXE copying requirement is based on yet another question. If you do not copy them, you will see error MSB6006: "CL.exe" exited with code -1073741515.
In addition to this answer I want to add that
You can install SDK 7.0 simply by running setup, there is no problem with it.
You can install SDK 7.1 by running setup, if you remove Microsoft Visual C++ 2010 Redistributables first and fix following registry values:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Client]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full]
"Version"="4.0.30319"
You can (and probably should) restore these values to whatever they originally were after installation is complete.
Do not forget to install KB2519277 after this, it updates compilers in SDK 7.1 to SP1.
You don't need to copy any dll. MSBuild uses
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VC#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VS#ProductDir
to set up paths. It's probably wise to fix them to point to "C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\" and "C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\" as it might be useful elsewhere in build process.
Same goes for version 10.0 if you plan to use Windows7.1SDK toolset.
Use WindowsSdkVer.exe to set current SDK to 7.1 to defeat cryptic error in Microsoft.Cpp.x64.Targets(63,5) about missing unnamed required file. If the tool gives you error, then set these values manually:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows#CurrentInstallFolder
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows#CurrentInstallFolder
to point to newly installed SDK. The tool needs some registry keys from Visual Studio installation to work properly, but there are many and I'm not sure which are important.
Reboot. None of the above asks you to, but without reboot I got errors when trying to build a project.
As an aside, SDK7.1 adds v100 toolset, but it won't work, saying something about Could not find WindowsSDKDir variable from the registry. This is because v100 actually requires SDK7.0A which comes with Visual Studio 2010 and is not available separately. Windows7.1SDK toolset is the one which utilises VC2010 compilers if you need them.
Microsoft.Cpp.Win32.*.props files have a lot of relevant stuff if something fails in build system.
One addition/update for VS2013 to Yodans answer:
My working setup:
VS2013 has to use VS2010 libs
Using WinSDK 7.1 (Yodans 2.) build tools (v100) in VS2013
clean install, uninstalling everything mentioned in the sdk release notes (can be downloaded at http://www.microsoft.com/en-us/download/details.aspx?id=8279 under category Details)
Microsoft Windows SDK for Windows 7 (7.1) (the Windows SDK core-component files)
Application Verifier
Debugging Tools for Windows
Windows Performance Toolkit
Microsoft Help Viewer 1.0
Microsoft Visual C++ 2010 Redistributable
Microsoft Visual C++ 2010 Standard Edition
Additionally removed all .NET and VC++ related MS Software (not tested if necessary)
choosing Windows7.1SDK as Platform Toolset in VS2013
error MSB6006: "CL.exe" exited with code -1073741515
cl.exe uses msobj100.dll, mspdb100.dll, mspdbcore.dll and mspdbsrv.exe
Added to PATH C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Build works and binary is usable ( So now its tested Yodan ;-) )
My mistake:
copied files in 7. above to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin (Yodans 3.), believing this dir is in PATH, but it was not!
So better do as sugested by Yodan and tested by myself in 8. above
p.s. same answer is solving this problem:
Visual Studio 2013: CL.exe exited with code -1073741515