Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
.NET project structure
$/
  artifacts/
  build/
  docs/
  lib/
  packages/
  samples/
  src/
  tests/
  .editorconfig
  .gitignore
  .gitattributes
  build.cmd
  build.sh
  LICENSE
  NuGet.Config
  README.md
  {solution}.sln
  • src - Main projects (the product code)
  • tests - Test projects
  • docs - Documentation stuff, markdown files, help files etc.
  • samples (optional) - Sample projects
  • lib - Things that can NEVER exist in a nuget package
  • artifacts - Build outputs go here. Doing a build.cmd/build.sh generates artifacts here (nupkgs, dlls, pdbs, etc.)
  • packages - NuGet packages
  • build - Build customizations (custom msbuild files/psake/fake/albacore/etc) scripts
  • build.cmd - Bootstrap the build for windows
  • build.sh - Bootstrap the build for *nix
  • global.json - ASP.NET vNext only

.gitignore

[Oo]bj/
[Bb]in/
.nuget/
_ReSharper.*
packages/
artifacts/
*.user
*.suo
*.userprefs
*DS_Store
*.sln.ide

There's probably more things that go in the ignore file.

  • Update: Added docs folder
  • Added README.md and LICENSE - Critical if you're OSS, if not ignore it
  • Renamed test to tests
  • Added lib for things that CANNOT exist in nuget packages
  • Removed NuGet.config for people using packet :)
  • Added global.json for ASP.NET vnext
  • Added .editorconfig file in the root (x-plat IDE settings)
  • Added NuGet.config back because people were confused about it missing

Maybe add bower dir to the gitignore file?

Owner

davidfowl commented Oct 28, 2014

This is more of a baseline .gitignore, it should have a ton more things specific to your project.

Are the files in samples what is created via code-gen or is it a place for devs to place samples? Also, I'd personally prefer the artifacts dir to be in the build dir and not at the project root. Thanks David.

Owner

davidfowl commented Oct 28, 2014

