Webpack Live Reloading broke when I moved from .NET 3.1 to .NET 5.0.1 - Project debugging with VS 2019 16.8, using Angular 10

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work] [regression] [worked-in:.NET Core 3.1]
After updating my back-end from .NET Core 3.1 to .NET 5.0.1 the live reloading stopped working.

• On Chrome I get a warning, and the associated log is found on the attachment:
  [localhost-1610379736782.log] (https://aka.ms/dc/file?name=Bc4efe358f6884403abd062a70e07aaa7637465801565279718_localhost-1610379736782.log&tid=c4efe358f6884403abd062a70e07aaa7637465801565279718)

• On Edge Chromium I get a warning too with this log:
  [localhost-1610983218905.log] (https://aka.ms/dc/file?name=Bab8491d5c0e349c798902a8ff26dcdcd637465801908236518_localhost-1610983218905.log&tid=ab8491d5c0e349c798902a8ff26dcdcd637465801908236518)

• On Firefox it fails most of the times (curiously not always, it maybe works 10% of the times) with two consecutive error logs:
  -- Firefox can’t establish a connection to the server at wss://localhost:44379/sockjs-node/452/wjbarfbd/websocket. sockjs.js:1684
  -- The connection to wss://localhost:44379/sockjs-node/452/wjbarfbd/websocket was interrupted while the page was loading.

---

Original Comments

Feedback Bot on 1/19/2021, 11:04 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

(no solutions)

[mkArtakMSFT]

Thanks for contacting us.
Integration with WebPack has been deprecated in .NET Core 3.1 and has been removed in.NET 5. You can learn more about this change from the announcement post.

[jlquijada]

No, this is not solved. This answer does not apply to my project. If this was the case, I believe I would get some warnings while building the project, or even I would not be able to run it altogether.

I already was using the instructions in https://docs.microsoft.com/en-us/aspnet/core/client-side/spa/angular?view=aspnetcore-5.0&tabs=visual-studio

On the referenced post about the obsolesced packages says at the end:

The functionality in Microsoft.AspNetCore.SpaServices.Extensions is not obsolete and will continue to be supported.

My Startup.cs file has:
using Microsoft.AspNetCore.SpaServices.AngularCli;

and in
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)

I initialize the Spa like instructed on the page (actually it was generated by the command dotnet new angular -o my-new-app):

            app.UseSpa(spa =>
            {
                // To learn more about options for serving an Angular SPA from ASP.NET Core,
                // see https://go.microsoft.com/fwlink/?linkid=864501
                
                spa.Options.SourcePath = "ClientApp";

                if (env.IsDevelopment())
                {
                    spa.UseAngularCliServer(npmScript: "start");
                }
            });

And the Live Reloading of the front-end on changes to the source code of the Angular-part is still not working after the migration to the .net 5.0.1. It was working when I had my project in .net Core 3.1

So, please, analyze it a bit deeper, I'm sure many VS2019+.NET+Angular developers will benefit from this.

And if you still think this is the way to solve this issue, maybe updating the Microsoft knowledge base articles for .Net 5 would help.

[captainsafia]

@jlquijada Can you try some of the recommendations in this thread to see if they resolve the issue?

#27790

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[erictor]

@captainsafia Hi, #27990 was the issue that lead to this issue (#29478) being created. If you scroll to the bottom you'll see the comments that lead to https://developercommunity2.visualstudio.com/t/Webpack-Live-Reloading-broke-when-I-move/1313178 being opened -- and that was closed and this issue #29478 was opened in its place.

[captainsafia]

@erictor Ah, I see. Thanks for clarifying. In that case, if anyone can share a repro project/repro steps that would help with investigation.

[erictor]

GitHubIssue29478.zip

@captainsafia This zip is of a Microsoft default/starter .NET Core 5 + Angular SPA app, created with the dotnet new command https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-new#spa you'll need to do the npm install to bring in all the npm dependencies, and you should be able to load the solution in VS 2019, build it, and then browse to it with View In Browser (Ctrl+Shift+W).

You'll see in package.json that it's creating an Angular 8 app (when I last ran dotnet new to create the sample, that's what it did), but if you test it as-is and see the issue, and then update it to the latest Angular (11), I believe you will still see the issue. It's occurring on other apps for @jlquijada (Angular 10) and for me (Angular 11). The common factor appears to be moving from .NET Core 3.1 to .NET 5.

F12 dev tools should show this error:

Each time you F5 reload the browser (or almost every time) you should see the error recur. This error has the impact of preventing Live Reload from functioning. After the error occurs, despite the fact that otherwise WebPack would automatically reload the javascript/HTML in the browser, updating a file will not result in the auto-reload.

Thanks.

[mattheiler]

I was also able to reproduce this issue with the Microsoft default/starter .NET Core 5 + Angular SPA app. That project uses Angular 8, as @erictor mentioned, so this does seem specific to net5.0, not Angular 10 or 11 like the title may suggest.

[captainsafia]

@mattheiler Thanks! Having this repro helps clarify the different issues reported across the two (three?) threads. I'm able to reproduce this on 5.0.0. I'll see if #27799 helps address the issue with Angular 8. Generally, we try to address the issues that come with the Angular version that the templates ship with and not others, hence the need to narrow down the repro to Angular 8 here.

[erictor]

Hi @captainsafia! May I ask if you've had a chance to review the "Websocket is closed before the connection is established" error? Thank you.

[jlquijada]

Finally I have updated my project also to Angular 11.1.3. Nothing changed regarding this problem, until I run this command manually:

ng update @nguniversal/aspnetcore-engine

This upgraded the package (dependency) to "@nguniversal/aspnetcore-engine": "^11.1.1",

I was all happy, because it seemed to work again (after starting the debugging session on VS2019), but after a number of auto-refreshes, it stopped working again. The only solution is to restart the debugging session on VS2019.

Also, in case you press F5, or Ctrl+F5 on the web browser, or you open the site on another browser, it stops auto-refreshing.

So, something changed, but still is not working as before.

[captainsafia]

Took a look at this today. I hadn't been able to reproduce via dotnet run on a new Angular project created via dotnet new or in the project shared in #29478 (comment) on macOS.

However, it repros on Windows across both VS/CLI and IIS/Kestrel. This issue is not a dupe of #27790 because it appears to affect web apps launched without SSL as well so the PR referenced above won't solve the issue here.

I notice that a couple of the comments in this thread reference different versions of Angular (our templates ship and support 8 by default) and include some dependencies we don't have in the template by default (@nguniversal/aspnetcore-engine). I'm not sure how these affect this scenario but for now I believe the investigation should focus on issues in the default template created via dotnet new.

[erictor]

@captainsafia thanks so much for keeping this issue and investigation open. Thanks for checking Windows and finding that the issue repros in Windows. I've been developing in Windows; also, in the projects I've been working with where this issue occurs, (including the zipped version of the default '.net new' template) the dependency @nguniversal/aspnetcore-engine is not present. Therefore I feel it's safe to say that that dependency is not an necessary element re: the presence of the "Websocket is closed before the connection is established" error.

[captainsafia]

Therefore I feel it's safe to say that that dependency is not an necessary element re: the presence of the "Websocket is closed before the connection is established" error.

Agreed -- I was making the point that my investigation focused primarily on the default template scenario.

[erictor]

Putting this out there in case somehow it helps a bit with trying to figure this one out. Today this displayed my Dev Tools Console:

I clicked on the links displayed in the Dev Tools Console for polyfills.js Lines 15841 and 15868 and the code opened up in my browser (I've been using Chrome).

15799  var utils = require('../utils/event')
15800  , urlUtils = require('../utils/url')
15801  , inherits = require('inherits')
15802  , EventEmitter = require('events').EventEmitter
15803  , WebsocketDriver = require('./driver/websocket')
15804  ;
15805  
15806  var debug = function() {};
15807  if (process.env.NODE_ENV !== 'production') {
15808    debug = require('debug')('sockjs-client:websocket');
15809  }
15810  
15811  function WebSocketTransport(transUrl, ignore, options) {
15812    if (!WebSocketTransport.enabled()) {
15813      throw new Error('Transport created when disabled');
15814    }
15815  
15816    EventEmitter.call(this);
15817    debug('constructor', transUrl);
15818  
15819    var self = this;
15820    var url = urlUtils.addPath(transUrl, '/websocket');
15821    if (url.slice(0, 5) === 'https') {
15822      url = 'wss' + url.slice(5);
15823    } else {
15824      url = 'ws' + url.slice(4);
15825    }
15826    this.url = url;
15827  
15828    this.ws = new WebsocketDriver(this.url, [], options);
15829    this.ws.onmessage = function(e) {
15830      debug('message event', e.data);
15831      self.emit('message', e.data);
15832    };
15833    // Firefox has an interesting bug. If a websocket connection is
15834    // created after onunload, it stays alive even when user
15835    // navigates away from the page. In such situation let's lie -
15836    // let's not open the ws connection at all. See:
15837    // https://github.com/sockjs/sockjs-client/issues/28
15838    // https://bugzilla.mozilla.org/show_bug.cgi?id=696085
15839    this.unloadRef = utils.unloadAdd(function() {
15840      debug('unload');
15841      self.ws.close();
15842    });
15843    this.ws.onclose = function(e) {
15844      debug('close event', e.code, e.reason);
15845      self.emit('close', e.code, e.reason);
15846      self._cleanup();
15847    };
15848    this.ws.onerror = function(e) {
15849      debug('error event', e);
15850      self.emit('close', 1006, 'WebSocket connection broken');
15851      self._cleanup();
15852    };
15853  }
15854  
15855  inherits(WebSocketTransport, EventEmitter);
15856  
15857  WebSocketTransport.prototype.send = function(data) {
15858    var msg = '[' + data + ']';
15859    debug('send', msg);
15860    this.ws.send(msg);
15861  };
15862  
15863  WebSocketTransport.prototype.close = function() {
15864    debug('close');
15865    var ws = this.ws;
15866    this._cleanup();
15867    if (ws) {
15868      ws.close();
15869    }
15870  };
15871  
15872  WebSocketTransport.prototype._cleanup = function() {
15873    debug('_cleanup');
15874    var ws = this.ws;
15875    if (ws) {
15876      ws.onmessage = ws.onclose = ws.onerror = null;
15877    }
15878    utils.unloadDel(this.unloadRef);
15879    this.unloadRef = this.ws = null;
15880    this.removeAllListeners();
15881  };

I thought it was interesting that the websocket close at one of the reported errors, Line 15841, appears right after comments that say: "In such situation let's lie - let's not open the ws connection at all."

I see that polyfills.js is built dynamically from pulling in code from various areas within node_modules, so I copied out the section that began with the comment: !*** ./node_modules/sockjs-client/dist/sockjs.js ***! and I've pasted it here as an attached file. Line 15841 from above is Line 2981 in this attached file. Line 15868 from above is Line 3008 in the attached file.

node_modules-sockjs-client-dist-sockjs.js.txt

I realize that focusing on sockjs.js, where the error is surfacing, doesn't really get to the question of why moving to the more recent version of .NET framework seems to result in the error occurring.

[dylanvdmerwe]

Coming from .Net Core 3 to .Net 5 has caused this issue as well for any angular sites we run. Maybe like 5% of the time the websocket connects and live reload works now.

[pablo-daza-incontact]

JFYI: I fixed the live reload socket warning adding the public host option in the angular.json file for angular 11.2. Now it works using SSL on asp .net core

"serve": { "builder": "@angular-devkit/build-angular:dev-server", "options": { "browserTarget": "AngularTemplate:build", "publicHost": "localhost:5001" }, "configurations": { "production": { "browserTarget": "AngularTemplate:build:production" } } }

[nakah]

Having the issue after updating to .Net 5, so I had to rollback to .Net Core 3.1.
Any progress on this issue ?

[captainsafia]

@nakah No progress yet outside of the investigation mentioned earlier. This issue is in the backlog at the moment as we've prioritized other items for .NET 6.

PRs are definitely welcome for this for folks who are interested in helping out.

[erictor]

Thank you for the status update @captainsafia.

[User00015]

I also just ran into this issue as well and decided to do some digging.

At sockjs.js:822 there is this line
var timeoutMs = Math.max(this._timeout, (this._rto * Transport.roundTrips) || 5000);

this._rto = 366 and Transport.roundTrips = 2, resulting in a timeoutMs of 644

According to the comment above that line, the default is supposed to be 5 seconds. If I manually modify the timeout to 5000, Live Reloading correctly enables for the remainder of the session. Is this a race condition issue with the timeout being set to low?

I also am able to manually connect a web socket to the server and successfully see reload updates

ws = new WebSocket("ws://localhost:53264/sockjs-node/828/veobws02/websocket"); 
        
// Then you can send a message

//Log the messages that are returned from the server
ws.onmessage = function (e) {
console.log("From Server", e);
};

ƒ (e) {
console.log("From Server", e);
}
VM1324:7 From Server MessageEvent {isTrusted: true, data: "o", origin: "ws://localhost:53264", lastEventId: "", source: null, …}
VM1324:7 From Server MessageEvent {isTrusted: true, data: "a["{\"type\":\"liveReload\"}"]", origin: "ws://localhost:53264", lastEventId: "", source: null, …}
VM1324:7 From Server MessageEvent {isTrusted: true, data: "a["{\"type\":\"overlay\",\"data\":{\"errors\":true,\"warnings\":false}}"]", origin: "ws://localhost:53264", lastEventId: "", source: null, …}
VM1324:7 From Server MessageEvent {isTrusted: true, data: "a["{\"type\":\"hash\",\"data\":\"1feae9ceb39ba2ff5ab8\"}"]", origin: "ws://localhost:53264", lastEventId: "", source: null, …}
VM1324:7 From Server MessageEvent {isTrusted: true, data: "a["{\"type\":\"ok\"}"]", origin: "ws://localhost:53264", lastEventId: "", source: null, …}

Note: I am using the default template provided in VS2019 like previous commenters have used.

[erictor]

Thank you for doing that research, @User00015. At https://github.com/sockjs/sockjs-client/blob/master/dist/sockjs.js the line you are referring to is line 825. I wonder if devs working that project are familiar with that line, the logic behind the calculation and whether that piece of code has seen any changes.

Most of the devs impacted by the Issue described here #29478, didn't see this issue until they moved from .NET Core 3.1 to .NET 5. And the issue goes away if they revert back from .NET 5 to .NET Core 3.1. If you're able to revert back to .NET Core 3.1 as a test it would be interesting to see what the behavior is.

Then the question is why does .NET 5 interact with that sockjs logic in a negative fashion but .NET Core 3.1 does not.

[User00015]

That line did see changes, but the original PR was merged in 2019. You can see the issue that called for it here #413 which is because of a reported issue here #403 which sounds rather familiar to our issue. More notably, this change was to include a new timeout argument that can be passed in, but I wasn't able to find a way of passing in that new argument. Maybe someone more experienced knows how to pass options down through the application to sockJS and seeing if a default timeout set to a non-zero number helps (default in this case is 0, which causes the round time calculation to fire instead which is how we're getting a timeout ms of 644 for my personal machine and 698 in the case of the original reporter)

I couldn't hazard a guess as to why this issue disappears when returning to .NET 3.1, as I can manually open a websocket connection to .NET 5 without issue as I showed earlier. I don't know enough about how .NET integrates with things like sockjs and whether .NET 5 uses a different version or not compared to .NET 3.1, so I guess that's one question: Does rolling back to .NET 3.1 revert sockjs to a previous version as well? Possibly to a version before the default timeout is set to 0 if no option is passed in?

[mattywong]

Recently encountered this issue with a custom webpack configuration for a React app on Windows. For now, our solution to this problem was by changing the webpack dev server transportMode option to use native web sockets instead of sockjs (which is the default (https://webpack.js.org/configuration/dev-server/#devservertransportmode)). This probably isn't an ideal solution for this specific bug repro using the Angular spa template as it seems you are at the mercy of angular cli still, though this may help some others resolve this issue (that may or may not be using Angular), and/or have access to the underlying webpack configurations. I looked in to angular cli docs, and it didn't seem there was a way to pass through dev server options via ng serve.

My understanding of this problem is that the UseProxyToSpaDevelopmentServer just takes too long to proxy the sockjs client connection request fast enough (we had tried some other recommendations scattered around e.g changing public host to 127.0.0.1, localhost, and 0.0.0.0, running without ssl). It ended up working sometimes as sockjs seemed to revert to xhr-streaming instead of websockets, but this didn't really sit nicely for us (and also seemed to break on Firefox for us), hence how we got to this point.

I had looked in to using a custom webpack config for Angular via (https://www.npmjs.com/package/@angular-builders/custom-webpack) and this blog post (https://www.digitalocean.com/community/tutorials/angular-custom-webpack-config), however couldn't get it working, though YMMV.

I agree that this probably shouldn't be an issue that users of the aspnet template encounter, though I hope this may help some, and potentially a fix may come out of this for Angular peeps.

[erictor]

@mattywong Thanks for taking the time to provide what you've learned about this. A question comes though, why would this issue appear only after moving from .NET Core 3.1 to .NET 5? .NET Core 3.1 allowed more time for the sockjs client connection request to be proxied?

[mattywong]

@erictor, I ended up testing our React setup with a fresh .NET core 3.1 project and can confirm it works fine with sockjs on 3.1.

Side note, my experience leans towards the node/javascript ecosystem, so my understanding of .net and the c# ecosystem is limited.

This issue seems to only be in .NET 5 (or SpaExtensions > 3.1.15 (and/or any of it's sibling references) via UseProxyToSpaDevelopmentServer).

From running both projects, it seems the problem is to do with the initial handshake of the websocket connection.

This led me to looking in to the WebsocketMiddleware and the SpaProxy source files and comparing 3.1.15 with 5.0.6.

I do not know if the below diffs are relevant at all, these were just the ones I had spotted that seemed interesting, and may or may not be useful (red v5.0.6, green v3.1.15):

[erictor]

@mattywong Thank you SO MUCH for your great research. @captainsafia, do you think the above diffs could be reviewed by someone at MS? It seems like this could be a great clue as to what may be the real reason why .NET 3.1 is playing well with sockjs and .NET 5.0.1 seems to not be.

[mattywong]

@erictor @captainsafia , my curiosity got the better of me, and from my testing, I believe I have found the lines and pr/issue that had introduced this bug. I had noticed the commented issue in one of the diff's mentioned above.

4eebc16
#16863
#16797

I have commented out those lines, rebuilt aspnetcore, used the output artifact produced for SpaServices.Extensions (Microsoft.AspNetCore.SpaServices.Extensions.dll) and copied that over to my local project, and the WebSocket connection warning is gone. I'd probably recommend someone else confirm this by removing those lines and building from source, but i've attached the resulting SpaServices.Extensions.dll for testing purposes.

Microsoft.AspNetCore.SpaServices.Extensions.dll.zip

[Tratcher]

@erictor The sample you gave in #29478 (comment) is missing the UseWebSocket middleware, so it won't hit this WebSocket code path in the SpaProxy.

aspnetcore/src/Middleware/Spa/SpaServices.Extensions/src/Proxying/SpaProxy.cs

Lines 66 to 70 in cc45d1b

	if (context.WebSockets.IsWebSocketRequest)
	{
	await AcceptProxyWebSocketRequest(context, ToWebSocketScheme(targetUri), proxyCancellationToken);
	return true;
	}

Does it work if you add app.UseWebSockets() early in the pipeline?

[erictor]

@mattywong I think you really did it! The version of Microsoft.AspNetCore.SpaServices.Extensions.dll that is building in my solution is 61k in length. The updated/fixed version you attached above is 56k in length. When I was initially testing yours -- by dropping it in my \bin\Debug\net5.0\ folder in place of the one that is normally there -- I was frustrated that it didn't seem to work. But then I started to check the folder I had dropped it in, and I started realizing my 61k version kept replacing your 56k version. I tried different things (avoiding rebuilding, just doing the Ctrl+Shift+W View In Browser action on my SPA project in my Angular solution) and finally it 'stuck' and wasn't being overwritten. Then... YUP, it worked. There was no sockjs "Websocket is closed before the connection is established." error displaying in browser Dev Tools. And if I changed a character in one of the files (changed one letter in a caption in an html file) the browser Live-Reloaded and showed the change. If I F5 Refreshed the browser (I did this multiple times), same thing -- no 'websocket is closed' error, Live-Reload continued to be enabled and demonstrably worked.

So --- WINNING --- and now my question is, how can this be made permanent... so I can use NuGet from within Visual Studio to pull down a latest-and-greatest rev of Microsoft.AspNetCore.SpaServices.Extensions into my SPA project and not worry that the current problematic version of the file will be restored into my \bin\Debug\net5.0\ folder? @captainsafia

[P.S. to be complete in my comments, I want to reply to @Tratcher and say thanks for your thoughtful idea; however, I did try moving app.UseWebSockets() to be as early in the pipeline as possible (right at the top of the Configure routine that passes "app" in), and it didn't resolve the 'websocket is closed' issue.]

[mattywong]

Looks like it won't be fixed:

#32677 (comment)

Upsetting to say the least.

[mcardoalm]

At least until .NET 6 is released, I found that downgrading just Microsoft.AspNetCore.SpaServices.Extensions to version 3.1.16 solved the live reload issue for us. Was able to stay on .NET 5 and all other packages are up to date.

Looked through the changes in the source and the changes between 3.1.16 and 5.0.7 seem to be minimal and besides losing some cleanup processes fixes using the 3.1.16 version with .NET 5 should be okay.

[dylanvdmerwe]

Has anyone been able to test this on latest .NET 6 preview? They are asking for feedback and I really feel this should be resolved as it has completely broken the development flow of people using the Spa Services (we use it for Angular).

The websocket does not connect anymore when VS starts the ng serve process, which means that when changes are made, developers manually need to refresh the various sites they are working on instead of the site being refreshed automatically. This also break HMR and other good development stuff.

[mcardoalm]

Added a comment here to hopefully open up discussion about fixing this issue in .NET 5 until .NET 6 is released:
#32677 (comment)

[jlquijada]

I just wanted to add that during this time my project has been updated several times.

Now it is using .Net 5.0.7, and Angular 12.1.0 and the problem is still there.

Really annoying and inconvenient having to reload the page for each and every change done on the Angular side, and never knowing for sure if the latest version was already being served after my changes.

Visual Studio Professional 2019 16.10.3 to run the back-end (C# .Net) and the one that starts the "ng serve".
Visual Studio Code - Insiders, version 1.58.0-insider for the front-end edition.

[enriquega-key]

At least until .NET 6 is released, I found that downgrading just Microsoft.AspNetCore.SpaServices.Extensions to version 3.1.16 solved the live reload issue for us. Was able to stay on .NET 5 and all other packages are up to date.

Looked through the changes in the source and the changes between 3.1.16 and 5.0.7 seem to be minimal and besides losing some cleanup processes fixes using the 3.1.16 version with .NET 5 should be okay.

Unfortunately this didn't work for me... Thanks anyway. I got a different error:
An unhandled exception occurred while processing the request. TimeoutException: The Angular CLI process did not start listening for requests within the timeout period of 0 seconds. Check the log output for error information. Microsoft.AspNetCore.SpaServices.Extensions.Util.TaskTimeoutExtensions.WithTimeout<T>(Task<T> task, TimeSpan timeoutDelay, string message)

[javiercn]

We've significantly changed the way the SPA templates are setup for development and production to align with how other backend frameworks approach this and as a result we no longer use SpaServices as part of the development workflow.

While we haven't removed or obsoleted the code, we don't plan to make future changes/fixes on it and we recommend people migrate to the new approach we use in the templates.