Aspnetcore: Proposal: Task runner should have built-in access to VS 2015 build configuration name

Created on 12 Jan 2016  路  9Comments  路  Source: dotnet/aspnetcore

In some of the organizations I have been working for, TFS created a number of builds targetting different scenarios (e.g. CI/QA).

Moreover, when I'm building on my personal development machine (BYOD) I'm choosing different targets, too (e.g. Development, Release).

Can we have task runners be able to read the VS 2015 build configuration name so we can take decisions in our task runner scripts on whether we want to uglify/bundle etc.?

I'd like to suggest to create a Visual Studio Node C++ addon reading the current solution file which we then can require:

let Solution = require("vssolution");

let solution = new Solution("MyVsSolution.sln");  // deserializes the current solution file
let isDebug = /DEBUG/i.test(solution.buildConfig.name)

/cc #724

Most helpful comment

Here is my hacking workaround for this until someone comes up with a better one.
I create a json file in which glup can read in:

  1. Add a pre-build event in the project with the gulpfile.js
    2016-02-09_7-48-42
    This creates a config.json file with the configuration name at the same level of my gulpfile.js.
  2. I read in the json file into the gulpfile.js
var gulp = require("gulp"),
    fs = require('fs');

var json = fs.readFileSync("./config.json", "utf8");
var host = JSON.parse(json.replace(/^\uFEFF/, ''));
host.isDebug = host.config == "Debug";
...

Initial results seem to be working pretty well.
Hope this helps someone else.

Update
Thanks @samirageb this is fixed.

All 9 comments

Here is my hacking workaround for this until someone comes up with a better one.
I create a json file in which glup can read in:

  1. Add a pre-build event in the project with the gulpfile.js
    2016-02-09_7-48-42
    This creates a config.json file with the configuration name at the same level of my gulpfile.js.
  2. I read in the json file into the gulpfile.js
var gulp = require("gulp"),
    fs = require('fs');

var json = fs.readFileSync("./config.json", "utf8");
var host = JSON.parse(json.replace(/^\uFEFF/, ''));
host.isDebug = host.config == "Debug";
...

Initial results seem to be working pretty well.
Hope this helps someone else.

Update
Thanks @samirageb this is fixed.

Very good comment! Excellent approach.

I'll use that for now. Yet, I still believe this should become built-in.

Update
@jonantoine (thanks!) has addressed the concern in this post and the below concerns and changes no longer apply.

_IGNORE BELOW THIS LINE_
@jonantoine Much thanks for this. Although I found 1 line to be counter intuitive. I believe this line:

host.isDebug = host.config != "Debug";

should be:

host.isDebug = host.config == "Debug";

In order to get host.isDebug returning _true_ when host.config is set to 'Debug'. Please let me know if I'm missing something.

Here's what I'm doing with xproj:
project.json:

{
  "scripts": {
    "prebuild": [ "npm run gulp -- default --configuration=%build:Configuration%" ]
  }
}

gulpfile.babel.js:

import minimist from "minimist";

const argv = minimist(process.argv.slice(2));
const production = "release" === (argv.configuration || "debug").toLowerCase();

But I agree that there should be an environment variable, which would do all this for me.

@ljani How is this possible since RTM?

@roydukkey The principle of delivering the configuration name is still the same, although the names of the hooks have changed with rc2/preview1 and thus with rtm/preview2 too (eg. prebuild -> precompile etc)

@ljani Yes, but did %build:Configuration% change to something else? It's not being replaced by rtm/preview2.

@roydukkey Sorry, I should've been more explicit, the name build has been replaced with compile everywhere, including %build:Configuration%. Ie this is working fine for me:

{
  "scripts": {
    "precompile": [ "npm run gulp -- default --configuration=%compile:Configuration%" ],
  }
}

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

Was this page helpful?
0 / 5 - 0 ratings