Related
What is the purpose of "Linked" Files in visual studio, and when I would use them versus simply including the class project that contains the file to my current project.
Project + Add Existing Item, arrow on the Add button, select "Add as Link".
Visual Studio strongly favors copying the item you select in this dialog into your project directory. This will keep you out of trouble, like accidentally modifying a source code file or resource that's also used in another project. Or forgetting to check-in the file into source control, by far the most dangerous mishap. Something you'll discover only a year or more from now, far too late to do anything about it.
The Add as Link option overrides that behavior, the file stays in its original location and the project file records the relative path of the file.
Good reasons to use this feature are very hard to come by. Trying to come up with some:
You may want to maintain a single source code file that's included in multiple projects, using Add as Link ensures you'll only ever edit that one single source file.
You may have a project that uses the same source code files as another project but with very different build settings, in which case you'd make all of the project items a link.
You may have a humongous resource that you don't want to have copied repeatedly in multiple projects
You may have a deployable item, like an unmanaged DLL, that you keep in a single directory but is used in multiple unrelated projects.
Digging yourself a deep source control hole is a high risk, be sure to think this through before you commit to using the feature.
Linked files are for when you want the code to be included in that project assembly.
"Wow Jimmy, thanks for pointing out the obvious. But why would I want to do this?"
Well, there can be several reasons, but for now I'll just list one example. Consider the scenario that your company|team requires every assembly to have certain constants or assembly attributes defined. Instead of creating a duplicate class in every single project, you could just have one copy of the file and link it into each project. Update the file once, and every assembly gets the changes.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
Being new to VS, how may I think of these two concepts, what is the difference?
I find some missing information in the other answers (at least for people who come from other IDEs like, say, Eclipse) . To say that a solution is a container for projects is only part of the thing. The conceptual feature of a VS project (what determines its 'granularity') is that one project produces one output: typically an executable or a library (dll). So, if you are going to code three executables that uses related code, you'll create one solution and at least three projects - probably more.
A solution is a container for projects, and tracks dependencies between projects.
Just to come up with a metaphor..
A solution is like a house, a project like a room. Each room provides a piece of functionality whereas the house, a container of rooms, provides the means to link the rooms together and organize them appropriately.
Kind of corny but I made it up on the fly, so bear with me :)
It doesn't help that Visual Studio seems to make things more confusing. "New Project" actually creates a new SOLUTION containing a project. "Open Project" actually opens a solution containing one (or many) project. (The file menu says "Open Project/Solution" but it really is opening solutions. There is no "Close Project" only "Close Solution" which is accurate.
So, in VS you are always working within a solution. Many solutions contain only one project and newer developers are likely to think of them as the same thing. However you can add other projects into a solution.
In case anyone decides to scroll down this far... I thought the MS docs did a pretty good job at describing the differences. I've copy pasted (and rephrased) the relevant bits here:
When you create an app, application, website, Web App, script, plug-in, etc in Visual Studio, you start with a project. In a logical sense, a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site, or else is needed in order to perform the compilation. A project also contains all the compiler settings and other configuration files that might be needed by various services or components that your program will communicate with.
You don't have to use solutions or projects if you don't want to. You can simply open the files in Visual Studio and start editing your code.
In a literal sense, a project is an XML file (.vbproj, .csproj, .vcxproj) that defines a virtual folder hierarchy along with paths to all the items it "contains" and all the build settings.
In Visual Studio, the project file is used by Solution Explorer to display the project contents and settings. When you compile your project, the MSBuild engine consumes the project file to create the executable. You can also customize projects to product other kinds of output.
A project is contained, in a logical sense and in the file system, within a solution, which may contain one or more projects, along with build information, Visual Studio window settings, and any miscellaneous files that aren't associated with any project. In a literal sense, the solution is a text file with its own unique format; it is generally not intended to be edited by hand.
A solution has an associated .suo file that stores settings, preferences and configuration information for each user that has worked on the project.
A Solution can have many Projects.
The Solution can also handle managing the dependencies between its different Projects...making sure that each Project gets Built in the appropriate order for the final Solution to work.
A project contains executable and library files that make up an application or component of an application.
A solution is a placeholder for logically related projects that make up an application. For example, you could have separate projects for your application's GUI, database access layer, and so on. The projects would be specific divisions for your program's functionality, and the solution would be the umbrella unifying all of them under one application.
A solution is a readable text file whose extension is .sln and having a structured content that describes the projects that it contains. A project is a readable XML formatted text file whose extension is .vcxproj and having a structured content according to its XML schema, and whose primary purpose is to contain the listing of source codes filenames and their dependencies or references to other project's source codes as well.
Solutions are containers for projects - you can also use them to organize items that are used across different related project (shared dll's and such).
Solutions are containers used by Visual Studio to organize one or more related projects. When you open a solution in Visual Studio, it will automatically load all the projects it contains.
When you create a new project in Visual Studio, it automatically creates a solution to house the project if there's not a solution already open.
You can set dependencies of projects on other projects in the solution. The dependent project is build after the project it is depending on is built.
For more details refer - https://learn.microsoft.com/en-us/visualstudio/ide/quickstart-projects-solutions
If you are from an Eclipse background you would probably go to build path of a project and add a dependency on other project or add an external jar. In VS you can do that in a single container called solution where all related projects are grouped together.
Eg. Let's say you are build and android and iOS app in xamrin, there would be some common code and resources that could go in a separate project and then your android and iOS projects can depend on this common code project. Also you could have projects to test these projects etc.
Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so?
Update
There were several good points made in the answers. Thanks for the responses!
I think it's clear from the other answers that solution files are useful and should be committed, even if they're not used for official builds. They're handy to have for anyone using Visual Studio features like Go To Definition/Declaration.
By default, they don't contain absolute paths or any other machine-specific artifacts. (Unfortunately, some add-in tools don't properly maintain this property, for instance, AMD CodeAnalyst.) If you're careful to use relative paths in your project files (both C++ and C#), they'll be machine-independent too.
Probably the more useful question is: what files should you exclude? Here's the content of my .gitignore file for my VS 2008 projects:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(The last entry is just for the AMD CodeAnalyst profiler.)
For VS 2010, you should also exclude the following:
ipch/
*.sdf
*.opensdf
Yes -- I think it's always appropriate. User specific settings are in other files.
Yes you should do this. A solution file contains only information about the overall structure of your solution. The information is global to the solution and is likely common to all developers in your project.
It doesn't contain any user specific settings.
You should definitely have it. Beside the reasons other people mentioned, it's needed to make one step build of the whole projects possible.
I generally agree that solution files should be checked in, however, at the company I work for we have done something different. We have a fairly large repository and developers work on different parts of the system from time to time. To support the way we work we would either have one big solution file or several smaller. Both of these have a few shortcomings and require manual work on the developers part. To avoid this, we have made a plug-in that handles all that.
The plug-in let each developer check out a subset of the source tree to work on simply by selecting the relevant projects from the repository. The plugin then generates a solution file and modifies project files on the fly for the given solution. It also handles references. In other words, all the developer has to do is to select the appropriate projects and then the necessary files are generated/modified. This also allows us to customize various other settings to ensure company standards.
Additionally we use the plug-in to support various check-in policies, which generally prevents users from submitting faulty/non-compliant code to the repository.
Yes, things you should commit are:
solution (*.sln),
project files,
all source files,
app config files
build scripts
Things you should not commit are:
solution user options (.suo) files,
build generated files (e.g. using a build script) [Edit:] - only if all necessary build scripts and tools are available under version control (to ensure builds are authentic in cvs history)
Regarding other automatically generated files, there is a separate thread.
Yes, it should be part of the source control.
When ever you add/remove projects from your application, .sln would get updated and it would be good to have it under source control. It would allow you to pull out your application code 2 versions back and directly do a build (if at all required).
Yes, you always want to include the .sln file, it includes the links to all the projects that are in the solution.
Under most circumstances, it's a good idea to commit .sln files to source control.
If your .sln files are generated by another tool (such as CMake) then it's probably inappropriate to put them into source control.
We do because it keeps everything in sync. All the necessary projects are located together, and no one has to worry about missing one. Our build server (Ant Hill Pro) also uses the sln to figure which projects to build for a release.
We usually put all of our solutions files in a solutions directory. This way we separate the solution from the code a little bit, and it's easier to pick out the project I need to work on.
The only case where you would even considder not storing it in source control would be if you had a large solution with many projects which was in source control, and you wanted to create a small solution with some of the projects from the main solution for some private transient requirement.
Yes - Everything used to generate your product should be in source control.
We keep or solution files in TFS Version Control. But since or main solution is really large, most developers have a personal solution containing only what they need. The main solution file is mostly used by the build server.
.slns are the only thing we haven't had problems with in tfs!
Visual Studio solutions contain two types of hidden user files. One is the solution .suo file which is a binary file. The other is the project .user file which is a text file. Exactly what data do these files contain?
I've also been wondering whether I should add these files to source control (Subversion in my case). If I don't add these files and another developer checks out the solution, will Visual Studio automatically create new user files?
These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'.
I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.
You don't need to add these -- they contain per-user settings, and other developers won't want your copy.
Others have explained why having the *.suo and *.user files under source control is not a good idea.
I'd like to suggest that you add these patterns to the svn:ignore property for 2 reasons:
So other developers won't wind up
with one developer's settings.
So when you view status, or commit
files, those files won't clutter the code base and obscure new files you need to add.
We don't commit the binary file (*.suo), but we commit the .user file. The .user file contains for example the start options for debugging the project. You can find the start options in the properties of the project in the tab "Debug". We used NUnit in some projects and configured the nunit-gui.exe as the start option for the project. Without the .user file, each team member would have to configure it separately.
Hope this helps.
Since I found this question/answer through Google in 2011, I thought I'd take a second and add the link for the *.SDF files created by Visual Studio 2010 to the list of files that probably should not be added to version control (the IDE will re-create them). Since I wasn't sure that a *.sdf file may have a legitimate use elsewhere, I only ignored the specific [projectname].sdf file from SVN.
Why does the Visual Studio conversion wizard 2010 create a massive SDF database file?
No, you should not add them to source control since - as you said - they're user specific.
SUO (Solution User Options): Records
all of the options that you might
associate with your solution so that
each time you open it, it includes
customizations that you
have made.
The .user file contains the user options for the project (while SUO is for the solution) and extends the project file name (e.g. anything.csproj.user contains user settings for the anything.csproj project).
This appears to be Microsoft's opinion on the matter:
Adding (and editing) .suo files to source control
I don't know why your project stores the DebuggingWorkingDirectory in
the suo file. If that is a user specific setting you should consider
storing that in the *.proj.user filename. If that setting is shareable
between all users working on the project you should consider storing
it in the project file itself.
Don't even think of adding the suo file to source control! The SUO
(soluton user options) file is meant to contain user-specific
settings, and should not be shared amongst users working on the same
solution. If you'd be adding the suo file in the scc database I don't
know what other things in the IDE you'd break, but from source control
point of view you will break web projects scc integration, the Lan vs
Internet plugin used by different users for VSS access, and you could
even cause the scc to break completely (VSS database path stored in
suo file that may be valid for you may not be valid for another user).
Alin Constantin (MSFT)
By default Microsoft's Visual SourceSafe does not include these files in the source control because they are user-specific settings files. I would follow that model if you're using SVN as source control.
Visual Studio will automatically create them. I don't recommend putting them in source control. There have been numerous times where a local developer's SOU file was causing VS to behave erratically on that developers box. Deleting the file and then letting VS recreate it always fixed the issues.
No.
I just wanted a real short answer, and there wasn't any.
On the MSDN website, it clearly states that
The solution user options (.suo) file contains per-user solution
options. This file should not be checked in to source code control.
So I'd say it is pretty safe to ignore these files while checking in stuff to your source control.
I wouldn't. Anything that could change per "user" is usually not good in source control. .suo, .user, obj/bin directories
These files are user-specific options, which should be independent of the solution itself. Visual Studio will create new ones as necessary, so they do not need to be checked in to source control. Indeed, it would probably be better not to as this allows individual developers to customize their environment as they see fit.
You cannot source-control the .user files, because that's user specific. It contains the name of remote machine and other user-dependent things. It's a vcproj related file.
The .suo file is a sln related file and it contains the "solution user options" (startup project(s), windows position (what's docked and where, what's floating), etc.)
It's a binary file, and I don't know if it contains something "user related".
In our company we do not take those files under source control.
They contain the specific settings about the project that are typically assigned to a single developer (like, for example, the starting project and starting page to start when you debug your application).
So it's better not adding them to version control, leaving VS recreate them so that each developer can have the specific settings they want.
.user is the user settings, and I think .suo is the solution user options. You don't want these files under source control; they will be re-created for each user.
Others have explained that no, you don't want this in version control. You should configure your version control system to ignore the file (e.g. via a .gitignore file).
To really understand why, it helps to see what's actually in this file. I wrote a command line tool that lets you see the .suo file's contents.
Install it on your machine via:
dotnet tool install -g suo
It has two sub-commands, keys and view.
suo keys <path-to-suo-file>
This will dump out the key for each value in the file. For example (abridged):
nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...
As you can see, lots of IDE features use this file to store their state.
Use the view command to see a given key's value. For example:
$ suo view nuget --format=utf8 .suo
nuget
?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}
More information on the tool here: https://github.com/drewnoakes/suo
Using Rational ClearCase the answer is no. Only the .sln & .*proj should be registered in source code control.
I can't answer for other vendors. If I recall correctly, these files are "user" specific options, your environment.
Don't add any of those files into version control. These files are auto generated with work station specific information, if checked-in to version control that will cause trouble in other work stations.
No, they shouldn't be committed to source control as they are developer/machine-specific local settings.
GitHub maintain a list of suggested file types for Visual Studio users to ignore at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
For svn, I have the following global-ignore property set:
*.DotSettings.User
*.onetoc2
*.suo .vs PrecompiledWeb thumbs.db obj bin debug
*.user *.vshost.*
*.tss
*.dbml.layout
As explained in other answers, both .suo and .user shouldn't be added to source control, since they are user/machine-specific (BTW .suo for newest versions of VS was moved into dedicated temporary directory .vs, which should be kept out of source control completely).
However if your application requires some setup of environment for debugging in VS (such settings are usually kept in .user file), it may be handy to prepare a sample file (naming it like .user.SAMPLE) and add it to source control for references.
Instead of hard-coded absolute path in such file, it makes sense to use relative ones or rely on environment variables, so the sample may be generic enough to be easily re-usable by others.
If you set your executable dir dependencies in ProjectProperties>Debugging>Environment, the paths are stored in '.user' files.
Suppose I set this string in above-mentioned field: "PATH=C:\xyz\bin"
This is how it will get stored in '.user' file:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
This helped us a lot while working in OpenCV. We could use different versions of OpenCV for different projects. Another advantage is, it was very easy to set up our projects on a new machine. We just had to copy corresponding dependency dirs. So for some projects, I prefer to add the '.user' to source control.
Even though, it is entirely dependent on projects. You can take a call based on your needs.