CODEWITHSUNDEEP
angularangular-cliconfiguration-files
marekdano
marekdano

Reputation: 57

Read config variables from "config file" before starting angular 2 app which was built through angular cli

I'd like to ask for an advice. I'm developing an angular app and using angular cli. The app is going to be deployed on one of the IIS servers. The angular production files will be within web.config (.NET) file in the same folder. I would like to be able to read some variables (e.g. OAuth params or proxy config url) from that web.config file in the Angular production build. Any idea how it can be implemented? Thanks

Upvotes: 0

Views: 1721

Answers (2)

tottomotto
tottomotto

Reputation: 2352

If you need more control of how the Angular app is set up, packed and bundled, you can try to eject it.

This will produce a webpack config file with a default configuration for the ng project. After that, you can modify variables and parameters before build and not only.

Beware, this disables the use of ng commands from the cli.

(Can be reactivated if you change eject: true to eject: false inside the angular-cli.json. However, ng commands will always ignore the webpack config file)

Upvotes: 1

mikegeyser
mikegeyser

Reputation: 327

Unfortunately, the web.config is for server-side applications only, so without additional server-side code (such as hosting inside a dotnet application, and exposing the settings via Web API) it won't really be possible.

Out-of-the-box, the @angular/cli makes use of compile time property settings, which can be frustrating and problematic (you would need to bundle your keys into the deployable code, and rebuild the package if the settings needed to change between environments).

The most common way around this is to create a environment specific config.json file, and then overwrite that at deployment time. So, for example, you would have:

  • dev.config.json
  • test.config.json
  • prod.config.json

And then at deployment time you would just rename the right file over config.json and link to it in your index.html.

I know this likely means duplicating settings into a different file, but it's the most expedient way of solving the problem - and does give you a certain degree of flexibility to change at run-time (just be careful of the file being cached).

Upvotes: 0

Related Questions