problem with css_inc paths

[kaeth...@gmail.com]

I found weird behaviour with including a file in a different folder that included all files in the current folder.

C:\Dropbox\CSScripts\BatchFiles\RunVirtualDllTests.cs

Has the line:

//css_inc C:\Users\Derek.Morin\Documents\Visual Studio 2010\Projects\ScriptCode\ScriptCode.ConvertedToC#\VirtualDlls\MsTest\*.cs

In that folder, one of the files has:

//css_inc .\*.cs;

So my expected behaviour would be that all of the files in the MsTest folder would end up getting included.  This works fine when I try to compile a dll in the MsTest folder.

But it seems like the //css_inc .\*.cs; actually ends up getting applied to both C:\Dropbox\CSScripts\BatchFiles and C:\Users\Derek.Morin\Documents\Visual Studio 2010\Projects\ScriptCode\ScriptCode.ConvertedToC#\VirtualDlls\MsTest\

So when I look at the project in notepad++ or visual studio I have all the files in MsTest and all the files in BatchFiles - I'm not expecting to have all the files in BatchFiles.

Derek Morin

[Oleg Shilo]

Hi Derek,

Before I start working on this I would appreciate if you cna do some test on your system for me. Can you please execute the following and see what scripts are included into the compilation:

css /cd /verbose main.cs

Thank you,

Oleg 

[DerAnn Kaethlerin]

Thanks Oleg,

I have attached a fairly minimal duplication scenario in a zip file.

If you try to compile RunVirtualDllTests or open it in notepad++ or visual studio you will see that it ends up including the file Cache_GetDotNet.

I would expect that it includes all the files in the subfolder VisualStudioAutomationExtensions but does not include Cache_GetDotNet.

css /cd /verbose RunVirtualDllTests.cs

C:\temp\CSScriptTest>css /cd /verbose RunVirtualDllTests.cs

C# Script execution engine. Version 3.13.4.0.

Copyright (C) 2004-2016 Oleg Shilo.

> ----------------

  TragetFramework: v4.0

  Provider: C:\Dropbox\Installs\cs-script\lib\CSSCodeProvider.v4.6.dll

  Engine: C:\Dropbox\Installs\cs-script\cscs.exe

  Console Encoding: IBM437 (OEM United States) - system default

  CurrentDirectory: C:\temp\CSScriptTest

  NuGet manager: C:\Dropbox\Installs\cs-script\lib\nuget.exe

  NuGet cache: C:\ProgramData\CS-Script\nuget

  Executing: C:\temp\CSScriptTest\RunVirtualDllTests.cs

  Script arguments:

  SearchDirectories:

    0 - C:\temp\CSScriptTest

    1 - C:\Dropbox\Installs\cs-script\Lib

    2 - C:\ProgramData\CS-Script\inc

    3 - C:\Dropbox\Installs\cs-script

    4 - C:\Users\Derek.Morin\AppData\Local\Temp\CSSCRIPT\Cache\-1738924138

> ----------------

Compiling script...

  Precompilers:

   0 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   1 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   2 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   3 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   4 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   5 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

   6 - csscript.DefaultPrecompiler

       C:\Dropbox\Installs\cs-script\cscs.exe

  Output file:

       C:\temp\CSScriptTest\RunVirtualDllTests.dll

  Files to compile:

   0 - C:\temp\CSScriptTest\RunVirtualDllTests.cs

   1 - C:\temp\CSScriptTest\Cache_GetDotNet.cs

   2 - C:\temp\CSScriptTest\RunVirtualDllTests.cs

   3 - C:\temp\CSScriptTest\VisualStudioAutomationExtensions\CodeFunctionExtensions.cs

   4 - C:\temp\CSScriptTest\VisualStudioAutomationExtensions\CsDllOptions.cs

   5 - C:\temp\CSScriptTest\VisualStudioAutomationExtensions\DTEExtensions.cs

   6 - C:\temp\CSScriptTest\VisualStudioAutomationExtensions\StackFrameExtensions.cs

   7 - C:\Users\Derek.Morin\AppData\Local\Temp\CSSCRIPT\Cache\-1738924138\RunVirtualDllTests.attr.g.cs

  References:

   0 - C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Text.RegularExpressions\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Text.RegularExpressions.dll

   1 - C:\ProgramData\CS-Script\nuget\NLog\NLog.4.3.9\lib\net45\NLog.dll

   2 - C:\WINDOWS\assembly\GAC\VSLangProj\7.0.3300.0__b03f5f7f11d50a3a\VSLangProj.dll

   3 - C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.IO\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.IO.dll

   4 - C:\WINDOWS\assembly\GAC\EnvDTE\8.0.0.0__b03f5f7f11d50a3a\EnvDTE.dll

   5 - C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Linq\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Linq.dll

   6 - C:\WINDOWS\assembly\GAC\VSLangProj80\8.0.0.0__b03f5f7f11d50a3a\VSLangProj80.dll

   7 - C:\WINDOWS\assembly\GAC\EnvDTE90a\9.0.0.0__b03f5f7f11d50a3a\EnvDTE90a.dll

   8 - C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll

   9 - C:\WINDOWS\assembly\GAC\EnvDTE80\8.0.0.0__b03f5f7f11d50a3a\EnvDTE80.dll

   10 - C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll

> ----------------

  Compiler Output:

  (0,0):warning CS2002 Source file 'C:\temp\CSScriptTest\RunVirtualDllTests.cs' specified multiple times

> ----------------

Initialization time: 71.5752 msec

Compilation time:    2527.131 msec

> ----------------

C:\temp\CSScriptTest>

[Oleg Shilo]

Thanks, this is what I wanted to confirm. It is consistent with my observations. 

