-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passing arguments to project.json #4622
Comments
From @Eilon on August 11, 2015 5:42 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. |
From @JamesNK on August 11, 2015 6:9 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. |
From @Eilon on August 11, 2015 6:18 @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). |
From @JamesNK on August 11, 2015 13:8 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. |
From @JamesNK on August 11, 2015 23:31 FYI there are some cases where you can pass settings in via environment variables, e.g. DNX_BUILD_KEY_FILE |
From @moozzyk on August 11, 2015 23:50 AFAIR we decided to leave DNX_BUILD_KEY_FILE to not break the CI... @davidfowl do you remember? |
From @davidfowl on August 12, 2015 0:56 We added it originally for the NuGet build. |
From @anurse on August 14, 2015 0:53 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... |
From @victorhurdugaci on October 2, 2015 19:25 +1 for this. We need it for feature defines (like disabling the min version check on dev) |
From @victorhurdugaci on October 5, 2015 19:43 Related: dotnet/aspnetcore#450 (comment) |
Since we're converging with msbuild, this behavior is expected to fall out of the new project model. |
have we converged with msbuild yet? I need to be able to pass arguments to a script as a precompile step so that it can generate an assembly that's referenced by the compiler. How do I do that? The documentation (what little there is) doesn't seem to give me much to work with here. |
It's gross but can you set an environment variable and read the value in the script? |
That's what I ended up doing but I really miss having some of the other visual studio variables (like OutputPath and the one that tells me if it's in Debug or Release and so on). It would be really useful if I could pass those to my scripts. It would also be useful if I could read environment variables in the project.json file as well to avoid horrible relative-paths and having to use a bunch of powershell haxin to do things. |
There are some arguments you actually can pass to scripts - see: http://stackoverflow.com/questions/37596115/how-to-run-scripts-based-on-solution-configuration-in-asp-net-core-rc2/37598276#37598276 |
…612.5 (#4622) Microsoft.FSharp.Compiler From Version 10.10.0-beta.20312.2 -> To Version 10.10.0-beta.20312.5 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
From @JamesNK on August 11, 2015 1:23
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)
Copied from original issue: aspnet/dnx#2450
The text was updated successfully, but these errors were encountered: