cs-script: Could not find a part of the path with CS-Script 4.0.0.0

Just gave version 4.0.0.0 a try by running a simple script.

As stated in the release notes I’ve simply unpacked the downloaded 7z file and try to run it.

I get an error:

Could not find a part of the path ‘C:\Users\MyUser\AppData\Local\Temp\csscript.core\build\obj’.

This is the batch file that I try to run:

PUSHD 
CD /d %~dp0 

SET CSSCRIPT_DIR=%~dp0\cs-script

"%~dp0\cs-script\cscs.exe" /dbg "%~dp0\run.cs" %*

POPD 
EXIT /B 0

And this is the complete cs-script file:

using System:

public static class Install
{
	public static int Main(string[] args)
	{
		log("Started."):
		
		// TODO.

		log("Finished."):
		return 0;
	}
	
	private static void log(string text)
	{
		Console.WriteLine(text):
	}
}

My folder structure is:

  • C:\MyFolder\MyScript (Contains both my .cmd file and my “run.cs” file)
  • C:\MyFolder\MyScript\cs-script (Contains the extracted 7z file)

When calling

dotnet --list-runtimes

I get:

Microsoft.AspNetCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

My question:

Am I doing something wrong?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 23 (13 by maintainers)

Commits related to this issue

Most upvoted comments

This issue has been closed as a more informative error handling notification (on no .NET SDK found) has been implemented.

However, I just realized that the old Roslyn based compilation engine (POC I did before .NET5 was releases) can be used to to execute scripts without SDK.

This can be a solution for the the cases when the low dependency is the primary requirement and the loss of some flexibility is acceptable.

I have resurrected the POC and it seems to work. The feature will be available with both CLI params and in-code directives (similar to dotnet and csc):

css -ng:roslyn test.cs
//css_ng roslyn
using System;
. . .

I am not yet declaring it done 😄 but it looks like I will be able to do it.

TBH I did not fully realized the depth of the SDK-dependency. Thank you, you have triggered this useful investigation. Now I also know that my no-sdk fallback routing helps with the creating the script execution infrastructure but… does nothing for achieving the desired outcome 😞

Still, it’s a usefull learning.

Thank you Uwe. As usual our interactions are mutually beneficial. Have a good one.

Great, thank you. Then I will use it as an SDK test

Hey Uwe, last ask 😃

Can you check please what is the output of the dotnet --list-sdks on the PC without SDK installed.

I am putting the checking at startup

OMG, shame on me. Of course it is the “7” from the 7-zip file extension. Doh!

image

Since I didn’t find any “csc.exe” on the machines, I’ve installed the SDK now on the machines where I want to try CS-Script with .NET 5.

Thanks for your awesome support, Oleg.

OK, I think I may have found the problem. The actual problem. The built-in fall back mechanism that I implemented for no-sdk scenario was crippled by an early mistake in the fallback trigger.

I have fixed it. Try the attached build v4.0.1. It will create the project file reliably.

We may still fail if dotnet.exe cannot build the assembly but we will test it too.

Uwe, this is what you need to try:

  1. Remove the csproj file you created manually.
  2. Try your test with the attahhed 4.0.1.1 build.
  3. If it succeeds go and celebrate it with some beer. 😃 If not then try the attached test.zip file: execute test.cmd. It will check if an assembly can be built at all.

There is a good chance you will not need to do step 3. test.zip

cs-script.win.v4.0.1.1.7z.zip

I found the trigger for the problem. In absence of SDK a C# project template cannot be created so dotnet.exe cannot use it to compile the script to assembly. csc.dll can do the job but it is not available if sdk is not installed.

I am yet to see why we are failing to create a template but let’s try this:

  • investigation Try to execute dotnet new console -lang C# and let me know the produced folder structure
  • potential temp work around In C:\Users\KeimUwe\AppData\Local\Temp\2\csscript.core\build drop the attached project template file manually. let me know if you can run the scripts now.

uwe.zip

I have prepared RC for v4.0.1.0. It supports a new switch -verbose2 that prints the compiling command and the compiler output. The intention is to help in the cases like yours, when I cannot easily access the required environment to reproduce the problem. I have attached the binaries.

image

Please give it a try and see what exactly is upsetting the compiler

cs-script.win.v4.0.1.0.7z.zip

Hm… It found it. The dotnet executable.

Can you now try to run your script with an extra CLI arg -ng: to ensure dotnet but not csc is used.

In fact try both:

cscs -ng:csc -c:0 test.cs 
cscs -ng:dotnet -c:0 test.cs 

This is an excellent clue. Yes SDK is a dependency. On Choco .NET 5 SDK is a dependency of the package so it is installed automatically.

I am still behind with the documentation and will need to reflect the need for SDK explicitly.

Though… I would still expect .NET Runtime to be able to run. Can you please execute cscs.exe? It will print the found compilers. I suspect it cannot find them in your case.

Not sure what is happening.

Your test-case works OK for me. Just to avoid any discrepancy I have attached the working test case (very same that you have shared)

support.zip

Though I have slightly different runtimes installed:

D:\dev\support>dotnet --list-runtimes
Microsoft.AspNetCore.All 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

It looks like I am running a more complete .NETCore (e.g. with desktop)

Can you please check the attached test case to ensure we are running the same things

Hi Uwe, will check