.net – “Error 0x800713ec – Asia” when Installing .NET Framework 4.7.2 targeting pack

I downloaded and tried to install the .NET Framework 4.7.2 Targeting Pack. When the downloaded installer runs it produces this error for unknown reasons:

Note that I am in the USA and have not downloaded an Asia-specific installer (AFAIK), so that part of the error makes no sense to me. The computer I'm installing on has unmodified English / US settings. It is running Windows 7 in a virtual machine.

The first lines of the log file which appear to show errors are:

[11C8:0AB4][2018-12-11T07:27:41]e000: Error 0x800713ec: Process returned error: 0x13ec
[11C8:0AB4][2018-12-11T07:27:41]e000: Error 0x800713ec: Failed to execute EXE package.
[1228:1730][2018-12-11T07:27:41]e000: Error 0x800713ec: Failed to configure per-machine EXE package.
I've found a similar posting on a MSFT forum but without any solution:
https://developercommunity.visualstudio.com/content/problem/367071/microsoft-net-framework-472-developer-pack-install.html
There are also some other failures installing other things with similar errors:
https://github.com/patrickmoore/Mu/issues/7
visual studio 2013 error on installation microsoft.net framework 4.51
But no definitive solution that I can see.
Thanks
The problem was: not enough disk space. 
The disk wasn't full but was running low, so I made some room and then it installed OK.
I inferred this from reading about other similar errors, though none specific to .NET framework components. Therefore this is probably the cause of many cases of “Error 0x800713ec - Asia" even in other circumstances.
I have no idea why such a meaningless error is used, or why the logs are so unclear as well.
Related Solutions
C# – How is Math.Pow() implemented in .NET Framework

MethodImplOptions.InternalCall
That means that the method is actually implemented in the CLR, written in C++. The just-in-time compiler consults a table with internally implemented methods and compiles the call to the C++ function directly.
Having a look at the code requires the source code for the CLR. You can get that from the SSCLI20 distribution. It was written around the .NET 2.0 time frame, I've found the low-level implementations, like Math.Pow() to be still largely accurate for later versions of the CLR.
The lookup table is located in clr/src/vm/ecall.cpp. The section that's relevant to Math.Pow() looks like this:
FCFuncStart(gMathFuncs)
    FCIntrinsic("Sin", COMDouble::Sin, CORINFO_INTRINSIC_Sin)
    FCIntrinsic("Cos", COMDouble::Cos, CORINFO_INTRINSIC_Cos)
    FCIntrinsic("Sqrt", COMDouble::Sqrt, CORINFO_INTRINSIC_Sqrt)
    FCIntrinsic("Round", COMDouble::Round, CORINFO_INTRINSIC_Round)
    FCIntrinsicSig("Abs", &gsig_SM_Flt_RetFlt, COMDouble::AbsFlt, CORINFO_INTRINSIC_Abs)
    FCIntrinsicSig("Abs", &gsig_SM_Dbl_RetDbl, COMDouble::AbsDbl, CORINFO_INTRINSIC_Abs)
    FCFuncElement("Exp", COMDouble::Exp)
    FCFuncElement("Pow", COMDouble::Pow)
    // etc..