@jskulavik artifacts shouldn't be in the build dir, it's just transient, intermediate output. The build dir is for build scripts (it's the src equivalent for build stuff).

samples are placed in dev samples. Sample projects, showing how to use the things in src.

fraga commented Oct 28, 2014

Gitignore templates can be found here https://github.com/github/gitignore

scripts folder

Most of my .Net projects end up with such a folder. It contains scripts that are useful for anyone actively developing on the project. Items like

  • building + installing a dogfood version of the product
  • wrapping all the steps necessary to build and validate a deployment

I could see an argument for them being in build but it's not build so much as develop

horsdal commented Oct 28, 2014

Would add NCrunch files to .gitignore:

*.ncrunchproject  
*.ncrunchsolution 

and maybe a docs folder.

Otherwise it looks reasonable.

Owner

davidfowl commented Oct 28, 2014

@steveoh Not sure that makes sense, since src is plural πŸ˜„. It would mean that we use artifact and package which is just bizarre.

Owner

davidfowl commented Oct 28, 2014

@jaredpar lets put those things in build. I sometimes have a scripts folder too but lets just kill that convention and call it build.

stashev commented Oct 28, 2014

Usually .nuget folder used by build server, so its should be in source control.

@davidfowl fair enough.

I like it. These are the most common conventions i've seen and have been using most of them for a while on many of my projects. root is for configs, build scripts, deployment scripts, and package description files for nuget/npm/bower...and the code all resides in src. i've seen build output in both /build or /dist, but I like /build just fine. Question. Is the artifacts dir intended to be the build output artifacts, or something else?

pebezo commented Oct 28, 2014

  1. Aren't these going to be sorted, which would put artifacts at the top? Or is VS going to give /src preference?
  2. nuget.config should go into /packages and build.* into /build imo
  3. What about IDE temp files? I thought we're going to have a folder for that that we could easily exclude from source control.

samples - seems like a very narrow scenario. Not saying it isn't applicable to a lot of things you and the other teams at Microsoft are working on day-to-day but in the wild, maybe not common.

packages - I assume this is for referenced packages (like current solution directories and the "packaages" subdir), not generated packages. In this structure where would generated packages live? I generally like them not too far from the root to make it easier to push to Nuget.

There are many cases where I have files that live outside of the source--that are used adjunctly (shared) or independently of the source. e.g. Store/Marketplace image files, scripts to generate such image files, meta information, etc. Right now, I generally keep those in the root folder; but in the spirit of the compartmentalization this structure seems to suggest, a different folder for those may be useful. "artifacts" comes to mind for a folder name; but that's used by build artifacts ("artifacts" seems overly broad if it is "build artifacts"). These other types of artifacts may/may not live in source control

Other directories I've found useful/encountered: doc, install/deploy, help, and libs.

Owner

davidfowl commented Oct 28, 2014

@pebezo

Aren't these going to be sorted, which would put artifacts at the top? Or is VS going to give /src preference?

artifacts are never in the VS solution, it's where transient build artifacts go.

nuget.config should go into /packages and build.* into /build imo

It should be in the root of the solution. The packages folder is never checked in. build.cmd and build.sh are always in the root and the pattern is you clone the repository and just type build from the command prompt. It makes it all that much smoother.

What about IDE temp files? I thought we're going to have a folder for that that we could easily exclude from source control.

When that happens, we'll update this script to add it to the .gitignore.

Owner

davidfowl commented Oct 28, 2014

@sirkirby

Is the artifacts dir intended to be the build output artifacts, or something else?

@peteraritchie

In this structure where would generated packages live? I generally like them not too far from the root to make it easier to push to Nuget.

Anything generated goes into artifacts. I'm going to go into more details about generated nupkgs and where they should go, along with dll/pdbs/mdbs built per project etc.

Have you considered this https://github.com/fsprojects/ProjectScaffold I currently use this for F# and C# projects alike.

pebezo commented Oct 28, 2014

"artifacts are never in the VS solution, it's where transient build artifacts go." -- /temp sounds better to me

Owner

davidfowl commented Oct 28, 2014

@colinbull The layout looks great and I think they overlap, that project is much more opinionated than this proposal is trying to be (which probably makes it more useful as it has tools). I don't care what build tools are used to produce things, I just want them to end up in the same place.

Readme.md?

Owner

davidfowl commented Oct 28, 2014

@pebezo nah, build-artifacts shortened to artifacts πŸ˜„

Owner

davidfowl commented Oct 28, 2014

AndyCross all goes into the root. This isn't supposed to be the set of things you have in your project. Instead, it's the minimum set of things you should have in your project layout.

pebezo commented Oct 28, 2014

Then /build.artifacts πŸ˜„

Admirable. I'd use a Readme.md with a quickstart before I looked at the samples.

ashmind commented Oct 28, 2014

My approach is normally based on the assumption that the source is the most important thing there is for the project. Yes, there might be some build-related things, but those are not worthy to be presented as something of same importance as project source.

So instead of banishing source to a src folder I keep it on top.

Example based on your structure:

$/
  #packages/
  #build/
  #samples/
  !artifacts/ (I normally use ! to identify folders that are transient)
  Project1/
  Project2/
  Project3/
  TestProject1/
  TestProject2/   
  .gitignore
  .gitattributes
  solution.sln
  NuGet.config
  build.cmd
  build.sh

I think I'd like tests better than test, to make it consistent with samples, artifacts, packages (and the fact that you hopefully have more than one test πŸ˜„ )

osbornm commented Oct 28, 2014

tests not test

Two suggestions:

  • lib - binaries which are linked to in the source but are not distributed through NuGet (probably an old-school thing)
  • tools - binaries which are used as part of the build script (e.g. test runners, external tools)

flq commented Oct 28, 2014

@shiftkey your tools would go under build.

But indeed, where would old school libs go?

Also I am under the impression that some of the dirs are actually optional, right? E.g. Not every project needs samples.

@shiftkey shouldn't those go under build?

I do agree they are needed though for the reasons you stated

Tests are sources, why are they separate from src?

forki commented Oct 28, 2014

What about releasenotes file and readme? You should really look deeper into ProjectScaffold.

forki commented Oct 28, 2014

Appveyor, Travis?

-"The inconsistency in layout of .NET OSS projects is baffling"
You solve this by promoting ProjectScaffold.
Not by introducing yet antother structure to make it even more inconsistent.

Owner

davidfowl commented Oct 28, 2014

@shiftkey

lib - binaries which are linked to in the source but are not distributed through NuGet (probably an old-school thing)

lib - Death to lib, use nuget.
tools - I like it but would it be checked in to source control?

Owner

davidfowl commented Oct 28, 2014

@kenegozi easy to do globbing patterns, running all tests becomes ls -r tests/**/*Tests*.dll | %{ xunit $_ } (powershell syntax) something like that

Owner

davidfowl commented Oct 28, 2014

@flq Yep! You don't need samples

Owner

davidfowl commented Oct 28, 2014

@burn-ashe Is the .nuget folder for nuget.exe?

+1 to killing lib. I've always hated that "word." Abbreviations are for hacks. Please spell out words fully, don't be lazy. :) Everything else looks great. I'll be sure to use the results of this for my projects going forward.

