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

Accessing build configuration such as Debug, Development and Release in scirpts in project.json #1621

Closed
mbharodia opened this issue Jul 1, 2016 · 7 comments

Comments

@mbharodia
Copy link

Hello,

Ref: project.json file

I want to access type of configuration such as Debug, Development etc. in "scripts". Is it possible. Presently there are only a few options available and they all are related with project properties such as name, version etc. I want to do something like the following where I am passing a configuration type to a batch file

"scripts":{
"postcompile":["myBatch.bat %configuration%"]
}

Really appreciate any help!

@ShadowDancer
Copy link

There are 4 (?) ways to set environment.

#1 Default is production - this is simple case
#2 UseEnvironment on WebHostBuilder - custom implementation (for instance if you pass it in command line args you will need to parse "arguments" argument in web.config)
#3 Environmental variable - try to read ASPNET_ENV variable
#4 Configuration file (UseConfiguration on WebHostBuilder) - parse config file that you are using

@mbharodia
Copy link
Author

Hello Thanks for your reply. It is good to know about setting up environment variables. However, I like to know how I can pass which solution configuration (Debug, Release and Development etc.) I am using while doing build on visual studio. Depending on the solution configuration I like to run batch file to process a few files. I have named appsettings files after name of configuration such as appsettings.debug.json or appsettings.release.json etc. Earlier I used $(ConfigurationName) in project properties. However, we don't have any option with Asp.Net Core MVC any more. I think that is moved to project JSON within "scripts":"postcompile:[]".

All of the difficulties arise due to the fact that I don't have different machines for various environments. I have one machine which hosts TEST and LIVE site. Therefore, environment variables would not work for appsenttings.json. Therefore, I like to generate required appsettings.json on the fly during build. I like to set which build I am doing using solution configuration. It is pretty similar to config transforms in older MVC. I have batch file set up for this reason. This file takes an argument of build configuration and copies file. For example, if I pass an argument "release", then it looks for appsettings.release.json and copies that to appsetting.json. This way now I have build available with a valid appsettings. This can be now published. If I am doing development then I keep the build configuration to debug. In this case during build appsettings.debug.json is copied to appsettings.json and I have appsettings available for the development.

My cient has 18 various web applications and they are not in a positon to create VMs for each and every environment. To keep the cost low we have this work around where we host test and live site on the same box. Sorry this is not as per standeard but I don't have choices.

I hope now it would be clear what I am trying to achieve. I am really looking for a solution here which is valid in Asp.NET Core MVC type of project set up. Config transform worked very well earlier. Now everything is based on environment and I am not aware of any soluton to fix this problem.

@ShadowDancer
Copy link

ShadowDancer commented Jul 1, 2016

I see that my comment was totally out of context :(

I think that you have two options:
#1 in case you have CI server you may do it there (but I guess you do not)

#2 generate both configuration files, and then do something like

#if DEBUG
builder.AddJsonFile("appsettings.debug.json");
#endif

or you may use environment and:

if (env.IsDevelopment())
                builder.AddJsonFile("appsettings.dev.json");

@mbharodia
Copy link
Author

Thank you for getting back so quickly. I guess your second option with compiler directives could be useful in my case. It is clear and easy. By the way I don't know what is CI server. If you have time may I request you to provide me with some hint or some documentation? Were you talking you continuous integration? Thanks a lot again for your help and co-operation.

@ShadowDancer
Copy link

ShadowDancer commented Jul 1, 2016

I have even more crazy idea - You make your application respond with build configuration if magic argument is on command line. This way your build script may ask your exe for buildConfiguration.

These are hacks of course. I think you should not deploy configuration with application. In my setup I send releases with pdb everywhere. Each server have config file where it is stated what kind of server is it (production/staging) and then application makes decisions based on environment.

@moozzyk
Copy link
Contributor

moozzyk commented Jul 1, 2016

@mbharodia
Copy link
Author

Yes. That’s what I was looking for. Thank you so much Pawel.

From: Pawel Kadluczka [mailto:[email protected]]
Sent: Friday, July 1, 2016 3:45 PM
To: aspnet/Home [email protected]
Cc: Mayur Bharodia [email protected]; Mention [email protected]
Subject: Re: [aspnet/Home] Accessing build configuration such as Debug, Development and Release in scirpts in project.json (#1621)

@mbharodiahttps://github.com/mbharodia - are you asking about this: http://stackoverflow.com/questions/37596115/how-to-run-scripts-based-on-solution-configuration-in-asp-net-core-rc2 ?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/1621#issuecomment-230054207, or mute the threadhttps://github.com/notifications/unsubscribe/AJ3YwawIanDUaH5hHHQza8X8tmhRSV5mks5qRYpegaJpZM4JCvmi.

@moozzyk moozzyk closed this as completed Jul 1, 2016
@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants