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
@ryanande

This comment has been minimized.

Show comment Hide comment
@ryanande

ryanande Oct 28, 2014

Maybe add bower dir to the gitignore file?

Maybe add bower dir to the gitignore file?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 28, 2014

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

Owner

davidfowl commented Oct 28, 2014

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

@jskulavik

This comment has been minimized.

Show comment Hide comment
@jskulavik

jskulavik Oct 28, 2014

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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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

This comment has been minimized.

Show comment Hide comment
@fraga

fraga Oct 28, 2014

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

fraga commented Oct 28, 2014

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

@jaredpar

This comment has been minimized.

Show comment Hide comment
@jaredpar

jaredpar Oct 28, 2014

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

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

This comment has been minimized.

Show comment Hide comment
@horsdal

horsdal Oct 28, 2014

Would add NCrunch files to .gitignore:

*.ncrunchproject  
*.ncrunchsolution 

and maybe a docs folder.

Otherwise it looks reasonable.

horsdal commented Oct 28, 2014

Would add NCrunch files to .gitignore:

*.ncrunchproject  
*.ncrunchsolution 

and maybe a docs folder.

Otherwise it looks reasonable.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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

This comment has been minimized.

Show comment Hide comment
@stashev

stashev Oct 28, 2014

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

stashev commented Oct 28, 2014

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

@jaredpar

This comment has been minimized.

Show comment Hide comment
@jaredpar

jaredpar Oct 28, 2014

@davidfowl fair enough.

@davidfowl fair enough.

@sirkirby

This comment has been minimized.

Show comment Hide comment
@sirkirby

sirkirby Oct 28, 2014

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?

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

This comment has been minimized.

Show comment Hide comment
@pebezo

pebezo 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.

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.
@peteraritchie

This comment has been minimized.

Show comment Hide comment
@peteraritchie

peteraritchie Oct 28, 2014

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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

@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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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.

@colinbull

This comment has been minimized.

Show comment Hide comment
@colinbull

colinbull Oct 28, 2014

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

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

@pebezo

This comment has been minimized.

Show comment Hide comment
@pebezo

pebezo Oct 28, 2014

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

pebezo commented Oct 28, 2014

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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.

@AndyCross

This comment has been minimized.

Show comment Hide comment
@AndyCross

AndyCross Oct 28, 2014

Readme.md?

Readme.md?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 28, 2014

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

Owner

davidfowl commented Oct 28, 2014

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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

This comment has been minimized.

Show comment Hide comment
@pebezo

pebezo Oct 28, 2014

Then /build.artifacts πŸ˜„

pebezo commented Oct 28, 2014

Then /build.artifacts πŸ˜„

@AndyCross

This comment has been minimized.

Show comment Hide comment
@AndyCross

AndyCross Oct 28, 2014

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

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

@ashmind

This comment has been minimized.

Show comment Hide comment
@ashmind

ashmind 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

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
@akoeplinger

This comment has been minimized.

Show comment Hide comment
@akoeplinger

akoeplinger Oct 28, 2014

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 πŸ˜„ )

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

This comment has been minimized.

Show comment Hide comment
@osbornm

osbornm Oct 28, 2014

tests not test

osbornm commented Oct 28, 2014

tests not test

@shiftkey

This comment has been minimized.

Show comment Hide comment
@shiftkey

shiftkey Oct 28, 2014

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)

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

This comment has been minimized.

Show comment Hide comment
@flq

flq 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.

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.

@jaredpar

This comment has been minimized.

Show comment Hide comment
@jaredpar

jaredpar Oct 28, 2014

@shiftkey shouldn't those go under build?

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

@shiftkey shouldn't those go under build?

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

@kenegozi

This comment has been minimized.

Show comment Hide comment
@kenegozi

kenegozi Oct 28, 2014

Tests are sources, why are they separate from src?

Tests are sources, why are they separate from src?

@forki

This comment has been minimized.

Show comment Hide comment
@forki

This comment has been minimized.

Show comment Hide comment
@forki

forki Oct 28, 2014

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

forki commented Oct 28, 2014

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

@forki

This comment has been minimized.

Show comment Hide comment
@forki

forki Oct 28, 2014

Appveyor, Travis?

forki commented Oct 28, 2014

Appveyor, Travis?

@rogeralsing

This comment has been minimized.

Show comment Hide comment
@rogeralsing

rogeralsing Oct 28, 2014

-"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.

-"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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

@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?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 28, 2014

@flq Yep! You don't need samples

Owner

davidfowl commented Oct 28, 2014

@flq Yep! You don't need samples

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 28, 2014

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

Owner

davidfowl commented Oct 28, 2014

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

@Mike-EEE

This comment has been minimized.

Show comment Hide comment
@Mike-EEE

Mike-EEE Oct 28, 2014

+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.

+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

This comment has been minimized.

Show comment Hide comment
@dliuzzi

dliuzzi Oct 28, 2014

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

dliuzzi commented Oct 28, 2014

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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.

@shiftkey

This comment has been minimized.

Show comment Hide comment
@shiftkey

shiftkey Oct 29, 2014

@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)...

@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)...

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

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

@shiftkey

This comment has been minimized.

Show comment Hide comment
@shiftkey

shiftkey Oct 29, 2014

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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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)

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

This comment has been minimized.

Show comment Hide comment
@gep13

gep13 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

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

@J0rgeSerran0

This comment has been minimized.

Show comment Hide comment
@J0rgeSerran0

J0rgeSerran0 Oct 29, 2014

For me:
builds instead of build
tests instead of test

For me:
builds instead of build
tests instead of test

@Layoric

This comment has been minimized.

Show comment Hide comment
@Layoric

Layoric Oct 29, 2014

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

Layoric commented Oct 29, 2014

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 29, 2014

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

Owner

davidfowl commented Oct 29, 2014

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

@vasily-kirichenko

This comment has been minimized.

Show comment Hide comment
@vasily-kirichenko

vasily-kirichenko Oct 29, 2014

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

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

@yannisgu

This comment has been minimized.

Show comment Hide comment
@yannisgu

yannisgu Oct 29, 2014

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.

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.

@tugberkugurlu

This comment has been minimized.

Show comment Hide comment
@tugberkugurlu

tugberkugurlu Oct 29, 2014

@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.

@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.

@tugberkugurlu

This comment has been minimized.

Show comment Hide comment
@tugberkugurlu

tugberkugurlu Oct 29, 2014

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

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

@jammycakes

This comment has been minimized.

Show comment Hide comment
@jammycakes

jammycakes Oct 29, 2014

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?

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?

@Mike-EEE

This comment has been minimized.

Show comment Hide comment
@Mike-EEE

Mike-EEE Oct 29, 2014

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

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

@jrwren

This comment has been minimized.

Show comment Hide comment
@jrwren

jrwren 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.

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.

@mcintyre321

This comment has been minimized.

Show comment Hide comment
@mcintyre321

mcintyre321 Oct 29, 2014

Yes but should we use spaces or tabs? :)

Yes but should we use spaces or tabs? :)

@vkocjancic

This comment has been minimized.

Show comment Hide comment
@vkocjancic

vkocjancic Oct 29, 2014

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

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

@peteraritchie

This comment has been minimized.

Show comment Hide comment
@peteraritchie

peteraritchie Oct 29, 2014

@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.

@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.

@J0rgeSerran0

This comment has been minimized.

Show comment Hide comment
@J0rgeSerran0

J0rgeSerran0 Oct 29, 2014

@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?

@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?

@tugberkugurlu

This comment has been minimized.

Show comment Hide comment
@tugberkugurlu

tugberkugurlu Oct 29, 2014

@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.

@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.

@isaacabraham

This comment has been minimized.

Show comment Hide comment
@isaacabraham

isaacabraham Oct 29, 2014

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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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

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 πŸ˜„ ?

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 29, 2014

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

Owner

davidfowl commented Oct 29, 2014

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 29, 2014

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

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

This comment has been minimized.

Show comment Hide comment
@jethrob

jethrob Oct 29, 2014

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

jethrob commented Oct 29, 2014

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

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Oct 30, 2014

Why no extension on LICENSE?

Why no extension on LICENSE?

@nfplee

This comment has been minimized.

Show comment Hide comment
@nfplee

nfplee 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.

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

This comment has been minimized.

Show comment Hide comment
@forki

forki 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

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

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 31, 2014

@forki gone now

Owner

davidfowl commented Oct 31, 2014

@forki gone now

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Oct 31, 2014

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

Owner

davidfowl commented Oct 31, 2014

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

@forki

This comment has been minimized.

Show comment Hide comment
@forki

forki Oct 31, 2014

What's global.json doing?

forki commented Oct 31, 2014

What's global.json doing?

@J0rgeSerran0

This comment has been minimized.

Show comment Hide comment
@J0rgeSerran0

J0rgeSerran0 Oct 31, 2014

@davidfowl Ok! :)

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 1, 2014

@forki Thats for ASP.NET vnext projects.

Owner

davidfowl commented Nov 1, 2014

@forki Thats for ASP.NET vnext projects.

@Mpdreamz

This comment has been minimized.

Show comment Hide comment
@Mpdreamz

Mpdreamz 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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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.

@kijanawoodard

This comment has been minimized.

Show comment Hide comment
@kijanawoodard

kijanawoodard Nov 3, 2014

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

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

@Mpdreamz

This comment has been minimized.

Show comment Hide comment
@Mpdreamz

Mpdreamz 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!

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

This comment has been minimized.

Show comment Hide comment
@whut

whut 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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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.

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.

@kijanawoodard

This comment has been minimized.

Show comment Hide comment
@kijanawoodard

kijanawoodard Nov 5, 2014

"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".

"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".

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Nov 5, 2014

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

Owner

davidfowl commented Nov 5, 2014

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

@whut

This comment has been minimized.

Show comment Hide comment
@whut

whut 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:)

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:)

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl 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?

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?

@khellang

This comment has been minimized.

Show comment Hide comment
@kenegozi

This comment has been minimized.

Show comment Hide comment
@kenegozi

kenegozi Nov 7, 2014

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

kenegozi commented Nov 7, 2014

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

@peteraritchie

This comment has been minimized.

Show comment Hide comment
@peteraritchie

peteraritchie Nov 8, 2014

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

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

@Romoku

This comment has been minimized.

Show comment Hide comment
@Romoku

Romoku Nov 30, 2014

πŸ‘

Romoku commented Nov 30, 2014

πŸ‘

@glennblock

This comment has been minimized.

Show comment Hide comment
@glennblock

glennblock 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 :-)

@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 :-)

@glennblock

This comment has been minimized.

Show comment Hide comment
@glennblock

glennblock Nov 30, 2014

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.

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.

@serialseb

This comment has been minimized.

Show comment Hide comment
@serialseb

serialseb Dec 2, 2014

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).

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).

@SeanFeldman

This comment has been minimized.

Show comment Hide comment
@SeanFeldman

SeanFeldman Dec 11, 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.

@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

This comment has been minimized.

Show comment Hide comment
@Haacked

Haacked 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.

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

This comment has been minimized.

Show comment Hide comment
@damianh

damianh 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.

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

This comment has been minimized.

Show comment Hide comment
@mastoj

mastoj 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."

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."

@wholroyd

This comment has been minimized.

Show comment Hide comment
@wholroyd

wholroyd Dec 28, 2014

@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"?

@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"?

@stevenkuhn

This comment has been minimized.

Show comment Hide comment
@stevenkuhn

stevenkuhn 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.

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

This comment has been minimized.

Show comment Hide comment
@Haacked

Haacked 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

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

This comment has been minimized.

Show comment Hide comment
@Haacked

Haacked 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.

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

This comment has been minimized.

Show comment Hide comment
@bitbonk

bitbonk Jan 20, 2015

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

bitbonk commented Jan 20, 2015

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

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Jan 23, 2015

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?

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

This comment has been minimized.

Show comment Hide comment
@whut

whut 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?

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?

@ursenzler

This comment has been minimized.

Show comment Hide comment
@ursenzler

ursenzler Apr 14, 2015

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

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

This comment has been minimized.

Show comment Hide comment
@Fido789

Fido789 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.

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.

@evancox10

This comment has been minimized.

Show comment Hide comment
@evancox10

evancox10 May 16, 2015

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.

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.

@ennerperez

This comment has been minimized.

Show comment Hide comment
@ennerperez

ennerperez Sep 18, 2015

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?

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?

@oshalygin

This comment has been minimized.

Show comment Hide comment
@oshalygin

oshalygin Oct 2, 2015

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

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

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Apr 15, 2016

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.

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.

@davidfowl

This comment has been minimized.

Show comment Hide comment
@davidfowl

davidfowl Sep 23, 2016

Should be reordered

Owner

davidfowl commented Sep 23, 2016

Should be reordered

@mwhitis

This comment has been minimized.

Show comment Hide comment
@mwhitis

mwhitis 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.

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.

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Oct 12, 2016

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.

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.

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Oct 12, 2016

btw - thanks for re-ordering.

btw - thanks for re-ordering.

@adamralph

This comment has been minimized.

Show comment Hide comment
@adamralph

adamralph Oct 12, 2016

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

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

@bitbonk

This comment has been minimized.

Show comment Hide comment
@bitbonk

bitbonk 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 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)?

@alextercete

This comment has been minimized.

Show comment Hide comment
@alextercete

alextercete Apr 26, 2017

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

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

@alextercete

This comment has been minimized.

Show comment Hide comment
@alextercete

alextercete 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)?

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)?

@fernandezjose

This comment has been minimized.

Show comment Hide comment
@fernandezjose

fernandezjose 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.

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.

@ernestohs

This comment has been minimized.

Show comment Hide comment
@ernestohs

ernestohs Jan 26, 2018

@alextercete, good question, I like the idea of use directory hierarchy, something like tests/results

@alextercete, good question, I like the idea of use directory hierarchy, something like tests/results

@bryanjhogan

This comment has been minimized.

Show comment Hide comment
@bryanjhogan

bryanjhogan Mar 13, 2018

Where are people putting database scripts?
I want to add some scripts to generate tables, seed with data, etc.

I can see them going into src or build. Is there a common approach to this?

Where are people putting database scripts?
I want to add some scripts to generate tables, seed with data, etc.

I can see them going into src or build. Is there a common approach to this?

@galkizal

This comment has been minimized.

Show comment Hide comment
@galkizal

galkizal Mar 15, 2018

good point - I have same qn @bryanjhogan (bump)

good point - I have same qn @bryanjhogan (bump)

@MiYanni

This comment has been minimized.

Show comment Hide comment
@MiYanni

MiYanni May 11, 2018

@davidfowl It looks like NuGet.Config preferred casing is nuget.config as per here

MiYanni commented May 11, 2018

@davidfowl It looks like NuGet.Config preferred casing is nuget.config as per here

@Zonnex

This comment has been minimized.

Show comment Hide comment
@Zonnex

Zonnex May 22, 2018

I'd love a "dotnet new" template with this stuff. Available anywhere?

Zonnex commented May 22, 2018

I'd love a "dotnet new" template with this stuff. Available anywhere?

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