dliuzzi commented Oct 28, 2014

Any reason build for Windows is a plain batch file instead of PowerShell?

Owner

davidfowl commented Oct 28, 2014

@dliuzzi works on windows xp (I'm just kidding). It's the lowest common denominator on windows and it's double clickable.

@davidfowl @flq @jaredpar oops, my bad. I didn't notice the build folder. That's fine to use instead of tools if people prefer that name.

Death to lib, use nuget

I'm not going to lie, I've not checked how NuGet support is for unmanaged assemblies these days. But these are definitely projects which exist outside the NuGet ecosystem (like sqlite3)...

Owner

davidfowl commented Oct 29, 2014

@shiftkey How do those deps end up in the bin folder (for msbuild based projects)? Custom build script that copies all of them? There's likely still a case for lib but I'm not sure I would call it lib since people might assume that it's the generic 3rd party dependency dumping ground.

Here's an example of how we bring sqlite in one of our build scripts:

https://github.com/aspnet/DataCommon.SQLite/blob/dev/makefile.shade#L21

How do those deps end up in the bin folder (for msbuild based projects)? Custom build script that copies all of them?

I can think of a couple of tricks:

We're embedding these assemblies into the app - so we can't use these tricks, and will instead manually link to the lib files in the csproj.

There's likely still a case for lib but I'm not sure I would call it lib since people might assume that it's the generic 3rd party dependency dumping ground.

In other situations we've called this ext to indicate "external dependencies" - does that sounds more suitable?

Here's an example of how we bring sqlite in one of our build scripts:

/shrug - yeah, being able to pull in C# code rather than write MSBuild scripts makes that trick appealing. But with how rarely we bump these binaries, I'm just kinda meh on eliminating them from source control.

And in build server situations you should do a clean of untracked files, so you'd miss the benefits of the local NuGet cache and have to hit the network.

Owner

davidfowl commented Oct 29, 2014

In each of those examples, dependencies come from NuGet packages (the fact that they use build scripts to copy them to the folder is kinda irrelevant, though this probably doesn't work on asp.net vnext). So lets take something that doesn't have a nuget package, libuv. If you wanted to use libuv in a .NET project, you'd probably need to put it in lib then author a script to copy it (or just load it in place)

gep13 commented Oct 29, 2014

@dliuzzi works on windows xp (I'm just kidding). It's the lowest common denominator on windows and it's double clickable.

I typically have this, and then simply invoke the PowerShell script that I am using :-) That way, still double clickable.

πŸ‘ for a docs folder

For me:
builds instead of build
tests instead of test

Layoric commented Oct 29, 2014

+1 for 'tests' instead of 'test', but looks good!

Owner

davidfowl commented Oct 29, 2014

@J0rgeSerran0 I'll do tests because it's more consistent by I think src and build should stay.

@forki @rogeralsing This discussion is very C#-ish :) Similar to ones from roslyn codeplex. Inventing the wheel all the time, in very hot debates :)

PowerShell is right-clickable ("Run with PowerShell")... Come on guys, in world of "death to lib use nuget" we should also say "death to cmd use powershell". It is only a matter of time until cmd will deprecated and PowerShell the only shell on windows (well until then we maybe have the next one ;) )

NuGet changed the mentality of .NET devs, PowerShell should do the same.

@davidfowl I'm looking at revision 6a126e4d387335c9aed6dc1601fcd1c4875ce360. Looks great to me except for:

  • global.json file at the root is missing.
  • I'd prefer scripts folder instead of build as I might have any script files there which don't need to be specific for build process. A few examples would be:
    • a script file which would run only once to set up your environment for the project.

      Side Note: I don't like the fact that I need some scripts to run to set up the environment (db, etc.) but there are some places you really cannot avoid this.

    • deployment scripts which are not related to build process.

@yannisgu powershell first needs to drop this stupid 'ps1' file extension name πŸ˜„ It just makes me not double click on it.

While putting your .sln file in the root directory and having separate /src, /tests and /packages folders for your main projects, tests and NuGet packages sounds like a good idea, it does have one problem. It's not the Visual Studio default, and it requires discipline to maintain it. On a project with several developers, as sure as eggs are eggs you're going to find someone checks in a new project into your root folder, and you'll have to faff about relocating it.

For this reason, I personally prefer to put the .sln file in the /src folder and just use the Visual Studio defaults from there on -- all the project folders and the NuGet /packages folder immediately under /src. If that starts to feel unwieldy, it indicates that you probably have too many projects in your solution.

I'd be interested to know what your thoughts are here -- in particular, what are the advantages to your approach?

+1 to @yannisgu's comment ... Powershell > Batch!

jrwren commented Oct 29, 2014

+1 @jammycakes Visual Studio is the tool of choice. Its defaults are correct, unless no one on your team is using Visual Studio, and you aren't open source, or you don't want contributions from VS users, then do whatever you want.

Yes but should we use spaces or tabs? :)

