I've got a collection of HTML documentation that I'd like to add to my solution in Visual Studio. It's just a collection of files -- there are no build steps.
What's the best way to add this to my solution? In the past I've used a C# class library project and disabled it in Build Configuration, but this felt wrong.
A "Makefile project" doesn't work, because it doesn't support nested folders.
I don't really want to use Solution Folders, because they're not real filesystem folders. This makes them harder to work with. Solution Folders are great when your solution has a large number of projects in it, but I don't think they're great for managing more than a couple of loose files.
How do others do this?
You can put them in solution folder
Right click on solution and select Add->Add existing item - it will create solution folder automatically. You can add solution folder manually via Add->New solution folder
I would recommend simply adding them directly under the solution (or rather under a Documentation folder under the solution). The context menu for the solution title in Solution Explorer gives options to create solution folders and add references to solution files.
Given that you don't want to use solution folders, I see absolutely no point of including them in your solution then. Any method you could use would be rather contrived. It is quite common simply to have a Documentation folder in the root directory of your solution that is not referenced in any way by the solution/project files. (If you like, you can then mirror the directory structure of Documentation using Solution Files.)
I always put a .Documentation folder in each project that I am making the documentation for. It's not as elegant as having a single location for the solution, but it also makes it so that as I use different projects in different solutions and have the documents follow their projects. At compile time I have the build system put all the documentation together in one folder.
Related
I have seen most of the time how developers in order to work on a solution, right click on solution folder in source control, select "Get Latest" and... have tons of problems: solution's projects reference other projects from other solutions, missing references, etc...
Here is the simulated example of something similar we have at work...
Now, imagine you have to work on TicketsSolution, specifically - fix some bugs, make changes with TicketsSolution's Web project. Usually developers right click on TicketsSolution's folder in TFS/VSS (whatever) and select "Get Latest"... and the above mentioned problems hit them right in the face.
Turns out, TicketsSolution also includes such projects as
Common.Solution1.Project1, which may have a reference to Common.Solution2.Project1
Common.Solution1.Project2
WCFServicesLibrary project, which may have a reference to SQLServerProxy project
also, some external 3rd patry DLLs that have been missing or placed somewhere under ROOT but outside the TicketsSolution folder...
In this scenario when you Get Latest for just TicketsSolution folder all those references will be missing,
so it seems the only reasonable way to Get Latest would be right-clicking on JUST the solution file, such as TicketsSolution.sln and getting latest of that file only. Then, opening that TicketsSolution.sln file in Visual Studio would hopefully :) reconstruct all the tree nodes within and beyond the solution folder required by the solution.
Even in this approach references for external DLL libabries will be missed, because VS knows how to reconstruct the folder-tree, but it doesn't include DLLs referenced outside of TicketsSolution folder.
But 90% of developers get latest of the solution folder and having tons of problems.
So, my question is - in this scenario, whould it be correct to include external projects in TicketsSolution solution, or it would be more reasonable to add "lib" folder under TicketsSolution folder and drop the dlls of all those external dependent projects in it, and then, reference them from the solution's projects, instead of reconstruction the entire folder tree with all the dependent projects from upper levels (that may and probably will have their own dependencies and reference problems) ??
Lib folder makes life simpler but introduces other issues in you build hierarchy.
Plus you have to store your libraries in source control which to some people is a no no.
I use a local NuGet feed.
I think the simplest answer to your question though, is to create a .bat file, write the check out calls for the folder s you need to check out for a solution, store in the solution root folder on TFS.
Get the devs to click the bat file to get latest on all of the files for the solution.
The project I'm currently working on uses Nant build scripts for the continuous integration server builds. The build file is stored in a folder in the repository.
I find it annoying having to browse to it via windows explorer rather than it being available from the visual studio solution when I need to make changes.
I was wondering if there is any reason not to include it somewhere in the solution for ease of access? If this isn't daft where would you store it in the solution? Would you create a dummy non building project for holding these type of resources?
Thanks,
Neil
Go right ahead and add it to your solution file.
You will either get, or have to create manually, a folder for it, but I think that when you add it you will get a folder called Solution Items.
As far as I have seen, there is no real reason to not have them along with your project solution. In one project, since there were lots of build files, it made sense to create a separate solution for them.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
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!
In an earlier question, I've found out that sadly Solution Folders are not real folders inside a directory.
I wonder if there is an AddOn or Macro that adds this functionality? i.e. when I create a Solution Folder, it created a real folder. When I Create a new Item (Right Click => Add => New Item) it automatically moves them into that folder, removing causes it to delete it from disk (after asking) etc.
This is for Visual Studio 2005, although we might upgrade to 2008 in a few months.
As of now, this doesn't seem to be possible in either VS 2005, 2008 and 2010 and there is no AddIn for this.
I too thought it was a strange idea. However it can be a useful tool to logically group projects in solutions without necessarily moving around folders in the file system.
I suspect you need this for revision control tool. In that case Look at AnkhSVN.
Maybe what you want is to add files to a solution folder as «links», i.e., keeping the files where they are but giving them a different organization inside the solution.
(when you add an existing file to a solution folder or to a normal project folder, if it is in a different corresponding physical folder, the file is copied).
It usually stays unnoticed, an option in the «Add > Existing Item ...» dialog where you can choose "Add As Link", instead of the "Add".
This allows to share files amongst projects, or, simply, organize them differently.
What I oftem miss is the possibility to add "virtual" folders inside a project, for organizational purposes, without breaking the namespace/folder best-practice.
Can't really get the point you want to add this function.
Sometimes you want to know if it can do this , however, the answer may be no. But it is not necessary means you can't achieve your original goal, there still a few ways to work around it without this.
Additionally, VS solution suppose to be the shortcut of your project settings and should not been included in any hard-code, the solutions may be various between the PCs and IDE envrionment.
I didn't really use VS2005 much, but have been using VS2008 for the past year.
It has a tick box for creating a solution folder when you create a new solution/project.
If you then use the "Solution Explorer" window you can create and manipulate folders and class files within them. This will actually create new directories that match.
Deletion of files from within the Solution Explorer will also delete the actual files from disk.