Using a custom project type was a bad idea, as Eric pointed out in the other thread
"A custom project type is a option of last resort. Having a custom project type means that in order to load a solution the project type needs to be installed on the devs system. For this project to be successful,
it has to be non invasive and I think a custom project would not be able to do this"
So the closest thing is a standard library project, which can be sort of abused as a plain file holder, but it's a hack and the overall user experience is inferior:
- You can't hide it in VS
- It'll still have its References and Properties pseudo-folders which are meaningless here
- You end up with a project file that needs to be checked in
Contrast that with the experience where the user only sees the things that matter. e.g. I add a NuPack reference to NHibernate, and all I see are the references getting added to my project. I don't see a bunch of other crap that I don't directly
care about popping up in my solution. It's the same experience as adding a regular assembly reference, which is what we want!
Note that I'm not saying that we should ignore source control. We will make it work in the scenarios that matter most, starting with TFS (and all the ones that are free of course). We will get community help to cover others as they come up.