When I create a WiX project and try to build it with the platform set to 'x64', I get errors in my build output like this:
------ Build started: Project: MyProject, Configuration: Release x64 ------
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets(444,7): error : The OutputPath property is not set for this project. Please check to make sure that you have specified a valid Configuration/Platform combination. Configuration='Release' Platform='x64'
Done building project "MyProject.wixproj" -- FAILED.
------ Build started: Project: MyProject, Configuration: Debug x64 ------
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets(444,7): error : The OutputPath property is not set for this project. Please check to make sure that you have specified a valid Configuration/Platform combination. Configuration='Debug' Platform='x64'
Done building project "MyProject.wixproj" -- FAILED.
It claims that there's no output path set for the project, but of course, there is. The output path is set to bin\x64\Debug\ for the debug configuration and bin\x64\Release\ for the release configuration. So what's the error?
Also, the error doesn't show up in the Errors window. Now, I know it's a rookie mistake to blame the compiler, but I'm beginning to wonder... Is this a build tool bug, or am I missing something stupid?
If you open your .wixproj file in a text editor, you will see that your x64 configuration items are at the bottom of the file (below the import of the standard WiX build targets) and your x86 configuration is at the top (above the import). If you shift the XML for the x64 config so that it's adjacent to the x86 config, then you will find that your project builds properly for both platforms.
I had the same issue. In my case, however, the wixproj file was not malformed, but the
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
was missing completely. Just made a copy of the x86 config, saved and all is good.
First make sure you are using the latest version of the WiX toolset (v3.5 or current v3.6 drop). If this still reproduces there it sounds like a bug. Please do file it here: http://sourceforge.net/tracker/?group_id=105970&atid=642714
Warning: WiX can insert multiple instances of this in different <PropertyGroup>s:
<DefineConstants>Foo=Bar</DefineConstants>
<DefineConstants>Foo=</DefineConstants>
thus overriding the settings that you want. You need to carefully edit the .WIXPROJ file manually and look out for duplicates.
Related
I'm using MSBuild to build a project with configuration set to a custom configuration. I have a referenced project (a library) which does not have any cutom configuration set to it. The issue is, it seems like MSBuild is building the project and the project references with the same configuration.
I'm using this command:
msbuild.exe <path>\<project>.csproj /p:DeployOnBuild=true /p:OutDir=<dirpath> /p:Configuration=<CustomConfig>
Im having the follow error:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(724,5):
error : The OutputPath property is not set for project
'referencedProject.csproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this
project. Configuration='CustomConfig' Platform='AnyCPU'. You may be seeing
this message because you are trying to build a project without a
solution file, and have specified a non-default Configuration or
Platform that doesn't exist for this project. [path\ReferencedProjectcsproj]
I cannot find anything related online, if anyone can point me to anything or help me out with this, that would be great.
I found a work around, posting it here in case someone ends up in the same scenario.
The project library did not have the custom configurtation so, i had to edit the csproj file to change the condition of build configuration to this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' Or '$(Configuration)|$(Platform)' != 'Debug|AnyCPU'">
This will force the compiler to take the leading configurations if it is in release mode or any custom configuration that is mentioned.
I have no found any way that will command MSBuild to choose different configuration project dependencies.
I am trying to build and run one demo in Visual Studio 2017.
But with compilation, the debug mode target gets the name with 'D' suffix instead of without it. (Specifically PDIconsoleD.exe instead of PDIconsole.exe) But when trying to run project already built project, it cannot find the file, because it looks for the name without this suffix (PDIconsole.exe).
I tried to run the file from the file browser, it got error, that I would like to debug.
Many thanks
PL.
Go to your project properties and check what is target name on different configurations. It might be that on debug mode it is changed to add suffig of 'D' so just delete that so it will be the same name for debug and release.
I have a VS2008 solution in which there is a C++ project (we'll name it Project1 for clarity's sake). The project's purpose is to test the executable generated by the compilation of another C++ project (Project2) in the same solution. The executable being tested (Project2.exe) is built in the same folder than the executable generated by our Project1 (Project1.exe). Here's what is looks like in the build folder:
Build_path/Debug
Project1_Debug.exe
Project2_Debug.exe
Build_path/Release
Project1.exe
Project2.exe
The project Project1 is set in the Configuration Manager to always build in debug (even when the solution build in release), since there is a problem with one of the third party tool used in Project1 when we compile in release. So any preprocessor definitions that would identify Project1's configuration would always be set to debug. Knowing this and the fact that Project2 build in release when the Solution Configuration is set to build in release, how can project1 locate project2 when building the solution in release, since it always search in the same folder it is located in?
Constraint(s):
I cannot change the build folder structure
As mentioned, using Project1's preprocessor definitions with a macro such as $(Configuration) won't help here, since $(Configuration) would be bound to Project1's configuration and would always be set to debug.
I am using GetModuleFileName to fetch Project1's executable and from that location (which is always in the debug folder), the only solution I found was to search for a macro representing the current solution configuration, which would help me to fetch Project2.exe in the release folder when building my solution in release (but Project1 still in debug) by adding ../Release in my path and stay in the debug folder when Project2 is actually in the debug folder (when the solution is built in debug) by adding ../Debug in my path.
A little pseudo-code would look like this:
If SOLUTION_CONFIGURATION == DEBUG // Project 1 and Project2 is in debug folder
add ../Debug in my research path to locate Project2_Debug.exe from Project1_Debug.exe's location
Else if SOLUTION_CONFIGURATION == RELEASE // Project1 is in debug and Project2 is in release folder
add ../Release in my research path to locate Project2.exe from Project1_Debug.exe's location
End if
There are no standardard macros for representing configurations and version information.
However, MS maintains a list of predefined macros for Visual Studio.
Some may be available with other compilers.
P.S. I found the site by searching the internet using the keywords "Visual Studio predefined macros".
First off, I did already check and found this question which is similar to my issue:
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
The solution there isn't usable though as VS2013 doesn't have the VC++ Directories settings anymore. It looks like those are configured through environment variables now, but I'm not sure how to fix this without borking the 32-bit builds.
====================================
I am working on porting a project from 32-bit to 64-bit code and so I created an x64 platform in my visual studio project. The debug build works fine, but the release build give me this error:
1>MSVCRT.lib(ti_inst.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
Setting the VERBOSE:Lib option, it appears to be trying to find the default system libraries in the x86 paths instead of x64. This pastebin includes the compiler and linker commandlines (yes, this is MACHINE:X64) as well as the VERBOSE:Lib output.
http://pastebin.com/Bqu0udRi
I'd like to know a) how do I fix this, and b) why would this only affect the release build? Looking at the library progress log for the debug build, I can see it is picking up the x64 paths and libraries correctly.
Perhaps it affect only Release build, because you have different properties set in this build configuration or different property sheets attached.
First of all, open Visual Studio, then go to Property Manager and expand Release | x64 configuration. Check if any other .props are placed above the Microsoft.Cpp.x64.user. If yes, check if they do not overwrite include/library directories.
Also compare what .props are attached in Debug | x64 configuration. Maybe some of them are required but not attached in Release?
If all this is fine, verify Microsoft.Cpp.x64.user itself. Go again to Property Manager, right click it and then Properties -> VC++ Directories. Check if Library Directories entry contains something like:
$(VCInstallDir)lib\amd64
$(VCInstallDir)atlmfc\lib\amd64
$(WindowsSDK_LibraryPath_x64)
The above entries are copied from my x64 .props file.
Lastly, switch to Solution Explorer and then check Project Properties - your project may have defined additional local directories, that are missing in this configuration (or shouldn't be present). Simply compare content in Debug and Release configurations.
Hope this helps.
One more thing:
You may also want to check global macros used by Visual Studio (or, to be more precise, what do they expand to). I ran into very serious problem once, after (with no reason) one of standard directory macro was overwritten to wrong value.
I am trying to build audEERING UG's openSmile library on Windows. I need to use this library with VS2005 but because setup with VS2005 isn't supported - my idea is to build it on VS2010 and then connect to VS2005 project. I can't somehow make it work so I will write step by step what I do:
I download latest openSMILE 2.1 version from official website: http://www.audeering.com/research/opensmile#installation
I open http://www.audeering.com/research-and-open-source/files/openSMILE-book-latest.pdf and read setup section for Windows
I open ide/vs10/openSmile.sln file with VS2010 and get this error:
error : Project "E:\Workplace\openSMILE-2.1.0\thirdparty\portaudio\build\msvc\portaudio.vcxproj" could not be found.
But I read in documentation that PortAudio is only one of variants so I ignore problem as I don't use it in my project:
You can select several configurations from this solution which represent the various combinations
of the standalone version (simply Release and Debug configurations) and support of OpenCV
and PortAudio (named accordingly).
I build openSmileLibClassif manually - done.
I build openSmileLibLibsvm manually - done.
I don't do anything iwth openSmileLibPortaudio
I build SMILEExtract manually and get an error:
error MSB4019: The imported project "E:\Workplace\openSMILE-2.1.0\openSMILE-2.1.0\ide\vs10\gnuGpl.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I check in the project directory if there is gnuGpl.props file but I can't find it. I try to download previous version of the lib then: openSMILE-2.0-rc1. After unzip there is an gnuGpl.props file in the previous version. I copy it to 2.1 version.
Try to build SMILEExtract again. I get other error:
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(E:\Workplace\openSMILE-2.1.0\openSMILE-2.1.0\ide\vs10\Debug\SMILExtract_Debug.exe) does not match the Linker's OutputFile property value (E:\Workplace\openSMILE-2.1.0\msvcbuild\SMILExtract_Debug.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
2>LINK : fatal error LNK1104: cannot open file 'E:\Workplace\openSMILE-2.1.0\msvcbuild\openSmileLib_Debug.lib'
I think that maybe copying gnuGpl.props from previous project to new one is bad idea so I try to build openSMILE-2.0-rc1 instead and I get same error as in point 8.
Can someone tell me what am I doing wrong?
After I've deleted openSmileLibPortaudio from my project directory (because usage of it disables ASIO and I need it) and compiled project 3 times errors disappeared and I have only warning about considering output file location.
change your mode from debug to release!
in manual:
Important note for building on Windows: Some versions of Visual Studio
always select the "Debug" configuration by default instead of the "Release" configuration.
However, you always want to build the "Release" configuration, unless you are
an openSMILE developer. Thus, you mus always select the "Release" configuration
from the drop-down menu, before clicking on "Build Solution" !!
right mouse-key onopenSmileLib go to project->add->exist item,
choose src\examples\simpleMessageSender.cpp and click add to openSmileLib project, finally, recompile the code.