After exporting a project template and using it to set up a new project/solution (very simple C++ program with a few source files), I can close the solution, re-open it and all the properties I've set (ignoring certain warnings, selecting the CONSOLE subsystem) are intact.
However, if I manually copy the entire solution folder to a different location and then open the solution in the new location, those properties have disappeared.
Any idea how to copy a solution folder and have the custom properties I've set remain intact?
Related
I have made a test program in Visual Studio 2013 using Direct X 11. It consists of a simple sprite which rotates slowly based on a timer implementation. The program loads and runs fine using F5 or Ctrl-F5, but when I try to open the actual created .exe (in my \Debug folder) it just shows the window then closes instantly.
Most of the answers I have read on this issue correspond to loading the .exe from inside visual studio. I have also tried Release mode but the same thing happens.
Sprite files are kept in your project folder. The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the debug folder, it is highly likely you are relying on project data files that are kept along side your source files in the project folder. When run from the Debug folder, those files are no longer visible because Debug folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I have been following some tutorials for c++ game programing. I am kind of new to c++ and I'm using Microsoft Visual C++ 2010 Express IDE. I'm working on creating a game, and when I run the program through the IDE, it shows the grass sprites as expected. But when I run the .exe file from the Release folder, it shows weird images. and when I run the .exe file from the debug folder I get a grey screen. Can anybody tell me why this is happening?
I hazard to guess that your sprite images are kept as data files in your project folder. With that I offer the following premise:
The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the release folder, it is highly likely you are relying on project data files (images in your case) that are kept along side your source files in the project folder. When run from the Release folder, those files are no longer visible because your the Release folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I use VS2008 and try to answer your question. Right click on the project and select properties on the bottom of popup, then go to Debugging under Configuration properties. You can see command you run and arguments you pass in IDE. I guess you miss some parameters.
I made some changes to the Property Pages/Configuration Properties a long time ago and I'd like to reset them. I changed stuff like the output directory, code generation settings, etc.
I've tried resetting all environment settings from the Import and Export Settings Wizard. I've also tried the devenv /resetsettings command. Both of which did not work. Reinstalling doesn't work either. May I get some advice on how to restore everything back to the default.
Thank you.
If I understand you correctly, you are trying to revert to old settings for the Project -> Properties.
This information is stored in the project itself, not in Visual Studio. Look for a file with the extension vcxproj in the solution folder.
You can edit it with Notepad (notepad++), or - you can edit it inside Visual Studio, by
right-click the project, unload it, then edit project file, then reload project
Be careful how you edit these settings.
For best results, create a new solution, with a new project, and compare the settings from the newly created project with the existing one.
edit: on my computer (I have VS Ultimate I think, but it shouldn't matter):
To edit, go to Project -> Properties -> VC++ Directories, and on each, at the end of the line, press the arrow down, and click Edit...
VC++ directories:
$(VCInstallDir)bin
$(WindowsSdkDir)bin\NETFX 4.0 Tools
$(WindowsSdkDir)bin
$(VSInstallDir)Common7\Tools\bin
$(VSInstallDir)Common7\tools
Include Directories:
$(VCInstallDir)include
$(VCInstallDir)atlmfc\include
$(WindowsSdkDir)include
$(FrameworkSDKDir)\include
from what I see in the directions you pointed out, all you have to do is remove from your list, the directories that you no longer want.
In c/c++ -> Code Generation ->
enable minimal rebuild: NO
enable c++ exceptions: YES (/EHSC)
Basic Runtime Checks - Both
/MTd
...
General -> Output directory:
not sure what is the default, I would put something like
$(SolutionDir)bin\$(Platform)\$(Configuration)\
Also, there seems to be a property sheet that may have been added to your project...
You can generally see the Property Manager from View -> Properties Window (F4).
here, you can expand the project configurations, and simply delete any property sheets you may not want (I expect a new project to have no property sheets).
I'm reorganizing my project in visual studio. I have some .cpp/.h files which I want to move into a subdirectory physically. A would like to have the following acts simultaneously:
File moving on file system
SVN working copy database updating (with keeping history)
Visual Studio project file(s) updating
Extra benefits would be nice, like:
Updating of #include directives referring to the file.
Are there any solutions? Best workarounds?
This is the proverbial chicken-and-egg dilemma for software developers:
Do you move/rename your files in Visual Studio first then go back to Windows Explorer and correct all the adds/deletes that should really be renames/moves?
Or do you rename/move your files in Windows Explorer then go clean up all the introduced compilation errors in Visual Studio?
You already have the solution at hand! Without AnkhSVN if you do your file operations in Visual Studio you already get two of your requirements: updating your VS project and file system synchronization. With AnkhSVN installed, though, you also get your 3rd requirement: it makes the necessary SVN synchronizations as well. All you have left to do is a commit.
I found the following description from a cached page in a Google search:
In Windows Explorer, right-click and drag the file from its old
location to its new location, then select "SVN move versioned item"
from the context menu. This will not only move the actual file itself,
but it will also make sure that all the file history stays with it
after you check in your changes. Back in Visual Studio, use the
Solution Explorer in VS2010 to "exclude from project" the
(now-missing) copy of the file in its old location, and then "include
in project" the file in its new location. You may need to refresh the
view in solution explorer and/or make sure you are viewing all the
files by clicking the "Show all Files" icon at the top (next to the
refresh icon) in order to see these files.
After you update the namespace to reflect the new location, I
recommend using a global find and replace before you try to compile to
save yourself a lot of trouble.
Hope this helps.
I have just taken over the maintenance of a project. It is a VS2010 solution which in amongst its projects includes a C++ project. The whole solution is kept in TFS 2010 as a source control system.
Now whenever I open the solution VS2010 presents me with this annoying dialog;
Visual C++ found a suitable location to store its browsing database and IntelliSense files
for the solution
"C:\***\****x.sln."
Visual C++ examined the folder "C:\***\A***LL."
This folder is not suitable because of the following:
The browsing database in this directory has the read-only attribute and cannot be written to.
The directory is on a local drive.
Because a 'Fallback Location' was not specified in the C++ Advanced Options, Visual C++ is
attempting to use your temporary directory.
Visual C++ examined the folder "C:\Users\***\AppData\Local\Temp\VC++\c****-57e7d5e2." This folder is suitable because of the following:
The directory is on a local drive.
The 'Fallback Location' is configurable under C++ Advanced Options.
Press OK to use this location.
It looks like this is caused by the C++ solutions *.SDF file being under source control, meaning when the solution is opened (despite being under source control) its read only hence the read only bit of the dialog.
So my question is whats the best practice for a C++ project under TFS source control?
Should I remove the .sdf file from source control, leaving VS to recreate this everytime somone gets the solution?
Should I tick the use fallback option efectivly bypassing the .SDF in the repository
or
Is there a better way that lets VS2010 know the SDF file is under source control so it can automatically check it out when it opens the project?
I can only recommend to exclude the sdf from source control. You have no benefit from versioning it, since it's generated every time something changes, which will be almost everytime. As an mantra one could say, that you should never versioning binary files unless it's absolutely necessary to share them (eg. icons and images that are needed).
My issue was with an Unreal Engine 4 solution. The issue was that I had moved the project's intermediate folder (which included build files), and then it was re-generated (without build files) the next time the editor was opened. The fix was to delete the new intermediate folder and re-migrate the old folder to the project directory.
If you had already deleted the intermediate folder and don't have a backup, the fix is most likely to rmb the .uproject>generate visual studio project files.