Skip to content
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

Closed
muratg opened this issue Dec 18, 2015 · 15 comments
Closed

Passing arguments to project.json #4622

muratg opened this issue Dec 18, 2015 · 15 comments
Milestone

Comments

@muratg
Copy link

muratg commented Dec 18, 2015

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

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @Eilon on August 11, 2015 5:42

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.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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).

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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

JamesNK/Newtonsoft.Json@b7cfafb#commitcomment-12644907

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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?

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @davidfowl on August 12, 2015 0:56

We added it originally for the NuGet build.

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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...

@muratg
Copy link
Author

muratg commented Dec 18, 2015

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)

@muratg
Copy link
Author

muratg commented Dec 18, 2015

From @victorhurdugaci on October 5, 2015 19:43

Related: dotnet/aspnetcore#450 (comment)

@TheRealPiotrP
Copy link
Contributor

Since we're converging with msbuild, this behavior is expected to fall out of the new project model.

@jefftucker
Copy link

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.

@moozzyk
Copy link
Contributor

moozzyk commented Jul 1, 2016

It's gross but can you set an environment variable and read the value in the script?

@jefftucker
Copy link

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.

@moozzyk
Copy link
Contributor

moozzyk commented Jul 3, 2016

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
rainersigwald pushed a commit that referenced this issue Jul 20, 2020
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants