Resolving 'Unexpected token '<' in Angular and .NET 8 Deployment

When Deployment Works in Debug but Fails on IIS

Have you ever faced the frustration of seeing your application work perfectly in debug mode but fail miserably when deployed? 😟 This can be particularly vexing when migrating a project, as I recently experienced when moving my Angular and .NET application from .NET Core 2.1 to .NET 8. The issue seemed cryptic: an 'Uncaught SyntaxError: Unexpected token '<'' error.

The odd part? Inspecting the deployment files revealed that some scripts—such as runtime, polyfills, and main—were served as HTML files instead of JavaScript. This behavior left me scratching my head because the local `dist` folder showed the correct JS format. The IIS deployment, however, painted a very different picture.

As a developer, encountering such inconsistencies feels like solving a mystery where every lead opens up another confusing question. I double-checked paths, commands, and configurations but couldn't pinpoint the cause immediately. With deadlines looming, solving this issue became a priority. 🕒

In this post, I’ll dive into the root cause of this problem, share the lessons I learned during troubleshooting, and guide you through resolving it effectively. If you’ve run into a similar scenario, stay tuned—I promise you’re not alone in this journey!

Demystifying Deployment Errors in Angular and .NET Applications

In the scripts provided above, each solution focuses on a specific aspect of troubleshooting deployment issues in an Angular and .NET environment. The IIS configuration file using the web.config is crucial for resolving MIME type mismatches. By explicitly mapping file extensions like `.js` to their proper MIME type (application/javascript), IIS knows how to correctly serve these files to browsers. This prevents the "Unexpected token '<'" error, as improperly served files often get interpreted as HTML instead of JavaScript. This approach is highly effective in cases where server configuration is the root cause of the issue. 😊

The Angular build command (ng build --prod) ensures the application is optimized for production. The `--output-hashing=all` parameter hashes filenames, enabling browsers to cache files without accidentally using outdated versions. This is particularly important in real-world deployments where users frequently revisit the application. By configuring `baseHref` and `deployUrl` in `angular.json`, we ensure that routing and asset loading work seamlessly even when hosted in subdirectories or CDNs. These steps make the application resilient to common deployment challenges, improving both user experience and reliability.

The Node.js script provided above adds another layer of debugging by scanning the `dist` directory to confirm the integrity of files. Using commands like `fs.readdirSync` and `mime.lookup`, the script verifies that each file has the correct MIME type before deployment. This proactive step helps catch potential errors before they occur in production, saving time and reducing frustration. For instance, during one of my deployments, this script helped me realize that a configuration issue had led to JSON files being served with the wrong MIME type! 🔍

Finally, the Jest test script ensures automated validation of key deployment aspects. It checks for the existence of critical files like `runtime.js` and `main.js` in the `dist` folder. This prevents overlooked errors during deployment, especially in team environments where multiple developers are involved. By incorporating such tests, you can confidently deploy your application knowing it has been thoroughly validated. These solutions, when used together, create a robust process for resolving deployment challenges and ensuring smooth production releases.

<!-- web.config solution to fix MIME type issues in IIS -->
<configuration>
  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".*" mimeType="application/octet-stream" />
      <mimeMap fileExtension=".js" mimeType="application/javascript" />
      <mimeMap fileExtension=".json" mimeType="application/json" />
    </staticContent>
  </system.webServer>
</configuration>

// Angular CLI commands to rebuild the application
ng build --prod --output-hashing=all
// Ensure deployment paths in angular.json are set correctly
{
  "outputPath": "dist/my-app",
  "baseHref": "/",
  "deployUrl": "/"
}
// Copy contents of dist folder to IIS hosted directory

// Node.js script to check MIME types of files in the dist folder
const fs = require('fs');
const path = require('path');
const mime = require('mime-types');
// Directory to check
const distDir = path.join(__dirname, 'dist');
// Function to validate file types
function validateFiles(dir) {
  fs.readdirSync(dir).forEach(file => {
    const fullPath = path.join(dir, file);
    if (fs.lstatSync(fullPath).isDirectory()) {
      validateFiles(fullPath);
    } else {
      const mimeType = mime.lookup(fullPath);
      console.log(`File: ${file}, MIME Type: ${mimeType}`);
    }
  });
}
validateFiles(distDir);

// Jest test to validate Angular dist folder integrity
const fs = require('fs');
const path = require('path');
test('All JavaScript files should exist and be served correctly', () => {
  const distDir = path.join(__dirname, 'dist');
  const requiredFiles = ['runtime.js', 'polyfills.js', 'main.js'];
  requiredFiles.forEach(file => {
    const filePath = path.join(distDir, file);
    expect(fs.existsSync(filePath)).toBe(true);
  });
});

Understanding the Importance of Static File Configuration in Deployment

One critical aspect often overlooked during deployment is the proper configuration of static file handling. In the case of Angular and .NET applications, static assets such as JavaScript and CSS files must be served correctly for the application to function. Improper MIME type settings on the server can lead to errors like the infamous "Uncaught SyntaxError: Unexpected token '<'," where a file expected to be JavaScript is instead served as HTML. Setting up staticContent in the IIS configuration ensures these files are interpreted correctly. Such server-level configurations are indispensable for avoiding runtime surprises. 🚀

Another angle to explore is the impact of routing misconfigurations. Angular applications use client-side routing, which often conflicts with server setups expecting predefined endpoints. Adding fallback routes in the server configuration, like redirecting all requests to the `index.html`, ensures the application doesn't break. For example, in IIS, this can be achieved with a `` rule that routes all unmatched requests to the Angular entry point. This simple yet powerful step can save hours of debugging and improve your application’s robustness. 🛠️

Lastly, consider the role of build-time optimization. Angular’s `ng build` command with production flags like `--aot` and `--optimization` compiles and minifies the app for better performance. However, ensuring these optimizations align with the deployment environment is key. For instance, enabling source maps during initial deployment can help debug issues in production without compromising security later by disabling them. Such best practices make deployments more predictable and efficient.