Chapter 11: Publish WorldCities Fails at webpack.Progress 95% elifecycle of ng build --prod about asp.net-core-3-and-angular-9-third-edition

[Darkseal]

Hello there,
sorry for the late reply.

First of all, thank you for purchasing the book: I'm glad you've managed to like it despite the hours you've lost to make some of my examples to actually work.

Regarding the "dll hell" issue you're having, I honestly don't know what could have gone wrong: occasionally I also run into such problems but fortunately I can always solve in a few minutes using the visual studio tools (Clear Project and so on) and/or getting back the project from scratch from my GitHub's latest pull. I think that the best thing you can do is to get a "working version" of Chapter 11 by getting it from the book's GitHub repo and then try to replace the json, cs, ts and html files until you get the one that's messing things around (it might be the angular.json file or other configuration files). I agree with you that these configuration issues are a nightmare and that they can easily cripple the whole programming experience of anyone who doesn't have the experience and/or the "StackOverflow grinding" patience required to eventually overcome them.

Regarding the "Broken Code Myth" issue, I think you may have misunderstood the concept I wanted to express in that paragraph. The fact that the book may contain typo or errors is practically inevitable: the myth I'm talking about is not the presence of errors, but the fact that they can seriously compromise the programming experience. From February to September we received over 50 bug reports, which I have personally reviewed: 99% of these were objectively insignificant in terms of understanding the code and could be easily solved by any developer just by observing the intellisense suggestions and acting accordingly: moreover, a huge number of them were not even present in the GitHub code, which I've struggled to keep updated and 100% build-capable with the given set of tools. Don't get me wrong, I do realize that in some edge-case scenarios these errors can lead the readers astray and make them waste a lot of time, especially if they don't check the GitHub code everytime something seems odd (general rule: whenever it doesn't compile or doesn't work as expected, it's definitely odd). At the same time, I am 100% convinced that exaggerating those inevitable typos and talking about "hours wasted trying to make a broken code to actually work" is a myth that needs to be defeated, especially when we talk about "differences between the book's text and the downloadable project code". The Broken Code Myth paragraph literally says what to do in this circumstance: Is the book's GitHub repository also affected by this issue? Did I try to compare it with my own code, possibly replacing mine? That said, if you think I'm wrong in saying this, I'll be more than happy to discuss a couple of issues you've had with the book source code and how they took hours to get fixed because of typos or missing bits.

As for the SeedController's Import() method, you're definitely right: there is no reason to trigger the DB save upon each iteration, you can do that at the end of each for cycle. I've just released on GitHub a patched version of that method that calls the context's SaveChangesAsync() method a maximum of two times (only if there is at least a new country or city to add). This can be done ever more efficiently using a single call near the end, but I do prefer to have different calls for countries and cities. While I was there, I took the chance to keep track of the existing cities too, so that multiple calls on the Import() method won't have the effect of adding duplicate cities on the DB. Hope you'll like it :)