I have the following folder structure for a VS2019 solution/project:
Solution_folder\
my_solution.sln
cpp_project\
my_cpp_project.vcproj
ifort_project\
my_ifort_project.vfproj
...
...
and I want to build specific projects from this solution using the command prompt.
Following the answer here, as well as the MS docs guidance
I tried the following:
devenv %path_to_sln_folder%\my_solution.sln /build Release /project .\ifort_project\my_ifort_project.vfproj /projectconfig Release
Also tried other variations according to the documentation (eg reference the name of the project only or pass the absolute path of the project). However, I always get the following error:
The operation could not be completed
Use:
devenv [solutionfile | projectfile | folder | anyfile.ext] [switches]
The first argument for devenv is usually a solution file, project file or a folder.
You can also use any other file as the first argument if you want to have the
file open automatically in an editor. When you enter a project file, the IDE
looks for an .sln file with the same base name as the project file in the
parent directory for the project file. If no such .sln file exists, then the
IDE looks for a single .sln file that references the project. If no such single
.sln file exists, then the IDE creates an unsaved solution with a default .sln
file name that has the same base name as the project file.
Command line builds:
devenv solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfile [
/projectconfig name ] ]
Available command line switches:
/Build Builds the solution or project with the specified solution
configuration. For example "Debug". If multiple platforms
are possible, the configuration name must be enclosed in quotes
and contain platform name. For example: "Debug|Win32".
/Clean Deletes build outputs.
/Command Starts the IDE and executes the command.
/Deploy Builds and then deploys the specified build configuration.
/DoNotLoadProjects Opens the specified solution without loading any projects.
/Edit Opens the specified files in a running instance of this
application. If there are no running instances, it will
start a new instance with a simplified window layout.
/LCID Sets the default language in the IDE for the UI.
/Log Logs IDE activity to the specified file for troubleshooting.
/NoVSIP Disables the VSIP developer's license key for VSIP testing.
/Out Appends the build log to a specified file.
/Project Specifies the project to build, clean, or deploy.
Must be used with /Build, /Rebuild, /Clean, or /Deploy.
/ProjectConfig Overrides the project configuration specified in the solution
configuration. For example "Debug". If multiple platforms are
possible, the configuration name must be enclosed in quotes
and contain platform name. For example: "Debug|Win32".
Must be used with /Project.
/Rebuild Cleans and then builds the solution or project with the
specified configuration.
/ResetSettings Restores the IDE's default settings, optionally resets to
the specified VSSettings file.
/ResetSkipPkgs Clears all SkipLoading tags added to VSPackages.
/Run Compiles and runs the specified solution.
/RunExit Compiles and runs the specified solution then closes the IDE.
/SafeMode Launches the IDE in safe mode loading minimal windows.
/Upgrade Upgrades the project or the solution and all projects in it.
A backup of these files will be created as appropriate. Please
see Help on 'Visual Studio Conversion Wizard' for more
information on the backup process.
Product-specific switches:
/debugexe Open the specified executable to be debugged. The remainder of
the command line is passed to this executable as its arguments.
/diff Compares two files. Takes four parameters:
SourceFile, TargetFile, SourceDisplayName(optional),
TargetDisplayName(optional)
/TfsLink Opens Team Explorer and launches a viewer for the
provided artifact URI if one is registered.
/useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables
instead of IDE paths for VC++ builds.
To attach the debugger from the command line, use:
VsJITDebugger.exe -p <pid>
I must say that just by removing the part from /project onwards, the build starts ok and finishes without errors, but it is not what I want.
It strikes me as odd, as I believe I'm following the documentation correctly, yet the error message suggests I don't? Also, it doesn't seem to be solution- or project-specific as it's happening with other solutions/projects.
Am I missing anything obvious here?
Thanks
Related
I try to use a shared .pch file, which is compiled in one project and used in others.
However the .pch file is deleted if a .pdb filename of the PCH project differs from .pdb filenames of the other projects.
This page doesn't answer the question: https://devblogs.microsoft.com/cppblog/shared-pch-usage-sample-in-visual-studio/
I don't want to use a same name for all PDBs.
Questions:
1) Why the .pch file is deleted at the start of other projects compilation, which leads to a C1083 error (.pch not found), if PDB names are not equal, not like in that page?
2) I copy pch.pdb and pch.idb files using COPY command, is there a RENAME comand or something, if the copied pch.pdb should be named just like a dependent project's PDB? And where can I find a complete list of Custom Build Step command?
3) I don't understand the purpose of "Additional dependencies" and "Outputs" in Custom Build Step. Can I enter the .pch filename into the dependency list, so it won't be deleted? Does the output list need to contain the dependent project's PDB name, or the pch.pdb, or both?
For some reason (I did this or not) the generated by compiler .pdb file was not $(PlatformToolsetVersion).pdb, but $(ProjectName).pdb . So the copied into other project folders shared .pdb file was pch.pdb in my case, while other projects were expecting different names. And that was triggering a DELETE task in Microsoft.CppCommon.targets , ("Delete the pch file if the pdb file has been deleted."). Instead of changing the output .pdb name I just looked into XCOPY command and made it to change the copied filename to an expected by a specific project (actually then I just added a custom Target with a renaming Copy task right into the project file instead of using the CustomBuildStep calling a xcopy OS's command, as now I learned more about MSBuild).
Then I also changed the generated by Linker output .pdb, just added "Linked" suffix to the name, so there are no conflicts between Compiler's and Linker's PDBs. Not sure if that is a good idea to change the default settings without a big reason.
I guess it's better just to change the Compiler's output PDB to $(PlatformToolsetVersion).pdb , so all projects will use the same name.
That was the first time I had looked into MSBuild and advanced project settings, now it seems to be obvious, that a project using a shared .pdb wants some familiar .pdb name, not a random pch.pdb
Here is my custom Target imported into project files copying the shared .pdb only if it was rebuilt (.idb is not generated in my case):
<Target Name="CopyFreshPchPdb" BeforeTargets="ClCompile"
Inputs="$(PchDir)\pch.pdb"
Outputs="$(IntDir)\$(ProjectName).pdb">
<Message Importance="High" Text="Copying shared pch.pdb" />
<Copy
SourceFiles="$(PchDir)\pch.pdb"
DestinationFiles="$(IntDir)\$(ProjectName).pdb">
</Copy>
</Target>
Did you use the sample code under the github link.
If so, you should download and then use that sample and if you create your own project, you should check your projects carefully.
Borrowing from this tutorial to your project, I think you need to pay attention to whether you have any additional custom targets in your xxx.vcxproj file to delete the PCH file. Therefore, you need to check each xxx.vcxproj file carefully. In vs, there will be no deletion of certain files due to the different .pdb file names of the PCH project and other projects, so check whether there are additional operations of your own.
1) Why the .pch file is deleted at the start of other projects
compilation, which leads to a C1083 error (.pch not found), if PDB
names are not equal, not like in that page?
First of All, make sure that there are no other option to delete PCH file in your projects.
The PCH project is to create a PCH file and the other two projects are to use such file. And every time when you build the two projects(reference the PCH project), and always execute the build of PCH project and then build the two project. So the PCH is always created and later be used in two projects.
Based on it, you should ensure that all three projects create and use the same address for the file.
SharedPCH project
ConsoleApplication1
ConsoleApplication2
In the sample code,the PCH file exists under SharedPchSample\Outputs\Intermediate\Shared\Win32\Debug.
2) I copy pch.pdb and pch.idb files using COPY command, is there a
RENAME comand or something, if the copied pch.pdb should be named just
like a dependent project's PDB? And where can I find a complete list
of Custom Build Step command?
Custom Build Step is under every project-->Properties-->Custom Build Step-->Command Line, and then you can find it.That custom step is just CMD command. And you can execute CMD in that to do extra opertion.
Besides, I guess you want to make those xxx.pdb and xxx.idb be the same name of the project name in order to distinguish one from another. You can right-click on every project-->Properties-->C/C++-->Output Files-->Program Database File Name-->change it and to use $(IntDir)$(ProjectName).pdb. More about Custom Build Steps, you can refer to this link.
I don't understand the purpose of "Additional dependencies" and
"Outputs" in Custom Build Step. Can I enter the .pch filename into the
dependency list, so it won't be deleted? Does the output list need to
contain the dependent project's PDB name, or the pch.pdb, or both?
Additional dependencies is set to use the PCH file's content in the project 1 and 2 which is similar to configuring the address of a reference class library in a c++ project. And I think it might be redundant and since the author has add it which implies that it is well-founded.
And Outputs is the author customized output path, the author changed the output address of the project, and started a new custom output path and a temporary output path.
Actually, the xxx.pch and its pdb and idb file will not be copied into outputpath. So the custom build step is to copied the files into temporary output path. And if you want to copied them into the final outputpath, you can also use these in CustomBuildStep.targets file:
<CustomBuildStep>
<Command>
if EXIST "$(SharedPdb)" xcopy /Y /F "$(SharedPdb)" "$(IntDir)"
if EXIST "$(SharedIdb)" xcopy /Y /F "$(SharedIdb)" "$(IntDir)"
if EXIST "$(SharedPdb)" xcopy /Y /F "$(SharedPdb)" "$(OutDir)"
if EXIST "$(SharedIdb)" xcopy /Y /F "$(SharedIdb)" "$(OutDir)"
</Command>
<Outputs>$(IntDir)vc$(PlatformToolsetVersion).pdb;</Outputs>
<Inputs>$(SharedPdb)</Inputs>
</CustomBuildStep>
And in fact, one project references another project, and the output files of the referenced project are automatically copied to the main project. Perhaps this is because the author's SharePCH project does not generate the pdb and idb files, so those files of the dependent project will not be found in the main project.
I'd like to add that I had a similar situation where a shared .pch file was being deleted but for a different reason related to the .pdb file.
The reason was that the pdb formats were different across the exe and the PCH.lib. The PCH library project has its 'Project Properties -> C/C++ -> General -> Debug Information Format' set to 'C7 compatible (/Z7)'.
When I added a new project exe that depended on the PCH library I had forgotten that new projects default to using 'Program Database (/Zi)' for its 'Debug Information Format'.
So now when the main project is being built and linked with the PCH it would delete the PCH.pch file and complain that the .PCH is missing.
Having all projects with the same matching Debug Information Format was the fix to prevent the PCH from being deleted.
VS2017, SDK/WDK, C++ project
we have a c++ solution (driver) that is shared across developers via Team Foundation Services - visualstudio.com (now called azure devops?).
When I perform a get latest source code, and want to rebuild the solution I get two MSB3030 errors:
"Could not copy the file "C:\path of my colleague his file" because it was not found."
I found it strange that I saw on one of the two errors a path of my colleague his pc. He works on C:\ I'm working on E:\
Unloading the project, I saw he path being set here:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<PackageRelativeDirectory>
</PackageRelativeDirectory>
</FilesToPackage>
We cannot get this solution to build because of the MSB3030. First we have to clean the specific projects individually, rebuild it, then build another project etc.. a few steps to perform manually in the correct order , trial and error, drinking coffee, throwing bananas to the pc and praying that a monkey outputs the code correctly.
Has anyone seen somehting similar regarding MSB3030 errors?
On my pc I see the path of my colleague, but he doesn't see my path (strange!).
C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets(1699,5): error MSB3030:
Could not copy the file 'C:...' because it was not found.
I've set the Any CPU to x64 because it doesn't make any sense for c++.
C++ Windows Driver MSB3030 could not copy the file '' because it was not found
The reason for this issue is that the path of the ItemGroup is an absolute path in the project file:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" ...>
...
</FilesToPackage>
</ItemGroup>
Regardless of whether your colleague has added this file to source control, when you pull the code from the TFS server to your local and put the code in a different local folder, the absolute path will bring you a lot of trouble, you need to manually check the code on the TFS server for this file and you need to modify the absolute path of this file in your project. But this problem will reappear after your colleague updates after you submit your code. Because an absolute path cannot be assigned to two different paths C:\ and E:\.
To resolve this issue, you need to change the absolute path to a relative path in the source code. Generally, we prefer to add this file to the Solution/Project folder, then use the MSBuild Macros $(SolutionDir)/$(ProjectDir) to specify it.
Check Common macros for build commands and properties for some more details.
Hope this helps.
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
I've been using windows in a class I've been taking but I am trying to run a basic code to figure out how to open/close/input/output from files on Xcode and the code I usually use on visual studios isn't working any idea why? thanks!
#include <string>
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
ifstream fin;
ofstream fout;
string input;
fin.open("inputFile.txt");
if(fin.fail())
cout << "File failed to open." << endl;
fin >> input;
fout.open("outputFile.txt");
fout << input;
}
Put your .txt files in the same directory where your main.cpp file is (or anywhere you like).
In Xcode go to Product > Scheme > Edit Scheme > Run (on the left) > Options (middle top)
Down under Options for "Working Directory" check “Use custom working directory” and set it to the directory where you .txt files are located.
To work with the files, you will have to specify just file names, e.g. in_file.open("inputFile.txt"); no path is necessary.
Here's a completely different approach: Have Xcode copy the input file for you.
Select your project in Xcode
Select Build Phases
Click the '+' button to create a new Build Phase
Select New Copy Files Build Phase
Select Products Directory
Click the '+' button to add your file
Click Add Other
Select your input file and click Open
Check the Copy items… checkbox and click Finish
Now every time you build your project, the input file will be copied to the same folder as the executable no matter where it is built. Of course, to see the output file, you'll still need to find the executable in Finder.
The answers don't really explain the problem so I thought I'd do that.
When you pass a relative path like "inputFile.txt" to file APIs, it's treated as relative to the working directory when the program is executed. This is the same as the 'working directory' when you use cmd.exe or Terminal.app or command lines in general. The Unix command pwd ("print working directory") displays the current working directory. On Windows running the command cd with no arguments performs the same function. (On Unix running cd with no arguments will change the working directory to the user's home directory.)
When you run a program from the command line, the command line shell sets the program's working directory. When you run a program from within an IDE, the IDE sets the working directory. Since, unlike on a command line, there's no obvious answer for what the IDE should set as the working directory, Visual Studio and Xcode set the working directory to different locations by default: Visual Studio sets the working directory to $(ProjectDir), the directory containing the Visual Studio project file; Xcode sets the working directory to the build products directory, i.e. the location the executable was written to.
Some possible solutions to your problem are:
Do not use a relative path, and therefore don't depend on the working directory. This isn't much help in making the program more portable, because the absolute paths will also differ between platforms, and so you will still have to 'configure' the program for each platform. In fact using an absolute path is worse, because it means your source code must differ, whereas it would be better to keep that difference confined to each platform's build configuration.
Configure the IDE to use your desired working directory. Visual Studio can be configured by right clicking the project, selecting Configuration Properties > Debugging > Working Directory, and setting the working directory to the desired path (potentially using Visual Studio build variables).
nepete's answer describes how to configure the working directly set by Xcode.
Configure the IDE's build process to copy your data files to an appropriate location. In Visual Studio you would do this in a C++ project by configuring the project's Properties > Configuration Properties > Build Events.
SSteve's answer covers how to configure additional build steps in Xcode.
I'm guessing you have inputFile.txt in the folder that contains your source code. That's not going to work. You need to put it in the folder that contains the generated executable. To find that folder, right-click on your app under Products and select Show In Finder.
This image shows what it looks like for a command line program. It also shows the Finder window that was opened. As you can see, it is a different folder than the one containing the source code.
As suggested by nepete, edit the scheme, but use $PROJECT_DIR as the custom working directory. Helps with moving the project around, or working in two different environments (e.g., home and office).
BTW. $PROJECT_DIR is one of the Xcode Environment Variables, and also helps with passing file names as command line arguments to programs (settable under "Arguments" in the scheme).
I've struggled with the same problem today. I wanted to add C code to my Swift project and my file pointer was always NULL.
Unfortunately, in XCode 9 for iOS app, I couldn't change the working directory. Changing Build phases didn't help me either. After 4+ hours of trial and error, that's what I've come up with finally and it works:
when copying files to XCode, I've chosen "Create groups", but I needed to choose "Create folder references":
I created a new objective-c file (.m) and copied all my C code there.
I left untouched .h files (XCode generated bridging header and my own .h file with public functions declaration). Now my project structure looked like this:
In my dict.m file in place of previous plain c fopen part:
FILE *dic = fopen("dictionary.txt", "r");
I added obj-C code:
NSString *filePath = [[NSBundle mainBundle] pathForResource:#"dictionary" ofType:#"txt"];
FILE *dic = fopen([filePath cStringUsingEncoding: NSUTF8StringEncoding], "r");
And it works now without any problem! It's just amazing!
ps I decided to write this answer in case it will help someone like me and will save them some time. If you know how to change working directory in XCode 9 for iOS, please, leave me a comment - now I am really curious why I can't find it.
I have combined several projects into one solution. I created empty solution and added these projects and here is a blue print of how it looks like:
Root:
Project1 - directory
Project2 - directory
Debug - directory
Main.sln - file
Now I want to direct the executable and dll from both projects to \debug folder shown up of the solution file. I go into project properites >> Configuration Properities >> General >> 'Output Directory' and change the output directory to $(SolutionDir)$(Configuration)\ which is default for a new project.
The problem is that it has no effect on where the output file is created, it is still created in the old destination. The old path for `Output Directory' was .\Debug\ not that it matters.
Could this be because the SolutionDir & Configuration may not be defined? Where can I see their definition or values? I also want to create a new configuration which would be 'Release with Debug' how can I create that using environment variable? Thanks!
My project is MFC/Visual C++.
Add-on:
Where are these identifiers like SolutionDir defined in the scrip? I look up for in .vcxproj file but there is mention of it. I create a new dummy VS2010 project just to look at it's .vcxproj file but these project settings identified are not defined in any place that I can see!
This is most likely caused by specific settings overriding global settings, namely Linker's "output" setting. This happens often as a result of conversion from earlier Visual Studio.
What you need is to go through every setting, paying attention to those whose values are written in bold, and reset to default (select it from dropdown) every setting with 'debug' or 'release', and others as necessary.
There could also be specific settings on files. I usually resolve this by opening project in notepad and removing any excessive settings. Just be careful. Using multiline replace in Notepad++ or any other capable editor helps.
I think I had a similar problem.
What I ended up doing was editing the vcxproj file directly. Find this section and edit it like this for each of your configurations:
<PropertyGroup>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
<OutDir Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(SolutionDir)$(Configuration)\</OutDir>
</PropertyGroup>
I had a similar problem with the Intermediate Directory setting in one of my VS2010 projects. No matter what I set it to, it would always use the default value of $(SolutionDir)$Configuration. Oddly, other projects in the same solution with the same settings worked just fine.
After playing around, I stumbled upon a solution.
Click on the setting in the propery page dialog.
Click on the down arrow button in the right-hand side of the edit box.
Select "inherit from parent or project defaults".
Click "Apply".
Click on the setting and change it to your desired value.
I don't know why this works, but it does. It seems like the macros were not being properly evaluated for whatever reason. Then, after you apply the inherited values, it seems to reset itself and start evaluating the macros properly.