Skip to content
This repository has been archived by the owner on Dec 18, 2017. It is now read-only.

Passing arguments to project.json #2450

Closed
JamesNK opened this issue Aug 11, 2015 · 11 comments
Closed

Passing arguments to project.json #2450

JamesNK opened this issue Aug 11, 2015 · 11 comments

Comments

@JamesNK
Copy link
Member

JamesNK commented Aug 11, 2015

When building a csproj with msbuild you can pass it arguments. For example, treating errors as warnings can be enabled with this argument:

/p:TreatWarningsAsErrors=true

It was be useful to be able to pass arguments to a project.json on build (treat warnings as errors, strong name path, etc)

@Eilon
Copy link
Member

Eilon commented Aug 11, 2015

Hmm, interesting. I think there are a couple ways (at least) to go about this:

  1. MSBuild style, where "everything's a variable/list" (you know, the PropertyGroup stuff)
  2. Allow some sort of $(variable) syntax for variables that are either env-vars, or command-line params

I don't see (1) happening, but (2) is certainly interesting (to me). Might be other reasonable options as well.

@JamesNK
Copy link
Member Author

JamesNK commented Aug 11, 2015

You could do option 1 with some kind of path (since Json isn't a flat list)

Eg compilationOptions.treatWarningsAsErrors=true

For now I'm going to have to transform the file myself in my build script and I'll probably use a path to insert the new value.

@Eilon
Copy link
Member

Eilon commented Aug 11, 2015

@JamesNK ah interesting. I hope you know a good JSON parser for your transformations 😄

With paths we'd have to consider how some more complex items would be persisted, e.g. dictionaries that have complex property names, or arrays. For example, even with setting compilation options, you can have that vary per framework, and the "path name" for those could get ugly (especially when they have weird characters in them).

I do think this would be an interesting feature (whatever it ends up being).

@JamesNK
Copy link
Member Author

JamesNK commented Aug 11, 2015

Ok. I'm not a fan of (2) because it would force those params to always be passed it. Optionally passing them in as overrides is more flexible.

I ended up using PowerShell's JSON functionality to modify the project.json so didn't do anything with paths myself.

@glennc glennc added this to the 1.0.0 backlog milestone Aug 11, 2015
@JamesNK
Copy link
Member Author

JamesNK commented Aug 11, 2015

FYI there are some cases where you can pass settings in via environment variables, e.g. DNX_BUILD_KEY_FILE

JamesNK/Newtonsoft.Json@b7cfafb#commitcomment-12644907

@moozzyk
Copy link
Contributor

moozzyk commented Aug 11, 2015

AFAIR we decided to leave DNX_BUILD_KEY_FILE to not break the CI... @davidfowl do you remember?

@davidfowl
Copy link
Member

We added it originally for the NuGet build.

@analogrelay
Copy link
Contributor

It's also a useful feature for cases where you want CI builds to do something but not dev builds. Having said that, a general purpose override system is also useful for that...

@victorhurdugaci
Copy link
Contributor

+1 for this. We need it for feature defines (like disabling the min version check on dev)

@victorhurdugaci
Copy link
Contributor

Related: dotnet/aspnetcore#450 (comment)

@muratg
Copy link
Contributor

muratg commented Dec 18, 2015

This issue was moved to dotnet/cli#563

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants