-
Notifications
You must be signed in to change notification settings - Fork 224
Passing arguments to project.json #2450
Comments
Hmm, interesting. I think there are a couple ways (at least) to go about this:
I don't see (1) happening, but (2) is certainly interesting (to me). Might be other reasonable options as well. |
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. |
@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). |
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. |
FYI there are some cases where you can pass settings in via environment variables, e.g. DNX_BUILD_KEY_FILE |
AFAIR we decided to leave DNX_BUILD_KEY_FILE to not break the CI... @davidfowl do you remember? |
We added it originally for the NuGet build. |
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... |
+1 for this. We need it for feature defines (like disabling the min version check on dev) |
Related: dotnet/aspnetcore#450 (comment) |
This issue was moved to dotnet/cli#563 |
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)
The text was updated successfully, but these errors were encountered: