I'm in the process of upgrading a Visual C++ 6 project to Visual Studio 2010, and I've been replacing the post-compile steps of copying files to a common location with having the output file put directly in the final location. However, for the *.tlb files that are being generated, there is an option (in project properties -> MIDL -> Output) to specify the filename. When I put the full path there, it looks reasonable in the command line (says /tlb "full\path\to\filename.tlb"). However, when it actually compiles, the file doesn't get put in the right place, and the command that was executed according to the log was /tlb ".\filename.tlb"). I'm hesitant to specify the path as the output directory, because then it will output the XXX_i.c and XXX.h files into that location as well, which isn't what I want.
Is there any way to get Visual Studio to respect the setting I actually put in the option, instead of doing what it wants?
I just had this problem as well and I finally found out why. Even though this question is a bit old, since it's still open I'll post my solution...
In addition to the MIDL settings under the project properties, there's the same settings under the IDL file itself. Just right-click the IDL file -> Properties -> MIDL -> Output.
This did it for me. Seems illogical, though.
I also ran into same situation so I specified the output file as a relative path and it generated the tlb file in the correct location instead of the default location
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.
When I run the Debug in Visual Studio for a project, fopen function works fine. It tries to open a file contained in the project and that I added in the filter "Resources".
But when I run .EXE file of my project, I get the null pointer exception: 0x000005c.
When I added the file to be in the same directory as my .EXE file, the exception disappeared.
This is the instruction I use :
fopen(&filename, "rb");
I know it is adviced to use fopen_s instead, but the file is not found anyway...
Apparently, the file is searched always in the current directory...
So, how to include the file in .EXE and make the path of the file relative to the .EXE, at a way it will be contained in the .EXE and not added to the directory where there is .EXE?
You can't include the file in the .exe. You just need to make sure that the file is in the same directory as the .exe.
If you really, really want to only use one file, you could either:
Zip the .exe and the text file together and make sure you include in a readme that the text file needs to be in the same location as the .exe
Use an array/struct/some other way of storing the contents of the file in the program itself, and reference that instead of using a file (I assume you don't care about users being able to edit this data outside of an instance of the program since you wanted it bundled with an executable, so the file is unnecessary in that case)
The reason the program only works when you put the file in the directory of the .exe is because the path to the file is defined in the program as something like .\file.txt or file.txt. When the file isn't in the same directory as the .exe, the program will try to find it, and will be unable to, which is why you get the error. It works when you debug because you have a copy of the text file in the same location as the debug .exe.
EDIT: I would also ignore the warnings about fopen_s and other variant's that append a _s to the end of a command - these are windows specific, non-standard, and in most cases, pointless. If you know this program will only be used in windows environments and you're not doing something for school where you are required to write standard code, I suggest you use the _s variants for the sake of security, but it will reduce portability of your code.
I was trying to #include a cpp file with some functions so I can use that cpp file later with other projects. It gave me an 'already defined in .obj' error and since then that .cpp file was like binded with my project. (I understood that's not the way, the answer here helped me with the already defined)
If I exclude the .cpp file from the project, remove it from the directory and remove the #include line it still looks for it:
c1xx : fatal error C1083: Cannot open source file: 'std.cpp': No such file or directory
Diagnostic:
Outputs for D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\CBMAIN.CPP|D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\STD.CPP: (TaskId:15)
It shouldn't be looking for the std.cpp at all, I removed it! So is there a way I can reset the project and recompile so that the program doesn't look for it? I already tried Rebuild and Clear -> Build Project
When I ran across a similar problem with VS Express, I wound up having to open up the the .vcxproj file (which is just XML), and remove the offending
< ClInclude Include="FILEPATHANDNAME" > tags.
Many of the solutions here will not work
Fullproof method:
Open the vxproj file that is giving you trouble in a text editor.
remove all references to the file it cannot find.
OK, I have no idea how I did it but I'm still going to try to write what I did.
Save all and Close solution
Open the .vcxproj file (not .sln)
Build -> Clean [Project Name]
Save all and Close
Open the .sln file again.
Build -> Project Only -> Clean Only [Project Name]
Build -> Project Only -> Build Only [Project Name]
That's exactly what I did and worked for me. I think the main thing to do is clean, save, close, open, build, but I'm not sure.
In Solution Explorer you can select/deselect option "Show All Files".
Try both options and make sure excluded file is not included in project for both of them.
That's what I had:
I used "Show All Files" option (so you can see all the files in project directories). I excluded one of my .cpp files from project. However, it behaved as this file is in project.
That's how I managed to fix it:
I switched "Show All Files" off and saw this file still belongs to project! So I excluded this file once again.
As I see, that's a known issue.
This worked for me, hope it will be useful for someone else.
Try to verbose builder output to see exact steps of what's going on. I suppose, you use Visual Studio, right?
Go to menu "Tools -> Options"
In options dialog, select "Projects and Solutions -> Build and Run"
Change current mode of "MSBuild project build output verbosity" from "Minimal" to something like "Diagnostics" or "Detailed".
Rebuild your project and investigate Output windows
Builder dump should shed more light on your current settings (I suspect you have more references to that file than you expect)
This happened to me because I renamed folder from inside the IDE. None of the above solutions worked. The only way to fix this is by opening vcproj in notepad and you should see the offending files in the <ItemGroup>. Just delete those lines.
Or sometimes, like in my case, the issue is simply in the naming of the folders in the location. I had a very long path with folders that I like to name with special characters so they show up at the top and it's easy to access them.
As soon as I put my solution in a folder just in D: drive, the issue was gone.
When I renamed a file, I found I had to go to SolutionExplorer, Source File, select the file, first exclude from Project, then re-add it to project, and rebuild the solution it lives in. It was still showing up as the old file name under Source Files for me.
I had the same problem, but I had another .sln worked fine. After tooling around with the Project->Properties-> to make them look identical, nothing worked. I opened both .vcxproj files and copied the contents of the working version into my non-working version. (I noticed that the two files had different lengths. The non-working version was longer by about 20 lines.) I just changed the RootNameSpace to the non-working version's name. I saved the non-working file and presto! It worked.
I removed those sources from Project and re-added them. Somehow, references were messed up after a hurry project refactoring.
For people having problem related to "error C1083: Cannot open source file":
Error is caused by settings in *.vcxproj file. Probably you deleted/moved source file by file explorer, not by Visual Studio's "Solution Explorer". Thus, your *.vcxproj file is corrupted. Fix is to manually correct settings in *.vcxproj file.
How Visual Studio settings files work
Visual Studio saves solution's info into file. This file is usually in project's solution directory, has extension .sln and base name is same as name of solution, f.ex.:
NameOfSolution.sln
Similarly, project's info is saved into one file (each project has its own file). Base name of this file is name of project, extension is .vcxproj, and usually is located in subdirectory named as your project, f.ex.:
NameOf1stProject/NameOf1stProject.vcxproj
NameOf2ndProject/NameOf2ndProject.vcxproj
Both *.sln and *.vcxproj files are textual files. You can open them by using Notepad.
How to fix problem
Find *.vcxproj file responsible for your project.
If you don't know where it is, open in Notepad the *.sln file of your solution. Search for name of your solution. You will find line like:
Project("{9AA9CEB8-8B4A-11D0-8D22-00B0C01AA943}") = "NameOf1stProject", "NameOf1stProject\NameOf1stProject.vcxproj", "{A8735D0A-25ED-4285-AB8F-AF578D8DB960}"
Value under "NameOf1stProject\NameOf1stProject.vcxproj" is location of *.vcxproj file of your project.
Open found *.vcxproj file by text editor (f.ex. Notepad).
Search for line on which is filename you are struggling with.
Example: if you are looking for "RemovedFile.cpp", then you should find line:
<ClCompile Include="RemovedFile.cpp" />
Delete that line.
If you have opened Visual Studio, it asks you if it should refresh solution - select yes. If it is not opened - just start using it.
In case of any problems, try to rebuild solution (top banner -> Build -> Rebuild Solution)
In my cases, it worked. 30 mins of trying to fix, <1 minute of fixing.
This helped in my case. To sum it up, my path to the project was too long, so I moved my project to something shorter i.e. D:\my_project and everything worked in a blink of an eye.
I had this same problem, but for me the issues was that I was using Bash on Windows (WSL) to clone the repository and then using VS to compile.
Once I deleted my clone and used Windows command line (cmd.exe) to clone the repo then the error 1083 went away.
This is caused by not removing/deleting the file properly. Go to Solution Explorer, select your solution, at the left corner, activate the icon: show all files.
(if you already removed the problem file, restore it from recycle bin)
Select the problem file, do remove and delete from within Solution Explorer and you should not have this problem. And remember to do it the proper way from now on.
This is on MS 2010
If you have that file in your project directory but you still got the error, on your IDE go to Solution explorer--> Remove that file-->then open the project directory on your file explorer-->Select that file and drop it on a specific location in IDE solution explorer. I fixed it this way. I use the Windows platform.
I got this error when I got a code from my peer and I tried directly running it on my system. Ideally to avoid such errors, I should have just copied the source and header files and should have created the VS solution of my own.
To resolve the errors I removed the files from the Solution Explorer and added them again. Following image shows the Solution Explorer window.
The remove option comes after right clicking on the file names.
I'm creating an automated build system for a group of projects. Most are C# and VB but we have a few VC++. I need to extract the AssemblyName properties for all of the projects before the build starts to perform some custom stuff. The C# and VB projects have an AssemblyName element inside the .csproj and .vbproj files and I can grab them using xml dom. There is no equivelant in the .vcxproj file. How do I figure out what the AssemblyName is going to be for a VC++ project by just looking at the project file (vcxproj) or the files included in the project? Does the compiler simply use whatever file contains the main entry point as the AssemblyName?
e.g. Win32ConsoleApp1.cpp -> Win32ConsoleApp1.exe?
Thanks, those elements were not in my .vcxproj. Perhaps you have an older .vcproj? Anyway it did lead me to find <TargetName/> in the Microsoft.Cpp.props file that is imported into every .vcxproj file. In there is the following line:
<TargetName Condition="'$(TargetName)' == ''">$(ProjectName)</TargetName>
This was no good for my goal of retrieving the name of the assembly that will ultimately be generated because the value $(ProjectName) is expanded during runtime. So I started tracking down were ProjectName is set. It’s in Microsoft.Common.targets and is set to $(MSBuildProjectName). Again no use to me because that too is expanded during run time. I then had to disassemble MSBuild.exe, its dependents, and finally found the Microsoft.Build.Evaluation.Evaluator class were MSBuildProjectName it is set. It’s simply the project file’s name minus the extension. E.g. MyConsoleApp1.vcxproj -> MyConsoleApp1.
I also did some experimenting and by simply right clicking my VC++ project in Visual Studio and selecting “rename” and saving the project a new element is added to the project file called <ProjectName/> with the new value I entered. So based on all of this the logic I’m going with is to parse the .vcxproj file and look for the <ProjectName/> element. If it’s in there then use it; if not simply use the project file’s name minus the extension.
This actually is in the .vcxproj file, under the headings <TargetName> and <TargetExt>. The default settings will be $(ProjectName) and .exe (for an application). The name is actually, by default, named based on the project, not a .cpp file.
However, if the user changes this (in ConfigurationProperties->General), you'll see, in the XML, something like:
<TargetName>$(ProjectName)</TargetName>
<TargetExt>.exe</TargetExt>
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
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).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.