Should I put the icons in:
[Solution folder]\[Project folder]\Resources\Icons
or:
[Solution folder]\Resources\Icons
or somewhere outside the solution folder?
Thanks
Update:
Based on the answers of Ritch Melton and x112358, I decided to put the icons in:
[Solution folder]\[MyProject.Views project folder]\Resources\Images
The easiest approach is to put them in the project folder, otherwise known as the "project cone" in MSBuild parlance, an then add them to the project from there.
Regarding the question of keeping resources (icons, configuration, etc.) under the solution folder versus under a specific project folder, I usually ask the question: Is it unique to a single project or does it apply to multiple projects? If it's shared, I'll stash it at a higher-level folder than if it's project-specific.
Related
Where should I keep my projects? There is no special folder in VS Code. Do I have to create it? Where? Maybe .vscode folder is the best option? Or this will be automatically removed after you uninstall/reinstall the editor?
You can keep them in the default location:
%USERPROFILE%\sourcerepos
Or create another folder and name it Projects (for example) in another drive.
Any folder can be your project. That’s why there’s the “Open folder” command. How to best organize your project inside that folder depends on what type of project it is.
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.
For a long time looking for a way to manage references, I haven't found any ideal way.
The main problems are:
1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?
2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?
3-) Its ok paste and reference dll´s inside bin folder of my project?
4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)
Someone can help me?
1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.
2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.
3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).
4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.
1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.
2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like:
3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.
4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.
1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)
We have a couple applications that have one solution with a number of projects contained within (for each 'piece').
2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.
(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:
<Reference Include="Elmah">
<HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>
)
This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.
(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)
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.