NBi is a testing framework (add-on to NUnit) for Business Intelligence and Data Access. The main goal of this framework is to let users create tests with a declarative approach based on an Xml syntax. By the means of NBi, you don't need to develop C# or Java code to specify your tests! Either, you don't need Visual Studio or Eclipse to compile your test suite. Just create an Xml file and let the framework interpret it and play your tests. The framework is designed as an add-on of NUnit but with the possibility to port it easily to other testing frameworks.
I will not be able to do any real C# code changes but at least I can contribute the full description and reasoning.
This discussion originally started in #410 . As I assume this is just a one line code check I have created PR #718
background
environment variables
Windows systems seem to have three kind of environment variables process, system and user scope.
System and user scope are in general set with the configuration dialog from the start menu:
Process based environment variables are in PowerShell just set by $Env:MYVAR="value".
I assume NBi is most of the time used in automatic testing and in DevOps pipelines.
Moreover, most likely NBi scripts contain references that are created as part of an Azure DevOps pipeline and thus connections strings and server names must be dynamic.
Which states that:
All environment variables that are provided to it by the parent process that created it. For example, a .NET application launched from a console window inherits all of the console window's environment variables.
If there is no parent process, per-machine and per-user environment variables are used instead. For example, a new console window has all per-machine and per-user environment variables defined at the time it was launched.
As a result I conclude, that we just have to switch from
var value = Environment.GetEnvironmentVariable(args.Name, EnvironmentVariableTarget.User);
to
var value = Environment.GetEnvironmentVariable(args.Name);
As a result it should be backwards compatible and in addition work for variables set at process scope...
Hi @Seddryck ,
I will not be able to do any real C# code changes but at least I can contribute the full description and reasoning. This discussion originally started in #410 . As I assume this is just a one line code check I have created PR #718
background
environment variables
Windows systems seem to have three kind of environment variables process, system and user scope.
System and user scope are in general set with the configuration dialog from the start menu:
Process based environment variables are in PowerShell just set by
$Env:MYVAR="value"
.NBi
The usage of environment variables is explained at http://www.nbi.io/docs/variable-define/#environment-variable .
Automation
I assume NBi is most of the time used in automatic testing and in DevOps pipelines. Moreover, most likely NBi scripts contain references that are created as part of an Azure DevOps pipeline and thus connections strings and server names must be dynamic.
Azure DevOps and most likely any other build agent Jenkins/Bamboo/etc. have the option to pass in environment variables. In Azure DevOps this is easly done and the suggested way to pass in any secret values. ( https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables )
Currently my Azure DevOps pipelines do hack the nbits file to adjust several settings instead....
solution
The relevant code is at: EnvironmentScalarResolver.cs
The documentation of the API is at https://learn.microsoft.com/en-us/dotnet/api/system.environment.getenvironmentvariable?view=net-7.0#system-environment-getenvironmentvariable(system-string) .
Which states that: All environment variables that are provided to it by the parent process that created it. For example, a .NET application launched from a console window inherits all of the console window's environment variables.
If there is no parent process, per-machine and per-user environment variables are used instead. For example, a new console window has all per-machine and per-user environment variables defined at the time it was launched.
As a result I conclude, that we just have to switch from
to
As a result it should be backwards compatible and in addition work for variables set at process scope...