Debug performance terrible

[tonywr71]

I am currently debugging a reasonably substantial and complex angular-cli application in the dot net core environment on a corporate Windows 7 desktop. I have Visual Studio 2017 Professional 15.7.4 installed. I used the latest JavaSciptServices Angular template, and upgraded it to Angular 6.

I run my application and my first run at this took about 40 seconds for an application to update after a change (hot module replacement, IIS Express). So I thought that's no good, and looked up lots of docs and found I could bypass the local server and use node, using the following document: Use the Angular project template with ASP.NET Core

Essentially, I have overridden the spa.UseAngularCliServer(npmScript: "start") statement and execute spa.UseProxyToSpaDevelopmentServer("http://localhost:4200"); instead and on the command line in the ClientApp folder, I execute npm start, which proxies the dev server to node. This is supposed to speed things up, and while the compilation itself seems a lot faster, it seems to take forever to download the script files to the browser client.

I do have plenty of modules, probably about 15. Many of these modules seem to get stuck downloading. Chrome says they are pending, and sometimes they arrive, but sometimes they don't. This is the latest version of Chrome. We also have access to IE11 and FireFox, but Chrome is the debugger of choice because it is the only one guaranteed to be up to date.

I'm pretty sure things shouldn't be this slow, with the app getting caught on downloading module scripts. I am using configuration provided in the new angular.json file.

"configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }

Any ideas what I might be doing wrong?

[tonywr71]

Ok, I should add that it is an ASP.NET Core app running on Dot Net Framework - I selected Dot Net Framework from the dropdown when I chose the Angular template so that I could use legacy framework projects.

[tonywr71]

Ok, I've started with two new angular template apps, one is a pure dot net core app and the other a dot net framework app. I ran them both, and in each one I went to the fetch data page. I modified the text in the heading in each one and then hit save. The dot net core one consistently takes about 5 seconds to reload. The dot net framework one takes around 45 seconds to reload. So it turns out that its to do with dot net framework.

The reason dot net framework is being used is to gain access to the entity framework designer, which obviously isn't available in dot net core. There is a fair bit of legacy code associated with the entity framework designer.

But I now think that I'm going to need to have to move to a pure dot net core app. That's going to be painful. Unless someone's got a better idea?

[tonywr71]

Well, it turns out dot net core still has problems of its own. It doesn't support types that are needed, such as Spatial types DbGeometry and DbGeography, which I need for maps that I render using Leaflet on Angular. So it looks like I have to fight the Full Dot Net Framework for now and accept low productivity.

[tonywr71]

For anyone that's interested, I have done a full conversion from dot net framework to dot net core. The performance is significantly better, I would suggest somewhere between 9 and 15 times faster, which I attribute directly to dot net core. That means that instead of making a small change in VS then saving, then waiting 45 seconds to a minute for a screen to hot module replace, I now only wait 3 to 5 seconds, and this is a substantial application. I am now able to be productive again.

That said, under the old pre angular-cli template, I was still productive, so perhaps if you're on the old template you should stay there if you are using dot net framework. I don't recommend the new template for dot net framework apps. Once I had moved to angular-cli, I really had little choice and had to keep pushing forward until my entire app was upgraded to dot net core.

I was able to find dot net core alternatives for everything that was previously dot net framework, but I did need to use some pre-release packages to get everything working. I was able to come up with an alternative solution to the Spatial types mentioned above, using NetTopologySuite.IO.GeoJson and a column conversion method in the database context (new feature as of entity framework core 2.1) to convert wkb database fields to geojson.

My application had services, and I was using TopShelf. I was unable to use TopShelf as TopShelf for DotNetCore haven't figured out how to install as a service. I found a dot net core alternative, PetterKottas.DotNetCore.WindowsService, which works pretty much the same way, but installs the service as well. SignalR works brilliantly. I was also able to get Hangfire working properly in dot net core. I was creating DocX documents and found a DocXCore packages to replace it.

I converted all my Sql Server EF designer objects to EF Core. There is a course on pluralsight that helps. I used the scaffolding to generate the EF classes and context. Oracle was a bit trickier as out of the box they don't have much dot net core support in their provider, but luckily for me I don't have to do very much with Oracle in that application, otherwise I probably would have gone out and purchased DevArts EF designer (which is an option if you would rather stick with database first for significant existing databases).

Bottom line is that if you want to get your productivity back after updating to the new javascript services template that uses angular-cli, then this appears to be a viable path.