Fix frameworks in runtime store doc

[dasMulli]

• Removes net47 directory.
  • .NET Framework doesn't support runtime stores and the dotnet store tooling couldn't create one anyway
• Fixes the dotnet store example with valid arguments
  • netstandard2.0 is invalid as it cannot restore a CoreCLR but netcoreapp2.0 does

also see https://github.com/dotnet/cli/issues/7481#issuecomment-323591328

cc @mairaw @guardrex

[dnfclas]

@dasMulli,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

[guardrex]

It prob needs a bit more to clarify/fix a few problems ...

The store layout section was created during preview. IIRC the net47 folders were in there on my local machine (the store at c:\Program Files\dotnet\store). It might have been from a phase of preview development (i.e., placed there in ancient package store feature churn ... possibly even from a bug in a passing preview) ... or it might have truly just been my mistake. We didn't get dev team review on that PR ... cough cough [@]DamianEdwards cough lol 😄 ... #2496

The other thing is that it probably isn't enough to merely change the option's value. Since the option is for a "target framework" and "netstandard2.0" is a target framework, it will have to say more about what qualifies as a "target framework" for the option's value ... both in this topic and over in https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-store.

[EDIT] Must interject the bit about the "hang" that isn't really a hang ... just a monster delay depending on where the package manifest file is. Even placing it into the Documents folder is a BAD move.

... then there's the issue of the artifacts.xml file example shown in the topic (working on that at #2938). Should the file's contents be shown exactly as it's created on disk today like this ...

<StoreArtifacts>
   <Package Id="newtonsoft.json"  Version ="10.0.3"/>
   <Package Id="castle.core"  Version ="4.1.0"/>
   <Package Id="moq"  Version ="4.7.63"/>
</StoreArtifacts>

... or go with the 🌹 File Beautification 🌷 version that has the human-friendly package names (coming soon to a CLI near you thanks to @dasMulli, dotnet/sdk#1487) thus ...

<StoreArtifacts>
  <Package Id="Newtonsoft.Json" Version="10.0.3" />
  <Package Id="Castle.Core" Version="4.1.0" />
  <Package Id="Moq" Version="4.7.63" />
</StoreArtifacts>

The changes are significant enough that I recommend closing both of the patch PR's, opening a proper issue to cover the changes, and then proceeding with a proper branched fix-up spanning these two topics. @mairaw let me know which way u want to go and if u want me to take care of it.

[mairaw]

You lost me a bit @guardrex. Especially because you're probably the most knowledgable about those topics. Can you summarize what are your suggestions?

Getting dev review has been hard this month with a lot of folks away.

[guardrex]

There are four things to address/consider:

1. Remove net47 from the example of the store layout.
2. Change the target framework option to netcoreapp2.0.
3. "The Hang" ... that isn't a hang ... just an insanely long delay when you try to put the manifest file in a location that MSBuild must traverse completely looking for things to compile.
4. The artifacts.xml file layout is broken (looking). It works, it just doesn't look good.

Thoughts:

1. That's easy to fix. This PR takes care of it.
2. It probably isn't enough to merely change the option's value as this PR does. Since the option is for a "target framework" and "netstandard2.0" is a target framework, it should say more about what qualifies as a "target framework" for the option's value. [There's an additional minor update/addition for --framework-version ... it refers to the runtime framework version.]
3. "The Hang" should probably be explained. A dev has to be careful where they put the file or they may suffer a delay so long that they'll think the CLI has eaten itself. The dev side of the problem was lightly discussed (i.e., passing EnableDefaultItems=false to MSBuild); however, I don't see any action to fix it. The topic should say something like 'be careful where you put the manifest file because ...'
4. artifacts.xml file: You'll still have to decide if you go with (a) what the file actually looks like ("super embarrassing" lol 😀), (b) a hybrid (what I did in the topic ... fixed the spacing but left the packages all lowercase), or (c) clean it up to how it will look post Change xml formatting for store artifacts xml sdk#1487 (what that patch PR does).

I'm not sure what the best approach is to take. Since all of these issues overlap in the same topic (or two), I floated the idea that both of the patch PR's (this one and the one I created) be closed in favor of a proper (complete) set of changes. However, I'm busy atm with a new large project, so I wouldn't be able to handle the work.

[mairaw]

Not asking you to do the work @guardrex just trying to understand your suggestions. Thanks for clarifying it. I think it's fine to leave this PR and then address the other issues on a different one. You know I'm a fan of breaking things down to smaller pieces. 😉

[dasMulli]

@mairaw any plans yet? while the framework thing has been fixed by @guardrex in #3188 (after we talked about it on slack again), the net47 entries still need to be removed..

[mairaw]

LGTM. Thanks @dasMulli. And again, apologies for the delay reviewing this one. This will go live with our next push to production that is running right now.