Do you put DLLs that are not part of nuget to packages as well, or somewhere else?

@davdfowl I'd love to say "death to lib" but the set of technologies supported by Visual Studio is larger than the set of technologies supported by Nuget; so, Visual Studio users will be forced to use libraries outside of Nuget, but this project structure will not accommodate for it.

@davidfowl I'm agree about src, but not about build/builds.

In my case I use builds instead of build because I want to have inside of "builds", a debug build separated of the release build.
Inside of the "builds" directory, I have two directories: debug and release.
What do you think about it?

@vkocjancic That should go under a different folder as you are ignoring the packages folder. The common conversion for that is a folder named lib (I also see a few people using 3rdParty name) at the solution root.

I can see that some good thought and energy has been expended on this, and it's also getting conversations going, which is great. However - like some other people here, I'm not sure what this is trying to offer over and above the Project Scaffold: -

  • It does everything that this does and lots more.
  • It's being used in lots of packages already.
  • It's gone through many learnings and works very, very well now.
  • It works on both C# and F#.

I appreciate the comment re: not trying to be prescriptive - but why not just fork that and remove the bits that you feel shouldn't be there? (For what it's worth, I would rather be more prescriptive than not for this stuff - it just takes away all the thought of creating a new bit of code).

Just my two pennies.

Owner

davidfowl commented Oct 29, 2014

ProjectScaffold is great and I'm fine promoting is but one thing I don't want to do is force tools onto projects. People choose different tools for a reason and there's surely a limit to what people will tolerate.

@isaacabraham Let's say I forked the project and removed all the tools and make one for each build system. Then also made a flavor that worked for ASP.NET vNext (since it doesn't currently account for any of it), would that make everyone happy πŸ˜„ ?

Owner

