As to your original question, here's some info from the soon to be defunct What's the difference between an .fx and .hlsl file anyhow?
Historically the extension '.fx' refers to a HLSL shader intended to be built using the legacy effects fx_4_0, fx_5_0, etc. profiles; while '.hlsl' refers to individual HLSL shaders. The reality is that there's no consistency here. You will see lots of '.fx' files without any technique/pass statements.
Unlike C/C++ source files, HLSL files can contain a lot of stuff that gets ignored in a given invocation of the compiler. If you have a big .fx file with a dozen shaders in it and a bunch of technique/passes, you can compile the same file many times with different entry-points and profiles to generate lots of shaders.
It's really all a matter of how you want to build your shader content. For example, DirectX Tool Kit uses a command-line script to build all the possible combinations of shaders: currrently it builds 86 shader blobs from 7 .fx files (and actually it can build them twice: once with the Windows compiler and once with the Xbox One XDK compiler, but only one set of these shader blobs is included in a given build of the DirectXTK.lib anyhow).
If you use the Visual Studio 2012/2013 content pipeline to build your shaders, you do have to deal with a limitation of MSBuild which assumes each source file is built once for each result. So in that case, you'd want an individual '.hlsl' file for each shader combination (which for the DirectX Tool Kit example would mean 86 '.hlsl' files). One way to handle this would be to keep the shader source itself in a single file, and then have a bunch of .hlsl files that #include the 'source' file. Something like:
BasicEffectVSBasicVertexLighting.hlsl
#include "BasicEffect.fx"
BasicEffectPSBasicVertexLighting.hlsl
#include "BasicEffect.fx"
You then compile each of these .hlsl files once with the proper shader profile and entry-point. This approach works fine for smaller projects, but doesn't scale well to large complex shaders without using legacy fx profiles. In that case, other build solutions like DirectX Tool Kit's build solution is probably better.
If you are using legacy fx profiles, you of course only have to compile each .fx once and it will generate all the shaders it specifies in technique/passes in one go.
> Frank Luna's Direct3D 11 book is a victim of its timing. It was published just prior to the legacy DirectX SDK being [deprecated](https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275.aspx). The basics of the book are great, but FX11, D3DX11, and XNAMath all have replacements that avoid using the legacy DirectX SDK. See [Living without D3DX](https://blogs.msdn.microsoft.com/chuckw/2013/08/20/living-without-d3dx/), [Introducing DirectXMath](https://blogs.msdn.microsoft.com/chuckw/2012/03/26/introducing-directxmath/), and [Book Recommendations](https://blogs.msdn.microsoft.com/chuckw/2014/04/07/book-recommendations/) 
