Is there a possibility to set different working directories (VS_DEBUGGER_WORKING_DIRECTORY) for Debug and Release builds in a CMake generated Visual Studio project?
If I write
set_target_properties(${PROJECT_BIN} PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/Debug")
Selecting Project Properties > Debugging > Working Directory will display
C:/Users/Alexandru/Documents/MyProject/Build/Debug
for both Debug and Release configurations, but I want
C:/Users/Alexandru/Documents/MyProject/Build/Release
for the Release configuration.
I also tried setting VS_DEBUGGER_WORKING_DIRECTORY_DEBUG and VS_DEBUGGER_WORKING_DIRECTORY_RELEASE but it seems these properties don't exist.
If there are no configuration specific properties and generator expressions like $<CONFIG> don't work (tested it with VS_DEBUGGER_WORKING_DIRECTORYto no avail), you can still use VS variables:
set_target_properties(${PROJECT_BIN} PROPERTIES
VS_DEBUGGER_WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$(Configuration)")
I just installed from pkg the SDK 3.7 for Facebook.
I see that I need to put there a value for FacebookAppId. However I have 2 apps: one for testing and one for production.
Since I need to support variables for Debug and Release, I am using an Environment file which determines the value based on the configuration value. (Debug or Release)
How can I "tell" the SDK to use the relevant one for each release type, without changing it manually when building it?
I didn't check in the source code. Just the compiled one.
Is there a way to do it?
You can use the Preprocessor macros over here..
How to use it :
Go to Build settings of your project.
Search "Preprocessor macros". Here define your macros like for eg FBDebugAPPID for debug moed & FBReleaseAPPID for release mode.
FBSettings class used to override the default facebook AppId.
Then after add below code in your delegate method..
#if defined(FBDebugAPPID)
**Use your debug app id**
[FBSettings setDefaultAppID:#"DEBUGAPPId"]
#elif defined(FBReleaseAPPID)
**Use your release app id**
[FBSettings setDefaultAppID:#"RELEASEAPPId"]
#endif
Hope it resolve your problem..
You can change you enviornment.plist variables by adding a run script build phase
To add a Run Script Build Phase in Xcode
Select your application target in your project, then select "Build Phases".
In the menu bar, click "Editor", select "Add Build Phase", and then click on "Add Run Script Build Phase".
You should now see a Run Script section in the middle of your Build Phase options, as shown above.
Inside the body of the Run Script Build Phase, paste in the script.
#!/bin/bash
if [ "${CONFIGURATION}" = "Release" ]; then
/usr/libexec/PlistBuddy -c "Set :FacebookAppID 321" "$INFOPLIST_FILE"
else
/usr/libexec/PlistBuddy -c "Set :FacebookAppID 321" "$INFOPLIST_FILE"
fi
Here's a simpler approach,
Recent Xcode project templates already have a DEBUG=1 macro defined for the Debug build configuration.
You can use it in combination with #ifdef
#ifdef DEBUG
#define FACEBOOK_APP_ID #"FB_DEVELOPMENT_ID"
#else
#define FACEBOOK_APP_ID #"FB_PRODUCTION_ID"
#endif
Building my Jenkins/MSBuild solution gives me this error
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(483,9): error :
The OutputPath property is not set for project '<projectname>.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Latest' 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.
[C:\<path>\<projectname>.csproj]
Any ideas?
EDIT
I have this in my .csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Latest|AnyCPU'">
<OutputPath>bin\Latest\</OutputPath>
</PropertyGroup>
I have figured out how it works (without changing sln/csproj properties in VS2013/2015).
if you want to build .sln file:
/p:ConfigurationPlatforms=Release /p:Platform="Any CPU"
if you want to build .csproj file:
/p:Configuration=Release /p:Platform=AnyCPU
notice the "Any CPU" vs AnyCPU
check the code analysis, fxcop, test coverage(NCover) targets, as well as the MSBUILD should be located properly. In my case its:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
but it can be different as you can see microsoft has given 6 cmd options to build code base::AMD (with cross plt, x86 & x64 options) and Windows(cross, x86, x64) and that also when code development happened with default JIT (it can be PreJIT ngen.exe, econoJIT)
I think more than this troubleshooting can be handle using power shell + msbuild. May be helpful for someone ...
Open up your csproj in a text editor and see if you have a property group section, should look something like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Latest|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Latest\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
Do you have a 'Latest' build configuration? If not add the above section to the csproj.
As mentioned by perlyking, rather than editing the csproj XML The following worked for me. Here are the steps I used.
Open the Project Properties.
Select the Build Tab.
Under the Output section, Check that an output path is set. (if not set one, save the project and it should work).
If it is set, click on the "Browse..." button of the output path.
When the folder selection dialog opens, Navigate up one level in the
file browser and then re-select the output folder and click
the "Select Folder" button.
Save the project properties and it should work.
To add to what #James said, I found that if I looked at the project Compile properties in VS2013, the Build Output Path was specified. But when I examined the .csproj file directly, the OutputPath element was missing for the relevant build configuration. So in VS I simply made and reversed a minor edit to the output path, saved it, and that kicked the value into the project file, and I was then able to build.
I was using MSBuild to build multiple .sln files, and had added a new step to build a .csproj file as well, when I encountered this error.
#Saurabh's answer highlighted the root of the problem. However, when fixing it, adding /p:Platform=AnyCPU to the MSBuild Arguments section didn't fix it. I actually needed to update the Platform value on the build step.
All other build steps were using the $(BuildPlatform) variable value (which happened to be "any cpu", with a space in it).
(Had I been building multiple .csproj files, I probably would have created a second variable for the AnyCPU platform.)
For me the answer was to fix all the projects in Build > Configuration Manager.
If you have some projects where the name or platform does not match the solution configuration, you should change it so they all match.
I was running into this issue while updating an older project with additional project configurations for per-environment config transforms.
It turns out that when the project configurations were added to the csproj file, they were inserted after an Import element which caused the issue.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'ProjectName.Dev|AnyCPU'">
...
Moving the Import element after all the PropertyGroup definitions fixed the problem for me.
Relevant similar case: https://stackoverflow.com/a/31072208/2452820
I got this error only when I was publishing my web project. I had mistakenly selected the wrong build configuration when setting up the publish profile.
I had same issue. I have updated my windows platform by using command line. Currently i got updated to windows#5.0.0 version. Then you need to search for file name "SQLite3.UWP.vcxproj". Try to change "v141" to "v140". Currently I am using Visual Studio 2015 professional. If it's Visual Studio 2017, then there is no need to change version in SQLite3.UWP.vcxproj file.
In my case this error happened because the output folder included a dot to make it relative to the current directory. The problem was solved by removing the dot.
The offending Build output path was:
.\bin\Output
The problem was solved by changing it to
bin\Output
The build output path can be found in the Build tab of the project properties, and there is a different path for each combination of Configuration and Platform.
Just had the issue for some service fabric stuff in MSBuild.
First step was right clicking each affected project and pulling up their Properties, selecting the Build tab, then setting the platform target to x64.
Second step was to go into the configuration manager and set each project to also use x64 for Debug and Release.
This was for a VS2017 project.
I had the same problem on a few projects. After adding a new configuration to the projects, the PropertyGroup was added at the very end of the Project file.
Moving the PropertyGroup to right after all the other configurations PropertyGroup fixed the issue.
I hope this helps.
I had this witha slightly unusual SLN/CSPROJ file arrangement:
I had project files:
A.csproj, with configurations "Dev" and "Production"
B.csproj, with configurations "Dev" and "Production"
C.csproj, a "common" library used by both A and B with configurations "Dev" and "Production"
And I had SLN files:
AC.sln, with configuration "Production" - this is used by jenkins to build project A and the common library
BC.sln, with configuration "Production" - this is used by jenkins to build project B and the common library
ABC.sln, with configuration "Dev" - this is used by developers in VS to write new code without having to keep opening different solutions (this answer is a simplified view of a 55-project solution)
I'd made an edit to the common library and introduced a dependency on project A. AC.sln would still build in jenkins but BC.sln gave an error saying:
The OutputPath property is not set for project 'A.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Debug' Platform='AnyCPU'.
It was initially puzzling because we don't even have a Debug config anywhere in any project; find in files for Debug| turned up 0 hits
ABC.sln that the human developers use in VS would also build fine. Building BC.sln gave an error that A.dll wasn't found
When the circular irresolvable problem of C depending on A was removed, everything started working again
This error is misleading and can be caused by a different issue. Check the entire message:
The OutputPath property is not set for project 'myproject'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='myconfig' Platform='AnyCPU'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform.
My build configuration was missing this node in the csproj:
<PlatformTarget>AnyCPU</PlatformTarget>
Despite saying AnyCPU was the selected Platform in the dropdown, the actual xml was not there. Adding it fixed the mismatch between the project and the other project it was referencing.
The OutputPath property is not set for project error message will appear if a Platform environment variable exists (as seems to happen on HP laptops) and the target of MSBuild contains a reference to another Visual Studio project.
After renaming the Platform environment variable my build now works.
It seems the parameter /p:Platform="Any CPU" gets applied to the target solution but doesn't 'carryover' to referenced projects. In my instance, the error message indicated referenced projects were using the environment variable Platform=MCD.
I had two project configs, Debug and Release. When the Release build was used, it was throwing this error. The issue I found was that in the csproj file, the Debug config was near the top and the Release config was all the way at the bottom.
Manually moving the Release build just below the Debug build fixed it.
I'm assuming I did something incorrectly when setting up my build configurations because this doesn't feel like something I should have had to manually adjust.
Edit the properties of the project:
Make sure "Configuration Properties->General->Output Directory" is not blank. Note, it's not called OutputPath here. You can probably copy the value from Intermediate Directory.
I encountered the same problems when build TheXTech (https://github.com/Wohlstand/TheXTech/wiki/Building-on-Windows#building-in-visual-studio-201520172019-and-cmake) recently. And finally I found it is a cmake -A issue. The correct arch for 64 bit on windows is x64, not Win64.
For some more reference, see https://cmake.org/cmake/help/v3.16/generator/Visual%20Studio%2016%202019.html#platform-selection, https://cmake.org/pipermail/cmake/2019-April/069379.html.
Go to Solution properties and change the configuration to Any CPU or X64 or X86, and if build is checked uncheck that for what you are getting error for. By default, project build that for build configuration in solution and throw error as mentioned when building the project.
When I build my solution from the command line using msbuild, I don't get any output from the csharp compiler (Csc) like visual studio does.
For example, if I build my solution in Visual studio I get:
warning CS0162: Unreachable code detected
When I build from command line using msbuild, I get no warning at all (I want the warning to appear!)
Edit: the /verbosity flag does not do the trick
Are you sure you are building the same configuration? Typically Visual Studio will build your Debug configuration by default. MsBuild on the other hand will default to build your Release configuration. Make sure that you have the warning levels set to the same level for both configurations in your project settings.
I think you might need to provide an argument for output verbosity...
From MSDN reference:
Displays this amount of information in the build log. Individual loggers display events based upon the verbosity level. A logger can also be configured to ignore the verbosity setting.
The available verbosity levels are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. /v is also acceptable. For example:
/verbosity:quiet
For our VB.NET websites we use SVN for Source Control and CruiseControl.NET for continuous integration.
To use the SVN build number in the compilation by CruiseControl.NET we need to use Web Deployment Projects. We then replace in the configuration file the Version field with this variable from SVN Labeller
$(CCNetLabel)
This works great but my problem is that this variable causes warnings in Visual Studio for the solution. I'm working to remove all warnings and am left with just these two:
Warning 1 The version string specified for 'AssemblyFileVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
Warning 1 The version string specified for 'AssemblyVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
I have searched for ways to disable certain warnings but they all reference Windows projects not web site/deployment projects which do not contain a Compile tab.
I found information on using #pragma warning( disable : 1000 ) but it appears this is for C++ only and not VB.
It's not a show-stopper but is annoying the hell out of me this lazy Friday afternoon, any help would be appreciated - if reputation sharing was working yet I'd offer someone 20 of my rep for a workable solution :) at least....
It is possible to ignore errors, it is just in a weird place for vb.net.
Open the .vbproj file with notepad or an equivalent and find the <NoWarn> tag and add the id of the error there.
in a default 2008 winforms, I have these warnings already ignored.
<NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
If you used Nant in your build script you could just have it re-write the version prior to compile, and you wouldn't see the warning when you are working on your local machines.
Had a very similar situation with an old VB web project, and we did not want to add the #pragma blocks all over the code calls. For some reason, adding the lines to the <NoWarn> fields did not make Visual Studio builds ignore/suppress the warnings.
However, I found a different approach. By adding this in the .vbproj file after the <NoWarn></NoWarn> area ignored the obsolete warnings in VS 2017:
<DisabledWarnings>612;618</DisabledWarnings>
Common MSBuild project properties
Description of configuration setting:
DisabledWarnings Suppresses the specified warnings. Only the numeric
part of the warning identifier must be specified. Multiple warnings
are separated by semicolons. This parameter corresponds to the /nowarn
switch of the vbc.exe compiler.