Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Console tool, custom environment variables with connection string not picked up
GreenMoose
#1 Posted : Thursday, June 21, 2018 11:43:14 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 397

Thanks: 89 times
Was thanked: 42 time(s) in 41 post(s)
[NCrunch Console Tool v3.17.0.2

I cannot get it to work with supplying custom environment variables via a generated config file, it does pick up the other two though. What am I doing wrong? :|



Thanks
Remco
#2 Posted : Thursday, June 21, 2018 10:27:31 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,374

Thanks: 705 times
Was thanked: 878 time(s) in 835 post(s)
Array-based settings like the CustomEnvironmentVariables are handled by the configuration system in a simplified way, where the values for the settings can only be declared at one level.

For example, you may have some CustomEnvironmentVariables declared at global level, and some more declared at solution level. When the setting is defined at solution level, it will override anything declared at global level. My guess would be that you have this defined at multiple levels and the bottom level one is overriding the other values.
GreenMoose
#3 Posted : Sunday, June 24, 2018 10:07:40 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 397

Thanks: 89 times
Was thanked: 42 time(s) in 41 post(s)
Hrm so if I understand it correctly NCrunch picks up settings in the following order
Code:
global config or "/c configFile" switch to console -> solution config -> "-setting val" switch to console or solution .user config.

But since there are variables I cannot declare via console parameters, I must supply them via "/c configFile", but then the team settings override it.
So basically every value that I cannot specify via "-setting val", I must ensure developers are not adding in solution config because then it breaks the CI build settings? That doesn't sound right?

Thanks.
Remco
#4 Posted : Sunday, June 24, 2018 11:15:45 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,374

Thanks: 705 times
Was thanked: 878 time(s) in 835 post(s)
GreenMoose;12389 wrote:

But since there are variables I cannot declare via console parameters, I must supply them via "/c configFile", but then the team settings override it.
So basically every value that I cannot specify via "-setting val", I must ensure developers are not adding in solution config because then it breaks the CI build settings? That doesn't sound right?


That's correct. Putting it that way, there does seem to be a deficiency here. Which setting is being declared in the solution config that is causing problems for you? Could it be declared in the .user files instead?

Edit: One other option would be to provide the setting inside the engine mode being used by the console tool. Engine mode settings will take precedence over those declared at solution level.
GreenMoose
#5 Posted : Monday, June 25, 2018 5:04:48 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 397

Thanks: 89 times
Was thanked: 42 time(s) in 41 post(s)
Its environment variables that are defined in solution file. Currently for me I can simply remove them from there since I am currently the only one in the team for this project :)
(But those settings override default app.config which determines "Ncrunch or not behavior", that's why it's in solution file so when someone runs without Ncrunch they get correct behavior as well as running with Ncrunch.

* Edit: I'll look into engine mode
GreenMoose
#6 Posted : Monday, June 25, 2018 7:48:26 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 397

Thanks: 89 times
Was thanked: 42 time(s) in 41 post(s)
So I added the custom environment variables as an engine mode and it now correctly picks it up


My current config is as follows:

1) What happens is solution config also has engine mode with same name? I guess that engine mode overrides the "global" one above ? (which is why I always generate a new name for it above)
2) What about grid nodes? If those are defined in solution config I guess those overrides the ones I have set in my global config file? (And since they cannot be set in an engine mode it seems like a dead end on that one?)

Thanks.
Remco
#7 Posted : Tuesday, June 26, 2018 12:35:57 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,374

Thanks: 705 times
Was thanked: 878 time(s) in 835 post(s)
You've won the argument on specifying additional config settings via the command line. We're trying to work out how to proceed with this at the moment.

1) NCrunch identifies the engine modes internally using a combination of their name and the scope they're applied in (i.e. global/solution), so internally there's no weird stuff that would happen with the engine modes having the same name. However, the console tool command line can only identify an engine mode by its name, so there is ambiguity here. It looks like the code will use the first engine mode it will find with a matching name. Based on the sequence the configuration gets loaded, I would expect this will probably be the global one. To avoid confusion, it is recommended that you do not create engine modes with the same name.

2) I can't think of a way to override the grid nodes for a console run, if they've been defined in a solution-level file. This would need to be handled by changing where you declare your configuration settings. Or wait for us to implement the extensions for parsing more complex settings via the command line :)
1 user thanked Remco for this useful post.
GreenMoose on 6/26/2018(UTC)
Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.074 seconds.