FCFuncEnd()
Searching for "COMDouble" takes you to clr/src/classlibnative/float/comfloat.cpp. I'll spare you the code, just have a look for yourself. It basically checks for corner cases, then calls the CRT's version of pow().
The only other implementation detail that's interesting is the FCIntrinsic macro in the table. That's a hint that the jitter may implement the function as an intrinsic. In other words, substitute the function call with a floating point machine code instruction. Which is not the case for Pow(), there is no FPU instruction for it. But certainly for the other simple operations. Notable is that this can make floating point math in C# substantially faster than the same code in C++, check this answer for the reason why.
By the way, the source code for the CRT is also available if you have the full version of Visual Studio vc/crt/src directory. You'll hit the wall on pow() though, Microsoft purchased that code from Intel. Doing a better job than the Intel engineers is unlikely.  Although my high-school book's identity was twice as fast when I tried it:
public static double FasterPow(double x, double y) {
    return Math.Exp(y * Math.Log(x));
But not a true substitute because it accumulates error from 3 floating point operations and doesn't deal with the weirdo domain problems that Pow() has.  Like 0^0 and -Infinity raised to any power.
    
.net – What’s the difference between .NET Core, .NET Framework, and Xamarin

You should use .NET Core, instead of .NET Framework or Xamarin, in the following 6 typical scenarios according to the documentation here.
1. Cross-Platform needs
Clearly, if your goal is to have an application (web/service) that should be able to run across platforms (Windows, Linux and MacOS), the best choice in the .NET ecosystem is to use .NET Core as its runtime (CoreCLR) and libraries are cross-platform. The other choice is to use the Mono Project.
Both choices are open source, but .NET Core is directly and officially supported by Microsoft and will have a heavy investment moving forward.
When using .NET Core across platforms, the best development experience exists on Windows with the Visual Studio IDE which supports many productivity features including project management, debugging, source control, refactoring, rich editing including Intellisense, testing and much more. But rich development is also supported using Visual Studio Code on Mac, Linux and Windows including intellisense and debugging. Even third party editors like Sublime, Emacs, VI and more work well and can get editor intellisense using the open source Omnisharp project.
2. Microservices
When you are building a microservices oriented system composed of multiple independent, dynamically scalable, stateful or stateless microservices, the great advantage that you have here is that you can use different technologies/frameworks/languages at a microservice level. That allows you to use the best approach and technology per micro areas in your system, so if you want to build very performant and scalable microservices, you should use .NET Core. Eventually, if you need to use any .NET Framework library that is not compatible with .NET Core, there’s no issue, you can build that microservice with the .NET Framework and in the future you might be able to substitute it with the .NET Core.
The infrastructure platform you could use are many. Ideally, for large and complex microservice systems, you should use Azure Service Fabric. But for stateless microservices you can also use other products like Azure App Service or Azure Functions.
Note that as of June 2016, not every technology within Azure supports the .NET Core, but .NET Core support in Azure will be increasing dramatically now that .NET Core is RTM released.
3. Best performant and scalable systems
When your system needs the best possible performance and scalability so you get the best responsiveness no matter how many users you have, then is where .NET Core and ASP.NET Core really shine. The more you can do with the same amount of infrastructure/hardware, the richer the experience you’ll have for your end users – at a lower cost.
The days of Moore’s law performance improvements for single CPUs does not apply anymore; yet you need to do more while your system is growing and need higher scalability and performance for everyday’ s more demanding users which are growing exponentially in numbers. You need to get more efficient, optimize everywhere, and scale better across clusters of machines, VMs and CPU cores, ultimately. It is not just a matter of user’s satisfaction; it can also make a huge difference in cost/TCO. This is why it is important to strive for performance and scalability.
As mentioned, if you can isolate small pieces of your system as microservices or any other loosely-coupled approach, it’ll be better as you’ll be able to not just evolve each small piece/microservice independently and have a better long-term agility and maintenance, but also you’ll be able to use any other technology at a microservice level if what you need to do is not compatible with .NET Core. And eventually you’d be able to refactor it and bring it to .NET Core when possible.
4. Command line style development for Mac, Linux or Windows.
This approach is optional when using .NET Core. You can also use the full Visual Studio IDE, of course. But if you are a developer that wants to develop with lightweight editors and heavy use of command line, .NET Core is designed for CLI. It provides simple command line tools available on all supported platforms, enabling developers to build and test applications with a minimal installation on developer, lab or production machines. Editors like Visual Studio Code use the same command line tools for their development experiences. And IDE’s like Visual Studio use the same CLI tools but hide them behind a rich IDE experience. Developers can now choose the level they want to interact with the tool chain from CLI to editor to IDE.
5. Need side by side of .NET versions per application level.
If you want to be able to install applications with dependencies on different versions of frameworks in .NET, you need to use .NET Core which provides 100% side-by side as explained previously in this document.
6. Windows 10 UWP .NET apps.
In addition, you may also want to read:
When should I NOT use .NET Core?
When should I still use .NET Framework 4.x, instead of .NET Core?
When should I use Xamarin, instead of .NET Core?