davidfowl commented Oct 29, 2014

@J0rgeSerran0 build is for build scripts not build output, looks like you mean artifacts.

Owner

davidfowl commented Oct 29, 2014

@peteraritchie Ok how about death to lib if the thing you're putting in there exists in a nuget package?

jethrob commented Oct 29, 2014

I'm guessing .nuget will go into the build folder then? (Which contains the NuGet.exe)

Why no extension on LICENSE?

nfplee commented Oct 30, 2014

I like the consistent pluralization. My main suggestion is to add a global.json file. I would also suggest renaming NuGet.config to nuget.json. I understand this is out of your control but with the planned changes to NuGet 3.0 I think this is feasible. Even better it would be great to merge the NuGet.config (nuget.json) settings inside the global.json file but I guess that is something for the NuGet team.

forki commented Oct 31, 2014

Why do you have a nuget file at all? I thought it shouldn't be about specific tools. In projectscaffold we're happy to use paket instead of nuget. See https://github.com/fsprojects/Paket

Owner

davidfowl commented Oct 31, 2014

@forki gone now

Owner

davidfowl commented Oct 31, 2014

@nfplee I'll wait for that change to happen πŸ˜„. I added global.json thought

forki commented Oct 31, 2014

What's global.json doing?

Owner

davidfowl commented Nov 1, 2014

@forki Thats for ASP.NET vnext projects.

Mpdreamz commented Nov 2, 2014

Looking great except {solutionname}.sln files being at the root and not under src

Toolings tends to generate a bunch of generated files related to sln files: suo, sdf, ipch *.DotSettings *.ncrunch *.sln.GhostDoc to name a few which end up cluttering the root overview of a project.

I know tooling is out of scope but I would still like to make a plea to come with a default .editorconfig file in the root. EditorConfig is a great crossplatform way to handle editor settings (tabs, newlines) per repository. Its supported by almost all the major editors and has a great visual studio extension (including syntax highlighting and autocomplete for .editorconfig files) which already works VS2014.

It would be great way to promote the usage of this tool to get rid of formatting diffs.

Owner

davidfowl commented Nov 2, 2014

Looking great except {solutionname}.sln files being at the root and not under src

@Mpdreamz ehhhhhhh, not sure how I feel about that.

.editorconfig added.

If .sln only refers to things under src....................

Mpdreamz commented Nov 3, 2014

@davidfowl src/{solutionname}.sln is already a common pattern here's a random grab of popular C# repos that have a src folder.

all of them have a clean root.

Take https://github.com/reactiveui/ReactiveUI for instance and the root is cluttered with support files of course they should be in .gitignore but in active usage they'll be there nonetheless.

Just stating my personal preference here :) I can see with tests and samples being at the root as well and not under source, solutions under src will be problematic.

Much much love for the inclusion of an .editorconfig file thats seriously awesome!

whut commented Nov 4, 2014

When you create project in Visual Studio and add it to Git, VS will create a default .gitignore which have an exclude for \build folder. So \build should be for the build results (instead of the \artifacts folder, which name is also too broad, like @peteraritchie mentioned).

I always had only few build scripts, so it was OK to keep them in root, but what when there are plenty of them? Maybe that is just too project-specific and it should not be standardized?

Add the RELEASE_NOTES.md, like in the ProjectScaffold. It will be good to be here as close as possible to it.

Owner

davidfowl commented Nov 5, 2014

@whut it's going to be called artifacts and build. The entire point of the convention is to give up some stuff. I understand that everyone won't agree with it but that's ok. build should be checked in artifacts should be ignored.

RELEASE_NOTES.md sounds fine I can add that.

"The entire point of the convention is to give up some stuff. I understand that everyone won't agree with it but that's ok."

It's more not agreeing, the default gitignore you get from say, github for windows, will explicitly exclude build. Folks might be in for quite a bit of confusion and frustration when "all my build stuff is gone".

Owner

davidfowl commented Nov 5, 2014

Ah hah! We should totally fix github for windows /cc @Haacked πŸ˜„

