Some time ago I wrote a point cloud drop sampling code, directly call someone else's library "Library111" and property sheet.However, since the property sheet was not working well, the library was deleted and a new library named "Library_original" was copied.
During this period of time, the code of point cloud drop sampling was suddenly needed, so I changed the property sheet contained in the project to the property sheet in "Library_original", but I was warned that a file in the library "Library111" could not be found. I checked the included directory and library directory in the property sheet, and the path has been updated
According to the error message, you should check if the path is right.
If the file from D:\Library111\pcldebug_vs2017.props exists and there is no spelling errors under the path.
You should use this under the vcxproj file:
<Import Project="D:\Library111\pcldebug_vs2017.props"/>
After that, close VS, restart your project to test again.
The right way use to
<Import Project="D:\Library_original\pcldebug_vs2017.props"/>
Related
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.
I have download a software maintained by Carnegie Mellon:
https://github.com/festvox/flite
There is a sln, and in this solution, there's a vcxproj contained.
This project file states the following path for a ".c" file:
<ClCompile Include="..\..\lang\cmu_grapheme_lang\cmu_grapheme_lang.c" />
However, the actual folder structure on disk looks like this:
In my opinion, the location should be stated like this in the vcproj file instead:
<ClCompile Include="lang\cmu_grapheme_lang\cmu_grapheme_lang.c" />
I also think so because when I double-click the file in VS2017, it tells me that a part of the path couldn't be found:
I think a project which is so actively maintained would have this set up correctly, so I wonder if there's any option in VS2017 that I might perhaps just not have set right.
Thank you for any clarification on this problem.
You are correct - that file reference looks wrong. My best guess is that the developer indeed has that lang\cmu_grapheme_lang directory in the specified location and just neglected to make sure that the project on GitHub has valid settings (one of those "hey, this builds on my system so it must be correct" fiascos).
In your particular case: to properly build either fix the project file or copy the lang\cmu_grapheme_lang directory into expected location.
So, I have a project in VS2017, and VS2017 has recently received an update. I have then added all the wxWidgets modules as projects to my initial solution and have dealt with build order so they're built in the proper order.
However, I always get this error:
C:\Programs\Visual Studio 2017\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Common.props(144,5): warning
MSB4211: The property "WindowsTargetPlatformVersion" is being set to a value for the first time, but it was already consumed at
"C:\Programs\Visual Studio 2017\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.props (29,5)".
I've found this thread and the article linked in it: link
but it doesn't tell me how to fix it. From what I can tell, the properties for individual project are not evaluated in an order they should be evaluated.
How do I define the property sheet ordering? What exactly do I need to change?
Also not that I cannot change the project files or anything connected to wxWidgets since it's a submodule in my repository and any changes done cannot be saved to the repo.
Disclaimer: I haven't got a clue about your issue ,just trying to help you (the OP) !
In the IDE ,under menu View ,select other windows.
There select Property Manager ,which let you manipulate property sheets in your projects.
Right-click on a property-sheet. Some sheets have a menu which let you move the sheet up or down.
I suggest to play around with that. It might just solve your issue.
I could be completely wrong of course.
I had the same problem, with a different library though.
The cause for me was that in the project that I converted, the configuration that I was compiling with was not present in the props file
C:\Users\\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
For example, in the vcxproj file I had
<ProjectConfiguration Include="DLL Release|x64">
<Configuration>DLL Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
but in the props file I only had:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile>
<PreprocessorDefinitions>MYMACRO1;MYMACRO2;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
</ItemDefinitionGroup>
I just added a similar entry for 'DLL Release|x64' and that fixed it.
Definitely the warning message is not very helpful in this case.
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.
I will be creating a series of projects set up to build COM objects. I attempting to create a property sheet (.vsprops file) which will set up the builds for each project. One of the things I am doing with the properties file is customizing the location and names of the files created by the MIDL compiler. Here's the code I use for this:
<Tool
Name="VCMIDLTool"
TypeLibraryName="$(InputName).tlb"
OutputDirectory="$(RPCDIR)"
HeaderFileName="$(InputName).h"
DLLDataFileName="$(InputName)_dlldata.c"
InterfaceIdentifierFileName="$(InputName)_i.c"
ProxyFileName="$(InputName)_p.c"
/>
RPCDIR is a macro defined before this section of the property file. This works great for compiling the code. When I build my project, these five files are created with the correct names in the location I specified in the RPCDIR macro. My problem is when I try to clean the build. The clean successfully deletes four of the files, but the DLL Data File does not get deleted. I'm especially confused that some are deleted and one is not - I would have thought that either they would all be deleted or none be deleted rather than a split like this.
Does anyone know how I can customize the clean build to correctly delete these files? Optimally any changes I need to make would be in the property sheet so that I can share it with other projects, but if that's not possible then I'd like to at least be able to do it in the project file. Thanks in advance for any help you can offer!
Not your problem, it is a bug in the build system. The dlldata.c file doesn't get deleted using a regular build either. There aren't enough diagnostics available in the msbuild .log files to see what target fumbles this. I'm guessing it has something to do with the <FilePatternsToDelete> item in the Microsoft.CppClean.targets file.
I recommend you report this problem at connect.microsoft.com