Deploying an Angular 2 application from Visual Studio 2017

Question

I use Visual Studio 2017 and have developed two Angular 2 applications. The first is pure Angular 2 with no backend code (Data comes from wcf services). The second is an Angular 2 SPA application hosted in an MVC application (.net 4.6). They both work great and I can run and edit them in VS2017 with no issues. The problem comes with deploying to an IIS server. At the moment, I am bundling the components from the node_modules directory into .js files using gulp. I am then manually copying all the files for the application (including the gulp bundled files) to a server. This is a laborious process and I would like to find a better way. I was hoping Visual Studio would have provided templates to create the two type of angular 2 applications described above and also publish functionality to bundle the app including the necessary node_module components at the click of a button but have been disappointed. What is my best option to get as close to this functionality as possible? Please help.

Answer 1

This is the exact same arrangement I've been working through, with the "holy grail" being using Visual Studio (2015/2017) to develop and debug an Angular 2 front-end (Material Design UI), backed by WebAPI service endpoints in my case, with an Entity Framework database layer. As you said, it's not trivial to get a decent working arrangement that suits all needs. However, with Visual Studio 2017, I believe I have a fairly comfortable setup working, which I can also deploy to our in-house TFS build system.

I am using, currently, the @angular-cli basis, although that in itself is not required. Once it has been initialized, you should then have access to the npm scripts to perform a start (aka ng serve) and a build. In VS2017, you can use the Task Runner (and, if necessary, install the NPM Task Runner Extension for VS2017) window to configure running the "ng serve" command open your project opening. That will begin the webpack bundling and continuous monitoring for file changes; the latter part is important for a smooth debugging and development environment in VS2017, and tying it to the project opening event takes one extra step off your hands.

I then disable VS2017 typeScript compiling by manually editing the project file and adding the following key just below the TypeScript version:

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

I do this for two reasons: with continuous monitoring by the Webpack bundler handling compiling for me, there's no need for VS2017 to do it as well, and this allows me to ensure I'm compiling TS using the npm package installation of typescript over the tools which VS2017 at times stubbornly insists on using despite my overriding the path in the Options menu.

I use Chrome as my browser in VS2017 due to speed now over IE11. For some reason, using IE11 from VS's debugging engine runs really slow for initial load; I believe it is because of how VS must parse through every individual file that is bundled in each Webpack bundling. Chrome seems to run it like a champ. Ironically, Edge runs nearly the same speed as Chrome, but even in 2017 with brand new VS2017, Edge debugging isn't supported in VS2017 - go figure.

Breakpoints in VS2017 files are hit even when Chrome runs the browsing, which is a nice bonus. The only glitches I've seen to this are that I typically have to start debugging in VS2017, let Chrome launch my site, then refresh the page immediately in order for VS2017 to properly parse the sourcemaps. I also have noticed that I tend to have to put my breakpoints in the copies of my TS files that are shown in the "Scripting Engine" block of the Solution Explorer which appears when actively debugging, as breakpointing in my solution files directly doesn't seem to trigger under Chrome. I strongly suspect this is because my sourcemaps aren't compiling with the correct original file path, so VS2017 has no way of knowing that the file in the "Scripting Engine" ties to a specific file in my solution. I'm still working on this one.

The last headache I had to work out for this arrangement is enabling CORS so that the web site front end (Angular) can connect to my WebAPI backend while debugging in VS2017. Since @angular-cli's built-in lite server hosts the front end, and VS2017 boots up IISExpress to host the backend, they will be on different ports. I had to add CORS access to my backend (which I did globally via the global.asax.cs file, and wrapped in conditional compilation flags to ensure it is only used on DEV/local debug builds) to allow the front end to make service calls to the other port on the backend. Works like a charm, though.

---

Edit: To add to this slightly, I've refined my practice a bit to better support debugging in VS2017. When I start up the Angular CLI project, I typically let VS2017 make an empty website project so that the project directory is created. I then drop to a command prompt, get into that folder, and use the Angular CLI tool to generate my skeleton application using this command:

ng new -si -sg -dir . MyApp

The arguments I've specified skip package installation (since VS2017 can do that once I save the package.json file once), skip git (which I personally don't use since I work in a TFS house that doesn't use git), and targets the working directory for the Angular application (because I don't want it creating an extra level of directory).

Then, once that is done, I use Angular CLI's ng eject command to force the CLI to "eject" the tool's control over the webpack bundling and build process. This has the CLI tool write out all of the config files that it uses. I do this because I need to get into the webpack.config.js file to handle sourcemaps a little differently.

For DEV, in VS2017, I modify the webpack.config.js as follows:

1) Add const webpack = require('webpack'); to the top

2) Comment out the line "devtool": "source-map"

3) After the new AotPlugin(..) block, I add one more plugin:

new webpack.SourceMapDevToolPlugin({
    filename: '[file].map',
    noSources: true,
    moduleFilenameTemplate: '[absolute-resource-path]',
    fallbackModuleFilenameTemplate: '[absolute-resource-path]'
})

This seems like the magic charm for using IE11 or Chrome in VS2017 debug mode, which active debug breakpoints and Intellisense debugging. It does, however, break being able to debug directly in Chrome, mainly because this changes the path references in the sourcemaps generated by webpack to be absolute file paths on your computer. VS2017 eats that up, so it can find the source perfectly. My current plan is I'll retain the original webpack.config.js and use that for my DEV testing on our DEV webserver and our PRD builds, but use this revision here in a webpack.vs.config.js configuration with proper scripting (maybe a custom npm script) to do all my local machine DEV work with VS2017. So far...it's nearly a perfect environment for me.

Answer 2

For the first type of application described by you as “pure Angular 2 with no backend code”, you can use the Angular CLI project template available on the Visual Studio Marketplace.

The project is basically a customized ASP.NET Core project which shares the root folder with an Angular CLI application and is a design-time adapter between the traditional development experience in Visual Studio and the infrastructure provided by Angular CLI.

The project supports the standard Publish feature provided by Visual Studio. Only the files produced by Angular CLI during the build, and no DLLs, are published to the target destination.

Disclosure: I am the author of the template. The code is available on GitHub.