whut commented Nov 6, 2014

@davidfowl, yep, this is about compromise, I didn't put here a comment about "I like this or that better", but about valid issue with name "build" that it is added to .gitignore by default by many tools. Do whatever you like, cheers:)

Owner

davidfowl commented Nov 6, 2014

@whut which tools in particular? I'm curious because i've never encountered it myself. GH for windows and what else? Source tree?

kenegozi commented Nov 7, 2014

@davidfowl drop the tests prefix from the glob and the result remain the same.

@davidfowl +1 to death to lib for nuget packages. I thought that went without saying :)

Romoku commented Nov 30, 2014

πŸ‘

@davidfowl where would you put a common assemblyinfo.cs? It's not uncommon to have shared properties files that multiple projects share. I've seen this in several projects, including scriptcs :-)

Overall the structure looks good to me. As was commented, I've seen scripts pretty commonly added in cases where there are grunt scripts for example.

sln is the visual studio workspace for visual studio code, so i put it in /src alongside any test projects, of which I tend to only have one anyway. So +1 for .sln to be in /src, and as such +1 to move tests in /src in whatever format you want.

To take @davidfowl example ls -r tests/**/*Tests*.dll | %{ xunit $_ }, although I imagine one meant ls -r artefacts/**/*Tests*.dll | %{xunit $_}.

We already use art_e_facts spelt correctly in most of our solutions.

+1 million on all the associated sln files that need checking in (.DotSetting amongst others).

@davidfowl tests is related directly to the production code, should be under src. No point in adding hierarchy where it doesn't have to be. There's no benefit in having tests folder, but it will add overhead of remembering where to put "source" projects vs "test" projects.

Haacked commented Dec 12, 2014

@davidfowl tests is related directly to the production code, should be under src. No point in adding hierarchy where it doesn't have to be. There's no benefit in having tests folder, but it will add overhead of remembering where to put "source" projects vs "test" projects.

I agree with this. Instead, use a VS Solution Folder to group tests within your solution.

damianh commented Dec 22, 2014

@davidfowl tests is related directly to the production code, should be under src. No point in adding hierarchy where it doesn't have to be. There's no benefit in having tests folder, but it will add overhead of remembering where to put "source" projects vs "test" projects.

+1 to @SeanFeldman.

mastoj commented Dec 23, 2014

I really like that someone is trying to streamline how things are done, but I do agree with @Mpdreamz about the location of *.sln and @SeanFeldman regarding the test.

@davidfowl, can you elaborate on why you think that *.sln should be in the root and not in the src folder? The only answer you wrote was "@Mpdreamz ehhhhhhh, not sure how I feel about that."

@davidfowl, How would you suggest handling (master) assets like PSD files? The projects use the images produced by them, but aren't directly used and very much specific to the solution. Maybe an ".\assets"?

chartek commented Jan 6, 2015

If tests/ is relocated inside of src/ then moving the solution file inside could make sense. But it also opens up additional questions...

Why stop with tests? Why shouldn't samples/ be included as well? If a solution contains everything (source, tests, and samples) and the solution file is moved inside src, then it would be weird for the samples not to be in the src folder as well.

Additionally, packages/ exists in the same directory as the solution file by default. Should that be in src/ also? Granted, you can change the location of packages via the Nuget.config file, but doesn't Nuget.config need to live next to the solution file? And if the packages folder is relocated, shouldn't lib/ be moved as well? Where is that line drawn?

I agree with this. Instead, use a VS Solution Folder to group tests within your solution.

@Haacked How does that work if I'm using Sublime or another non-Visual Studio editor? Is that something other editors can recognize?

My personal choice would be to keep .sln and tests in the root folder and force all of the temporary/developer-specific files (suo, sdf, ipch, *.DotSettings, *.ncrunch, *.sln.GhostDoc, etc.) into a shared folder (a hidden .config/ folder maybe?) to keep the root folder clean. That would require changes to each project that generates those files so that may be easier said than done.