The problem you discovered is a N++ plugin defect and I have logged the issue on your behalf: https://csscriptnpp.codeplex.com/workitem/19# 

The duplication isn't really a problem as the compiler is smart enough to ignore the duplicated files. Though the duplication (even if it's minor) is to be fixed in the next release. 

Thank you fro reporting this.

[DerAnn Kaethlerin]

No problem - thanks for looking into this!

It also seems to happen in the visual studio plugin.  And I'm a little confused since the file Cache_GetDotNet also showed up in the command you had me run.

It makes me think maybe the problem isn't specific to the n++ plugin - unless the command you had me run simulates n++.  :)

Derek

--
You received this message because you are subscribed to a topic in the Google Groups "CS-Script" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cs-script/6QXQgaW5H08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cs-script+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oleg Shilo]

It is all triggered by the wrong priority order of the probing dirs. 

When user specifies *.cs it stops when it finds first directory with the files matching the pattern. And the idea is that the script directory should be probed first and the rest of the probing dirs and only if nothing is found in the script dir.

And it's is just happens that plugins do not put the script dir on the top of priority chain while cscs.exe does (as they all should). The fix will be available soon. And it will be to force the wild card probing to always start from the script dir.

[DerAnn Kaethlerin]

I have noticed that this issue has been fixed in the notepad++ plugin.  I also updated cs-script to 3.1.17 to see if the command line compile was also fixed but it still seems to be a problem.

If you run: css /cd /verbose RunVirtualDllTests.cs with the sample I've attached it still picks up the file Cache_GetDotNet.cs.  If you add some garbage code to Cache_GetDotNet.cs, then RunVirtualDllTests.cs would then fail to compile.

But I don't know if the command line compile is supposed to be fixed yet :)

In notepad++ if I load RunVirtualDllTests.cs then Cache_GetDotNet.cs does not show up in the tree with all the code files, so it all looks perfect in there.

NOTE:  I think I've figured out something, don't know if it is expected or not:

If I do a command line compile from the folder that the script is in, it will include all the other cs-script files within that folder.

If I do a command line compile but am not in the working directory then it won't include all other files

This is slightly different than the notepad++ loading behaviour where it won't load the other scripts within the same folder.

--

[Oleg Shilo]

>But I don't know if the command line compile is supposed to be fixed yet :)

The fix for the notepad++ plugin was done in the plugin and the engine codebase so I expect it to be fixed in both.

I cannot test your sample as you forgot to attach it. :)

However if you are referring to the sample you sent earlier then it has no RunVirtualDllTests.cs script.

Anyway I have attached a "no-dependency" sample that demonstrates (e.g. css -verbose main.cs) that *.cs only takes the scripts in the root directory. See if it works in your environment.

>If I do a command line compile from the folder that the script is in, it will include all the other cs-script files within that folder.

>If I do a command line compile but am not in the working directory then it won't include all other files

Using wildcards can be tricky as it can lear to unexpected side effects. Because you are using the most generic wildcard pattern (*.cs instead of *somekey_word_in_script_name*.cs) the engine picks all matches from the first probing directory where shch matches are found. And because the the current directory is on top of the probind directory queue it gets processed first. 

To solve this you should really consider making your wildcards  more specific. For example //css_inc common_script/*.cs or //css_inc *.tools.cs

Cheers,

Oleg

[DerAnn Kaethlerin]

Here is the sample I have.  I guess the problem is that in my subfolder I have a line:  //css_inc .\*.cs;

If I compile from the root folder with:

 css /cd /verbose RunVirtualDllTests.cs

I will get a compile failure because it picks up Cache_GetDotNet.cs

But if I run the compile from a different folder - it will work:

css /cd /verbose c:\temp\CSScriptTest\RunVirtualDllTests.cs

I don't see any problems when running in notepad++.

--

[Oleg Shilo]

OK, with the sample I see the problem. Yes it is caused by a too wide wildcard pattern. which picks the files from the current directory, which in in your case a root dir with Cache_GetDotNet.  

When you use Notepad++ the current dir is "C:\\Program Files (x86)\\Notepad++" so the cs files are picked from the next probing directory, which is the one that you want to use. This makes it look like N++ does probing differently but in reality it is the same. It's just runtime conditions when N++ discoveres the dependencies are different comparing to the conditions when the script is executes. This is in fact a N++ plugin deficiency/inconvenience and I am going to fix it so the behavior is consistent.

Now you probably have a sense of the potential complications associated with using wide wildcards. Thus the best way to manage it is to use more specific wildcard patterns as I mentioned in my previous email.

Saying that, your sample showed me an interesting opportunity to improve this valid but rather inconvenient wildcard behavior. I logged an issue/feature-request on your behalf: https://github.com/oleg-shilo/cs-script/issues/19. It is in fact implemented in the codebase and it will be available in the next release. With the change the naked wildcards will be treated as they are right now but the ones with the single-dot prefix will be unfolded into an absolute path pattern thus there will be no ambiguity which directory the matches supposed to be picked. I tested your sample and with the change it works as intended.

If you don't want to wait you can build the executable from the github source.

Thank you for your feedback,

Oleg

  

   

Oleg Shilo
--------------------------------------------------------------------------------------------
Website: http://www.csscript.net
E-Mail: csscript...@gmail.com

--
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+unsubscribe@googlegroups.com.

[DerAnn Kaethlerin]

Thanks for looking into this and coming up with a solution.  It sounds like your approach will work well.

I will be sure to try it out after the next release.

Derek

[DerAnn Kaethlerin]

I was able to test this out with release 3.18.  Everything seems to be working really nicely now.  This will make my code much easier to maintain :)

Thanks!

On Wed, Nov 9, 2016 at 11:05 PM, Oleg Shilo <oleg....@gmail.com> wrote:

[Oleg Shilo]

Great, thank you for testing it.