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

Maybe add bower dir to the gitignore file?

@davidfowl
Owner

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

@jskulavik

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
Owner

@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
fraga commented Oct 28, 2014

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

@jaredpar

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
horsdal commented Oct 28, 2014

Would add NCrunch files to .gitignore:

*.ncrunchproject  
*.ncrunchsolution 

and maybe a docs folder.

Otherwise it looks reasonable.

@davidfowl
Owner

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

@davidfowl
Owner

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

@stasburn

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

@jaredpar

@davidfowl fair enough.

@sirkirby

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

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
Owner

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

@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

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

@pebezo
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
Owner

@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

Readme.md?

@davidfowl
Owner

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

@davidfowl
Owner

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
pebezo commented Oct 28, 2014

Then /build.artifacts πŸ˜„

@AndyCross

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

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

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
osbornm commented Oct 28, 2014

tests not test

@shiftkey

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

@shiftkey shouldn't those go under build?

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

@kenegozi

Tests are sources, why are they separate from src?

@forki
forki commented Oct 28, 2014

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

@forki
forki commented Oct 28, 2014

Appveyor, Travis?

@rogeralsing

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

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

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

@davidfowl
Owner

@flq Yep! You don't need samples

@davidfowl
Owner

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

@Mike-EEE

+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
dliuzzi commented Oct 28, 2014

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

@davidfowl
Owner

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

@shiftkey

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

@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

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
Owner

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

For me:
builds instead of build
tests instead of test

@Layoric
Layoric commented Oct 29, 2014

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

@davidfowl
Owner

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

@vasily-kirichenko

@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

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

@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

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

@jammycakes

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

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

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

Yes but should we use spaces or tabs? :)

@vkocjancic

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

@peteraritchie

@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

@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

@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

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
Owner

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
Owner

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

@davidfowl
Owner

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

@jethrob
jethrob commented Oct 29, 2014

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

@adamralph

Why no extension on LICENSE?

@nfplee
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
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
Owner

@forki gone now

@davidfowl
Owner

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

@forki
forki commented Oct 31, 2014

What's global.json doing?

@davidfowl
Owner

@forki Thats for ASP.NET vnext projects.

@Mpdreamz
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
Owner

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

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

@Mpdreamz
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
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
Owner

@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

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

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

@whut
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
Owner

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

@kenegozi
kenegozi commented Nov 7, 2014

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

@peteraritchie

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

@Romoku
Romoku commented Nov 30, 2014

πŸ‘

@glennblock

@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

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

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

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

@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
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
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
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
bitbonk commented Jan 20, 2015

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

@adamralph

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

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

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

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

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

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
Owner

Should be reordered

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

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

btw - thanks for re-ordering.

@adamralph

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

@bitbonk
bitbonk commented Feb 22, 2017 edited

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

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