Today I wanted to share with you a solution to the issue I faced recently with my ASP.NET Core/Angular2 application.
The website was created based on the templates provided by the ASP.NET team (see Steven Sanderson blog entry for more), it’s using Hot Module Replacement middleware to release developer from the need to rebuild the website and update the website’s code when working on it. The workflow becomes trivial: you save the code in the IDE, and webpack middleware takes care of everything – in like a second you have refreshed code of your website in the browser, so that you can just focus on the development.
What’s so nice to this solution? Shortest will be to quote Steve:
This is not the same as a simple live-reload mechanism. It does not reload the page; it replaces code or markup directly in place. This is better, because it does not interfere with any state your SPA might have in memory, or any debugging session you have in progress
My problems appeared after I had to reinstall my Windows. After I recovered all the SDKs and launched the website, I noticed weird problem in the browser’s console:
EventSource’s response has a MIME type (“text/html”) that is not “text/event-stream”. Aborting the connection.
At first, I just ignored this message, but as it appeared, due to this problem, my code wasn’t even properly rebuilt by webpack, so I couldn’t get my website updated whatever I changed in the code.
I had to dig deeper into this.
Most of the answers all over the web are pointing to changing the url of webpack hmr, but I did not change this url so wasn’t sure it’s my case. I’ve then found this issue on github, where Steve explained, that this might come from the fact, that the application runs in production mode.
As you can imagine, there’s not much sense in running webpack if the application is in production.
So, the problem was, that under the url http://localhost:5000/__webpack_hmr there was no content and response was received as MIME type (“text/html”).
The solution is actually quite easy: one has to explain to the app that it is running in the development, and not production mode.
ASP.NET Core is using Environment variable called
ASPNETCORE_ENVIRONMENT to recognize which environment it is running on. I had no such variable configured after my system got reinstalled (not sure how was it configured for the first time – I suppose during some installation process). After adding such environment variable, everything started to behave properly again.
In my case, the IDE was Visual Studio Code, but when working directly from Visual Studio, you can configure such environment variable via debug profiles (Project -> Properties -> Debug) to be configured when debugging the application. This may save you from this issue even when reinstalling the system (those profiles are saved in launchSettings.json file of the solution).
Hope that will save you some time if you face the same error.