Please see my comment to the question.
I cannot clearly see what do you mean by the document in "MSDN site has deprecated the document". Maybe, this one will work for you:
https://msdn.microsoft.com/en-us/library/ee817674.aspx[
^].
But frankly, you don't really need such document. (Please see my comment again, last clause before the signature where I explain what's really critically needed :-).) You only need to understand how MSBuild work and have understanding of project growth, decision-making, refactoring and complexity control. As to MSBuild, you can learn it all:
https://msdn.microsoft.com/en-us/library/dd637714.aspx[
^],
https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx[
^].
If you analyze it all, you will see that you can choose to develop your own project types, which can really be needed, to develop and support different build tools (in particular, make sure they are build before you use them, all build technologies are about it: dependencies, time stamps, declarative definitions used by build and automatically determined order of operations). You can have master projects which can have projects as their members, but, alternatively, other solutions, which can be useful for having separately developed layers.
I must note that many incorrectly evaluate the roles and possibilities related to solution. First of all, you need to have some one-click build of everything, iterative and complete re-build. Also, you need a mechanism for version increments, deployment, and more. It's important not to mix it all together. For this purposes, a solution can work, but it could also be some master project. It's just important to have one single batch for all components of the project for each of such operations.
But this is not the only role of solution. The solution could also be a developer's entity, which is a point of view at the set of project (which should be a complete sub-set, in terms of ability to build it all, not depending on missing components.) You can have separate solutions just to allow some developer to work at the part of the product, not seeing other projects. On some other stage of development, this solution can be set aside and other solution created. So, you may want to have two different classes of solutions: partial solutions used for development, and the solutions used for total build. You will decide if it should be only one solution, or a set of solutions united by some master project. Your goal is to make sure you have one global product build as on-click artifact.
And finally, you need to develop most important part of the strategy: the ability to post-pone the decision. Good architecture is not the one which is based only good correct decisions. Really good architecture is the one where you can post-pone the decisions and fix your bad decision at lower costs. Don't decide how you structure your growing product for better manageability now. Don' go this way. Instead, sketch the strategy which allows you to make those decisions later, when you can better see the ways the product and your projects grow. Isn't that logical?
—SA
Submit an article or tip