ScriptFile is NULL

[uwe....@gmail.com]

I'm using CS-Script from within a batch file and intentionally did not install it on my machine. 

The batch file looks something like:

PUSHD 
CD /d %~dp0 
CLS 

   

SET CSSCRIPT_DIR=\\myserver\myshare\tools\cs-script 

   

@REM "\\myserver\myshare\tools\cs-script\cscs.exe" /dbg "%CD%\..\..\widgets\build.cs"
POPD 

In most cases this behaves like the following:

1. The script runs as expected
2. When accessing csscript.CSSEnvironment.ScriptFile for the first time, it returns the correct path.
3. When accessing csscript.CSSEnvironment.ScriptFile for the second+ time, it returns NULL.

So to work-around, I simply store it in a static variable and access only this static variable:

private static string _scriptFile = csscript.CSSEnvironment.ScriptFile;

Every now and then even this is not sufficient. In those scenarios, even the very first call to csscript.CSSEnvironment.ScriptFile returns NULL.

My questions:

• What am I doing wrong here?

• Any chance to make csscript.CSSEnvironment.ScriptFile always return the correct path, even on machines where I do not install CS-Script?
  

(The reason why I'm not installing it is that I want a simple xcopy deployment for my scripts whithout any additional installation)

[Oleg Shilo]

Unfortunately csscript.CSSEnvironment.ScriptFile is not as reliable as I wanted it to be. The reason is that it was designed to server a very specific purposes during the script compilation (first run) and during script hosting. And this mechanism can be compromised by the caching or by existence of the cross-domain boundaries in hosting scenarios. That is why I have already (long time ago) implemented a proper mechanism for discovering the script name via assembly attribute: 

string scriptFile = Assembly.GetExecutingAssembly().GetCustomAttribute<AssemblyDescriptionAttribute>().Description;

The limitations of CSSEnvironment can be observed with <cs-script>\Samples\ReflectScript.cs sample. The following fragment of it works perfectly yields different output (empty CSSEnvironment #*) if executed in Notepad++ because the editor hosts the script engine.

PrintScriptName("reflection #1    ", () => CSScript.GetScriptName(Assembly.GetExecutingAssembly()));
PrintScriptName("reflection #2    ", () => Assembly.GetExecutingAssembly().GetScriptName());
PrintScriptName("reflection #3    ", () => GetScriptName(thisAsm));
PrintScriptName("Environment Var  ", () => Environment.GetEnvironmentVariable("EntryScript"));
PrintScriptName("CSSEnvironment #1", () => CSSEnvironment.PrimaryScriptFile); //script that was executed from command line or double-clicked
PrintScriptName("CSSEnvironment #2", () => CSSEnvironment.ScriptFile);	      //script that is currently executed; it may not be a PrimaryScriptFile if it is a pre-execution scripting scenario

Only now, after reading the corresponding section of the documentation I realized that I didn't bring the developers attention to these limitations. I'll do that in the next release. And I will also update the API XML documentation. 

Keep in mind that you can also analyse CSScriptRuntimeLocation environment variable for the location of the cscs.exe.  

Thus the code above should be enough to solve your problem. Just run the ReflectScript.cs sample in your environment and see which methods works the most reliable. Keep in mind that all "reflection #*" are using under the hood the same a primitive reflection algorithm.

 

Regards,

Oleg 

--
You received this message because you are subscribed to the Google Groups "CS-Script" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cs-script+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[uwe....@gmail.com]

Thanks a lot, Oleg!

I'll then stick to the reflection thing.