Haacked commented Jan 14, 2015

Hey @davidfowl, not sure "build" is a good folder name if it contains anything persistent. Build is very commonly used solely for build artifacts. It's very common for this folder to be ignored. For example, the default .gitignore file for Visual Studio ignores it.

Might make sense to put any "customizations" in a build subfolder of tools or scripts.

Haacked commented Jan 14, 2015

I understand that everyone won't agree with it but that's ok. build should be checked in artifacts should be ignored.

That's really nice, but people are already ignoring build. I think this is one of those things where it's a bit too late to change the existing convention that's been embedded in tools for years.

bitbonk commented Jan 20, 2015

So what is the reason for {solution}.sln not being in the src/ folder ?

When a solution level package is installed, e.g. xunit.runners, an entry is added to .nuget\packages.config. This would mean that .nuget\ needs to be included in source control, no?

whut commented Feb 11, 2015

Previously I was against "build for build scripts" and "artifacts for build output". But recently we where reorganizing source code structure, and the end result is exactly the modest approach proposed here, so the build output is in "artifacts" folder. But currently all our build and deploy/release scripts are in root, as there are not so many files, so we do not have"build" subfolder.

Some proposed "scripts" instead of "build", this looks interesting, as it fulfills the: "build should be avoided as it is ignored in some tools" and "build could contain not only build related scripts". But maybe this is just something outside the "common" layout problem, and some teams just need separate folder for custom scripts?

having src and tests makes it hard to setup a visual studio solution for both because this is not how visual studio thinks the world should be.
Therefore I always have tests, specs and production code in src

Fido789 commented May 13, 2015

How do you create actual physical folders in solution? I want "tests" folder to be physical folder and at the same level as "src" folder.

If all source code is placed in a src sub-directory, won't VS be continually adding ".src" to the namespace when you create new files? Obviously not a problem for everyone, or something that can't be worked around, but it's something to keep in mind.

I have a 3 parts AssemblyInfo files, where it supoused to be? this are shared between projects. Also I have some files like *.ico, *.bmp, what about resources folder, even more: wix projects?

So if you create a solution folder and call it "tests", then add projects(via new project) to that folder(think C# library projects) what actually happens is VS studio will create the physical folder for you. BUT you can also bork this completely when creating the project and select the default folder which autotragically defaults to $/src.

I'm assuming my approach is valid but I could be terribly wrong.

Project organization is key, I like to keep my structure pretty flat for maintainability and quick development

Could we sort the folders and then files alphabetically? It would make it much easier when eyeballing a current solution on disk to see if it matches.

Owner

davidfowl commented Sep 23, 2016

Should be reordered

mwhitis commented Oct 7, 2016

@davidfowl, just curious if you had any thoughts about @wholroyd's question about "master" files that aren't used directly in the code, but generate assets that are. My use case is for a prototype xml / json file that is used to generate a set of domain objects. It's not updated frequently, but like to keep it around in case the model ever changes.

One thing I don't like is that the build folder takes precedence over build.cmd when you type B and then Tab to autocomplete.

btw - thanks for re-ordering.

.gitignore and .gitattributes should be swapped. I'd be happy to PR it if it was in a repo...

bitbonk commented Feb 22, 2017

What would be the best place for nuspec files and additional files that might be needed to build the nupkg (like readme.md, additional content or build and publish scripts)?

@bitbonk, sounds to me like they should live under build/.

alextercete commented Apr 26, 2017

Any advice on where to put test results (XML reports, screen capture videos, code coverage reports, etc)? Would test-results/ be reasonable (or maybe just results)?

ppcuban commented May 20, 2017

I've read almost every single comment. Some of them present real good alternatives. My suggestion to everyone in this thread would be to create your own folder structure and then post the link here so that we can look at the end result and see how it appeals our eye.

What do you think? In addition to all the good ideas posted here, when it comes to the build or script folder, I personally like a repo called "Script To Rule Them All" or something along those lines, that basically explains why you should have a script or build folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment