I began to use Visual Studio 2010. After I'm done with the C# program, I see that there are .sln, and .suo files in the project root directory, and a .csproj file in the subdirectory. What are those files for?
I need to identify the files to put into a Git repository. Together with the source code/documents that I create, I guess those three files are the only one that I have to take care of. However, I'm not sure if I'm tracking the correct files.
ADDED
How about the personal macro files? I have the Emacs key switch macro, does the .sln file or .csproj file have this macro?
You should commit the .sln and the .csproj, but not the .suo or the .user files.
You can add the following to .gitignore:
#ignore thumbnails created by windows
Thumbs.db
#Ignore files build by Visual Studio
*.obj
*.exe
*.pdb
*.user
*.aps
*.pch
*.vspscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.cache
*.ilk
*.log
[Bb]in
[Dd]ebug*/
*.lib
*.sbr
obj/
[Rr]elease*/
_ReSharper*/
[Tt]est[Rr]esult*
SLN (Solution) are the solution files. It stores info about the collection of projects that make up whatever you are developing. They contain projects, source control settings, or any other global level thing.
CSProj(Project file) are the actual code projects (C# Libraries, WCF Services, etc). It stores information at the project level. It wraps all relevant References, Classess, etc..
SUO (solution user options) are user settings files. Completely disposable, you can delete it and the most common thing you will lose are breakpoints.
Push everything except the SUO settings files.
Do not include any bin, debug, obj directory. The only DLLs (or compiled/generated object) you should include are those that are external to your application.
From MSDN:
A solution (.sln) is a structure for organizing projects in Visual Studio. It performs a function similar to Windows Program Group (.vbg) files in Visual Basic 6.0 and project workspace (.dsw) files in Visual C++ 6.0. The solution maintains the state information for projects in .sln (text-based, shared) and .suo (binary, user-specific solution options) files … [Source]
Furthermore, also from MSDN:
The solution user options (.suo) file is a structured storage, or compound, file stored in a binary format. You save user information into streams with the name of the stream being the key that will be used to identify the information in the .suo file … [Source]
You do not need to put .suo file in VCS. That is a user-specific file.
The SUO files do have a purpose and I disagree with the statement that they should always be ignored. I do not ignore them, and as a general practice I add them to our SVN repository. My projects are not always using the solution defaults for Startup Project or platform. I find it annoying that if I grab a new project it does not default to 64 bit and the proper platform. The SUO contains the settings to set these defaults properly.
The down side of this is that it's a binary file, so pretty much each time you open the solution and do anything the file will have changed. Typically the file is less than 100k, and unless you know you changed something, I don't commit the change.
In my case, I deleted all the "bin" and "obj" folder inside of my solution and projects
Related
I'm running VS Enterprise 2015. This infernal thing keeps wanting to add my solution's .vssscc file to version control. My .tfignore has this line:
*.vssscc
The other items in .tfignore are working fine, but for some reason this one is not. There are no other .tfignore files in the directory tree. Surely I'm overlooking something, but I'm pulling what's left of my hair out trying to figure out what. Any suggestions?
*.vssscc stands for Visual Studio Solution Source Control File
When a solution is added to source control, a corresponding .vssscc file is created. The text file contains connection information and an exclusion file list, similar to the project hint file. This file is temporary and exists only in the source control database.
As a rule of thumb, we'd recommend letting Visual Studio handle those files. It'll add to source control the files it needs and leave out those not needed.
.vssscc files also manage the solution bindings, so better to have them controlled (by VS) .
Also, visual studio can have problems with the source control bindings if the files it needs are not under source control.
When I press "Clean Solution" in Visual Studio 2008 for a Qt project all moc and ui header files from generatedfiles folder are cleaned.
I have one more my own generated *.h file in this folder, how to delete it too?
Where moc and ui headers file are deleted? I can't find any setting, with a option to add custom file except "Extension to Delete on Clean". But there is nothing about "generatedfiles".
And Project->Properties->Configuration Properties->General->Extensions to Delete on Clean can't be used in this case, because it ignores paths and recognize only extensions or file names.
The Visual Studio Qt Plugin is designed to put all files generated by uic, rcc and moc into a GeneratedFiles directory. Just like you stated, if you clean out the project, all of these generated files are also removed.
The files generated will be:
ui_*.h for all form files created with QtDesigner
qrc_*.cpp for all resource files created with QtResource
moc_*.h for all header files that contain Q_OBJECT
*.moc for all .cpp files that contain Q_OBJECT
The plugin is not designed to clean out any other files that you might put there yourself because it's not intelligent enough to know what your purpose with them is.
I would suggest that you put all your own header files somewhere else and delete them manually whenever you need to.
Is there any way to instruct Visual Studio 2010 to keep my .h files and .cpp files separate from the project files and databases that VS generates to manage the project? Specifically, I would like to have a set up where the project files are in the VS install folder and the source files are in a completely separate folder in my Dropbox, and monitored by git.
You can put the .cpp and .h files wherever you want. A project file just lists the locations of the source files. Create the .cpp and .h files where you want them, perhaps with Notepad, and then use "Add Existing File" to add them to the project. (Right-click on the project name in Solution Explorer and choose "Add Existing File".)
Source files are represented in the project file using relative paths, so if both the sources and the projects are on the same disk drive, the sources will be represented something like "..\..\..\..\MyFiles\work\SuperCalc\Input\parser.cpp". If they're on a different drive, then they'll use absolute paths like "D:\MyFiles\work\SuperCalc\Input\parser.cpp".
A detailed example of a source file and build file layout which uses this technique is presented in this StackOverflow response about organizing Visual C++ source files. You may find it helpful.
As an aside, if you really want to store your project files in the VS install folder, which is under C:\Program Files\Microsoft Visual Studio 10.0", then you'll need to run VS in Administrator mode, because C:\Program Files is a protected directory.
Visual Studio projects assumes all files belonging to the project are situated in the same directory as the project file, or one underneath it.
For a particular project (in the non-Visual Studio sense) this is not what I want. I want to store the MSVC-specific files in another folder, because there might be other ways to build the application as well, for example with SCons. Also all the stuff MSVC splurts out clutters the source directory.
Example:
/source
/scons
/msvc <- here is where I want my MSVC-specific stuff
I can add the files, in Explorer, to the source directory manually, and then link them in Visual Studio with the project. It's not the end of the world, but it annoys me a bit that Visual Studio tries to dictate the folder structure of my project.
I was looking through the schemas for the project files but realized that this annoying assumption is in the IDE and not the format of the project files.
Do someone know a neater way to solve this than manually linking files to the project from the source directory?
I use this sometimes, pretty sure it's what you want:
make sure the Show All Files option is on in your solution explorer.
create a symlink that targets your source directory and put the link at the same level as your project, or even lower if you want finer control. The command is mklink /j target source
For the example project structure you show, you'd run mklink /msvc/source /source and in the project the source directory will show up as if it was in the project dir (well, actually it is). Additional bonus: adding new items through VS also automatically puts them in the right directory.
You can add files with links like this, they are searchable, view-able, but they do not checkout if you try to change them, also visual studio leaves the wildcards in place:
<ItemGroup>
<Content Include="..\Database Schema\Views\*.sql">
<Link>Views\*.sql</Link>
</Content>
</ItemGroup>
This goes inside the .proj file.
I have a Visual Studio (2008) solution consisting of several projects, not all in the same namespace. When I build the solution, all the DLL files used by the top level project, TopProject, are copied into the TopProject\bin\debug folder. However, the corresponding .pdb files are only copied for some of the other projects. This is a pain, for example when using NDepend.
How does Visual Studio decide which .pdb files to copy into higher level bin\debug folders? How can I get Visual Studio to copy the others too?
References are as follows: all the DLL files are copied to a central location, without their PDB files. TopProject only has references to these copied DLL files; the DLL files themselves, however, evidently know where their PDB files are, and (most of them) get copied to the debug folder correctly.
From MSDN:
A program database (PDB) file holds
debugging and project state
information that allows incremental
linking of a Debug configuration of
your program. A PDB file is created
when you compile a C/C++ program with
/ZI or /Zi or a Visual
Basic/C#/JScript .NET program with
/debug.
So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDB files), and some are being built in release mode (hence not emitting PDB files). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.
However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.
Edit in Response to Edit
Yes, the DLL files "know" that they have PDB files, and have paths to them, but that doesn't mean too much. Copying just DLL files to a given directory, as others have mentioned, won't clear this issue up. You need the PDB files as well.
Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't know Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLL files aren't assembled in the "bundle" way, so copying them leaves their PDB file behind.
I'd say the only answer you're going to have is to update your process for getting the DLL files to those central locations, and include the PDB files ... I'd love to be proven wrong on that, though!
First off, never assume anything. Clean the solution, rebuild it in debug mode, and check to see if all PDB files are created. If not, that's your problem.
If they are created, and they're not all getting copied, you can get around this by creating a post build event that manually copies the PDB files to the desired locations. This is just a workaround, of course.
The only other thing I can think of is that your solution file has become corrupt. You can open your .sln as an XML file and examine the contents. Check the configuration for the projects that are acting as expected and compare them to those that aren't. If you don't see anything, you have to repeat this at the project level. Compare working .csproj (or whatever) project files and the non-working ones.
Edit in response to edit:
If you're just manually copying stuff around, then manually copy the PDF files as well. DLL files shouldn't "know" anything about PDB files, I believe. Just stick them in the destination directory and go have a cup of coffee. Relax.
Check when you clean the solution, that it is actually cleaned.
I've seen Visual Studio leave files hanging around in bin\debug directories even after cleaning. Delete the bin\debug directory on all of your projects and rebuild.
As other posts have said, you may have a compiler/corruption issue.
But, as Will said, if the PDB files are being created, but not showing up where you want them, create a post-build step. Here is the post-build step I define for every project in my solution. It makes sure all output files are copied into a common directory.
If your project file is in \SolutionDir\ProjDir, then the first line of the post-build step will copy the output files to \Solution\Bin\Release or \Solution\Bin\Debug. The second line copies the PDB file if this is a debug build. I don't copy the PDB file for release builds.
So, \SolutionDir\Bin now contains all your output files in one location.
xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)