`//css_reference` search order

[maettu-this]

Hi Oleg,

As documented in https://github.com/oleg-shilo/cs-script/wiki/Script-Syntax#directive-css_reference, the "assembly must be in one of the search directories". What if there are two same-named assemblies in the directories? As far I know, the order of directories is not specified. The compiler will arbitrarily pick an assembly.

Questions/ideas:

• Would it be possible to specify the desired assembly version with //css_reference, e.g. //css_reference [-ver:<version>]?
• Could //css_searchdir be specified to be at the top of the search directories, resulting in assemblies located in //css_searchdir being priorized over assemblies in other directories?
• Any other idea?

Best regards,
Matthias

[oleg-shilo]

Hi @maettu-this,
The assembly probing follows the standard concept of file probing as in any dependency resolution scenario.

E.g. native exe will pick the first dll with the required name from the exe dir and then from the directories in the envar PATH. The order is as the directories appear in the PATH.

CS-Script follows the same concept but with a little extra. It allows comprehensive management of the probing directories. These directories are a combination of script dir, some well-known directories, directories specified directly in the script or as CLI params.

In what order? Well, the easiest way to answer this question is to execute any script with the -verbose parameter. This will print all the search dirs in the order they are going to be probed:

This should help.

Would it be possible to specify the desired assembly version ....

While it's not impossible, it's not in the feature that I plan to implement. The reason is that cs-script does not load the assembly to test if it is the one that you need, but only checks the file name. It needs to stay this way, loading is not always possible (e.g. if the correct assembly is of a different CPU architecture).

//css_searchdir being priorized over assemblies in other directories...

Yes it is already the case. The only dirs with the higher probing priority are:

• process current dir
• script file dir
• script engine dir

[maettu-this]

Hi @oleg-shilo, thanks for the details, the last piece of information was what I had been missing: The "process current dir". This fact kills the idea I had in mind:

Given a hosting application that ships with with an assembly, e.g. "nunit.framework.dll" version 3.14, enabling a script to use that assembly out-of-the-box. Now if a script wants to use NUnit 4.x instead, I intended to specify //css_dir to let compilation retrieve the 4.x assembly from some other location. But as the "process current dir" has higher priority, this idea won't work, the 3.14 version will always "win". I assume there are good reasons for this behavior.

Now, e.g. with a C compiler, one typically has the option to exclude the standard search dirs, with GCC e.g. "prevent the preprocessor from searching any of the default system header directories with the -nostdinc option" (https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html). Would this be a possible way to refine CS-Script behavior?

In any case, I think the behavior should be documented at https://github.com/oleg-shilo/cs-script/wiki/Script-Syntax#directive-css_searchdir, i.e. it should be documented, which paths are searched, and in which order. I understand that -verbose tells me this piece of information, but that doesn't tell me the concept/specification behind.

And two minors:

• https://github.com/oleg-shilo/cs-script/wiki/Script-Syntax#directive-css_searchdir:
  "expression.In" misses a space and should be "expression. In".
• https://github.com/oleg-shilo/cs-script/wiki/Script-Syntax#directive-css_precompiler:
  The link at the end of the paragraph misses the closing ")".

[oleg-shilo]

About the documentation... You are right, it should have been well reflected there, but it is not.
I have updated the implementation (as well as the typos). And in the next release this will be the output: this will be the output of css -syntax //css_searchdir:

//css_searchdir <directory>;

Alias - //css_dir

directory - name of the directory to be used for script and assembly probing at run-time.

This directive is used to extend the set of search directories (script and assembly probing).
The directory name can be a wildcard-based expression. In such a case all directories matching the pattern will be
this case all directories will be probed.
The special case when the path ends with '**' is reserved to indicate 'sub directories' case. Examples:

    //css_dir packages\ServiceStack*.1.0.21\lib\net40
    //css_dir packages\**

Directory probing order:
  0: script dir
  1: current dir
  2: script host/engine dir
  3: dirs from cmd args
  4: dirs from code
  5: dirs from config
  6: csscript special dirs, e.g. cache dir
The precise runtime order can be discovered by executing the script with the -verbose switch.

I assume there are good reasons for this behavior.

Yes, it was.
We are talking not the runtime dependency here (assembly), and on all OSs, as far as I am aware, the dependency probing mechanism always checks the location of the dependent module first. The canonical example is the exe file that will always pick the dependency dll located next to the exe file.

This is very much consistent with your case of //css_reference since you are also probing for a library.

The case of //css_include, is not much different and it has been implemented arguably in all scripting languages (e.g. Python).

The fact that the C compiler has a special exclusion mechanism is interesting, but it is targeting a very specific case of an SDK folder, not the "fundamental" location as "currdir".

Thus, I do not see a strong case for bringing similar functionality in CS-Script and, as a result, creating an obscure dev experience.

Now, about your problem.

You can easily solve it by distributing your nunit.framework.dll in a subfilder:

Root
├── lib
│   └──  nunit.framework.dll
└── my-app.cs

In your script, you can have this directive:

//css _searchdir .\lib 
//css_ref nunit.framework.dll

And if you are running on the OS where another version of nunit.framework.dll is present, you simply pass the desired folder with higher precedence like this:

css -dir:%USERPROFILE%\.nuget\packages\nunit\2.4.8\lib\net45 my-app.cs

Or you can combine both dirs in your script without specifying it as CLI param:

//css _searchdir %USERPROFILE%\.nuget\packages\nunit\2.4.8\lib\net45 
//css _searchdir .\lib 
//css_ref nunit.framework.dll

Or you can have a cs file (probing_dirs.cs) with only all possible //css_dir statements in the desired order. And then in your my-app.cs:

//css _inc probing_dirs
//css_ref nunit.framework.dll

---

However, the most obvious solution would be a single nuget directive in the my-app.cs without even distributing the dll:

//css_nuget NUnit 
. . .

This will ensure that the package is downloaded before the script execution.

Unless this approach is incompatible with your target environment for some reason.

[maettu-this]

Thanks for adding the details to the documentation, this will help understanding the behavior.

The folder approach indeed does the trick, I'll use that. The NuGet approach isn't what my hosting app wants to have to rely on, I don't want to have nightly hardware tests stalling due to some network hickup. Also, I don't really like the NuGet approach, what is the purpose of probing the same thing hundreds of times each day? I prefer a release notification and a managed upgrade strategy for such 3rd party packages.

From my point of view, given the documentation will get updated, you may close this issue. Or keep it open until the next release. I am fine with both. Thanks!

[oleg-shilo]

Done. v4.13 is released

You can update with:
dotnet tool install --global cs-script.cli
dotnet tool update --global cs-script.cli