I'm using the new Visual Studio 2017. I follow this tutorial to change the default (temp) path where store .db and such.
It correctly moves *.VC.db files, but I can still see these files into the .vs within the solution's folder:
Solution.VC.db
Solution.VC.db-shm
Solution.VC.db-wal
I'd like to also move these data. How can I do it?
The guide that is the source of all these tutorials and advices is https://blogs.msdn.microsoft.com/vcblog/2010/03/09/intellisensebrowsing-options-in-vc-2010/
You are trying to get rid from you *.db files in {ProjectDir}/.vs/{SolutionName}/v15{(VS version)}/ and following the old guide for ipch files
you successfully moved Browse.VC.db fie. However
Solution.VC.db
Solution.VC.db-shm
Solution.VC.db-wal
Are not browsing files and have nothing to with Intellisense. They are
Project Preload files and needed only to speed up VS hefty loading of solutions.
The answer to your question: No, you can not move them to the other folder by the means of VS options. They are supposed to be internal matter of VS speeding up the openage.
2 of this 3 files should disappear when you close the solution( the heaviest one will remain)
However there is a lot you can do about it:
1)You can turn them off completely by Tools->Options->Text Editor->C/C++->Experimental in Enable Faster Project Load = False
2) If you'd like to leave project load(I don't feel much difference, but maybe I don't have very big projects) you can always clean files ad hoc by Project->Properties->Build Event->Post Build and entering any console command you'd like removing files from that folder- that will happen each build, which is what you want in the end when you close it.
3) You can hack their size to zero by using symlinks - just create symlink with the same name(by a script, maybe) that to points to the location you like and VS won't spot the difference.
Also, you can turn off browsing db in the Advanced - it will turn off Intellisense (or leave where you moved it).
I hope it helps to solve this issue with heavy untransportable files.
Two things
how to control or manage the path where .vs folder is created?
Currently I couldn't find a way for this - its still created next to solution folder (I am using VS 2019)
how to control or manage the path where the contents (like Browse.VC.db and including the other temp ones like Browse.VC.db-shm, Browse.VC.db-wal & Browse.VC.opendb) are created?
Solution: Use Fallback Location
Visual Studio > Tools > Options > Text Editor > C/C++ > Advanced > Browsing Database Fallback > "Always Use Fallback Location" as true and provide a valid path to "Fallback Location".
After this, I have to restart VS.
This is especially useful when you are using cloud or web drive for your solutions and / or projects and don't want these temp files to clutter and consume more spaces.
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'm using Xcode (with C++) and my project layout (in the file system, not in Xcode) looks like this:
SubfolderA
-file_A_1, file_A_2
SubfolderB
-file_B_1, file_B_2
Right now I've set up this structure in Xcode via groups. And so, when I want to include file_A_2 in file_B_1, I write #include "file_A_2" in file_B_1.
Is there some way to make an inclusion look like #include "/SubfolderA/file_A_2", so that I can easily see to what directory/subfolder an included file belongs?
One way to see what's going on is to look at the Build Log and expand the line for compiling sourcefile.m. Look at the -I options being passed to the compiler.
If it's not to your liking you can add the source tree in the Build Settings > Header Search Paths to include $(ProjectDir)/srcroot and make it recursive, which saves you from adding each sub-folder individually.
In my experience this has never been necessary, however, as far as I can remember.
As far as the Xcode folders are concerned, if the top-level source folder is added then all sub-folders are automatically added when you add them to the filesystem, saving the hassle of keeping them in sync. You might need to add the top-level folder under the Source Files group for this to work, however.
Surprisingly, in Xcode's Build Settings I've added to User Header Search Paths non-recursive path to my project. This solved my problem.
I ended up here when I was having an issue with XCode while trying to include a header in a group by doing
#include "MyGroup/MyHeader.h"
Turns out the project structure and the file system weren't in sync, so I just had to remove my group from the project, put it in the correct place in Finder, then drag and drop it back into the project in the correct place and it worked for me.
I'm not sure if this is necessary or not, but I also have already set up my app's working directory because I am doing some game programming and need to be able to load in .png and make textures.
When installing OpenCart extensions, you´re generally given a bunch of folders that should be copied to the root directory and the extension files will find their way to the right subfolders. This works great in FTP software, but on a local installation (Mac OSX) using Finder, this operation makes Finder want to overwrite the folders completely, deleting the actual site and just keep the extension.
I can hold Alt when dragging the folders and it will give me the option to not overwrite, the problem is I have hidden files visible, which means there's now a .DS_STORE file in each folder and the ”Hold ALT”-approach doesn’t work in case there are ANY duplicate files in any of the folders.
I’m sure someone out there has stumbled upon the same problem, any ideas for how to solve such a simple but annoying problem? I do not wish to use FTP software for local file management.
I have the same problem, and i found 3 different ways to solve this:
a - use another file manager, i personally use "Transmit" to do this sort of things;
b - use terminal, like: ditto <source> <destination>. Or easier way just type ditto, and drag the source folder, then drag the destination folder, all inside source will merge inside destination;
c - unzip the plugin, inside the OC folder using the terminal, like: tar -zxvf plugin.zip;
I'm trying to set my project include to the path %OPENCV_246%\..\..\include
This resolves to the path F:\dev\opencv_246\build\include
However, when setting the project includes, that path will not resolve and as a result the included headers break.
I've tried both %OPENCV_246%\..\..\include and $(OPENCV_246)\..\..\include with no luck.
Using the path directly fixes my includes, but I'd like to have a better way of managing the path through environment variables.
In the screenshot I've added both for clarity, If anyone could point out the step I'm missing here I'd appreciate it.
EDIT: Variable OPENCV_246 contains value F:\dev\opencv_246\build\x86\vc11
Dev studio won't recognize any environment variables that have been changed since it was started, so if you change one, a restart is required (of Dev studio, not the computer).
https://superuser.com/questions/107521/why-are-changes-to-my-path-not-being-recognised
This sounded similar to my problem, which was getting VS2013 to acknowledge a change I made to my environment variable (in my case QTDIR). Even after a restart and a shutdown, it obstinately hung on to the old value !! (you can see the value if you go to edit a project setting, hit the "Macros" button, and scroll down the list to find e.g. "$(QTDIR)" )
Here it suggest VS2010 cahed values heavily, but 2013 seems even more keen !
After some FindInFiles for the old path, it seems that VS2013 caches environment variables in your .vcxproj.user file. I have no idea how it got in there in the first place.
So I deleted the entry, closed the solution, checked the file again in WordPad to make sure the entry hadn't been put back in. Then I re-opened the solution, but the old value was still there in the Macros list !
Closing VS seems to have done the trick. Now it seems to have the right path - although I'm sure I checked after I first opened the solution and QTDIR wasn't in the Macros list at all - maybe I'm confused...
Well, it all seems to be working now, and my project builds and links to my Qt libs without complaints :-)
And, the entry in the vcxproj.user file hasn't come back. So I still don't know how it got in there. Maybe I did something to cause it a while back in a previous version of VS...
I recently started working with WxWidgets (2.9.4) and was working through a tutorial I found, but it seems that I'm unable to load any images. I've already properly used the handler (for PNG) and the problem happens at run-time. Below is an image of the popup that is displayed when attempting to run the program.
Here is the code:
wxPNGHandler *handler = new wxPNGHandler;
wxImage::AddHandler(handler);
wxBitmap exit;
exit.LoadFile(wxT("exit.png"), wxBITMAP_TYPE_PNG);
wxToolBar *toolbar = CreateToolBar();
toolbar->AddTool(wxID_EXIT, exit, wxT("Exit"));
toolbar->Realize();
Connect(wxID_EXIT, wxEVT_COMMAND_TOOL_CLICKED, wxCommandEventHandler(mainWindow::exitProg));
Any help is appreciated.
EDIT: I forgot to mention that when I click Cancel, this happens:
I placed the exit.png file in the build directory (/Debug or /Release) as well as the source code directory, but it still has yet to see it.
What is your working directory?
If you are using visual studio and running using the interface ( F5 or ctrl-F5 or the little run button in the toolbar ) then your working directory is the folder containing the project file. So try copying your image file there.
Or open a command window, cd to one of your build directories, and run your app from the command line.
In general, to avoid this sort of problem, I alter the project properties so that the executable is NOT stored in one of the build folders, but in a new folder ( which I usually call 'bin' - my unix roots are showing! ) and also alter the debugging properties so that the working directory is the bin folder.
There are a couple of advantages to this technique:
Both the release and trhe debug version use the same folder, so you only need one copy of any extra file, like your image file.
It is easy to see the executable and extra files in the working directory without being distracted by all the .obj files that end up in the build folders
IMHO this is well worth the little extra trouble in maintaining non default project properties.
First of all, to avoid problems deep inside wxToolBar, always check the return code of LoadFile() or, alternatively, use wxBitmap::IsOk() to check that the bitmap was successfully loaded.
Second, while adding the handler explicitly as you did is perfectly fine, I'd recommend to just call wxInitAllImageHandlers() as it's simpler and has no real drawbacks unless you are looking to create the smallest program possible.
Finally, to address your real problem, the file clearly doesn't exist at the path you're loading it from. You can, of course, solve this by being careful not to change your working directly (or restore it after changing it) in your program and by placing the file in the correct place. But this is, as you discovered, error-prone, so a better idea is to always use full paths to your resources. To construct them, you will find wxStandardPaths useful, in particular its GetResourcesDir() method.