This project is read-only.

Settings missing from Visual Studio generated projects


If I enable unsafe code or add nuget dependencies to my csscript, it doesn't run from visual studio.


oleg_s wrote May 7, 2016 at 2:15 AM

Can you please describe how you run the script from VS?

So far I see the problem with script->rightClick->open-in-VS. Indeed it doesn't pick the referenced packages thus the debug*.cs script will need to be updated. But may be there are some other use-cases.

Opening the script in VS from Notepad++ seems OK. I was able to enable unsafe code, the NuGet package (in this case CSSCriptLibrary.dll) assemblies were also referenced properly.


You may use Notepad++ for now and I will update the CS-Script distro to match the Notepad++ version of debug*.cs. )

br1 wrote May 9, 2016 at 1:40 AM

Hi Oleg,

I was doing script->rightClick->open-in-VS. I'll try Notepad++. The workaround I'm doing for now is to enable unsafe code and add nuget packages manually in Visual Studio.

br1 wrote May 17, 2016 at 10:20 PM

I just hit this bug in reverse. When a cs references UdpClient, it runs from the autogenerated visual studio project but fails when running it directly.

oleg_s wrote May 18, 2016 at 5:23 AM

Txs, this one cannot be addressed directly. This is because VS has auto references some assemblies even without user nominating these assemblies. I think it comes from the machine.config file. Thus cs-script engine cannot possible know about these assemblies.

However you can achieve very similar behavior by configuring CS-Script default referenced assemblies. from the CS-Script config console. Then you don't have to reference them from code and the script engine will always add them automatically. By default CS-Script auto references System.Core and System.Linq:


br1 wrote May 18, 2016 at 2:07 PM

According to, csc.exe will load default assemblies from csc.rsp (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.rsp). Maybe cscs should have the same defaults. The list is quite long, but does not include System.Linq, though.

oleg_s wrote May 25, 2016 at 1:20 AM

Yes, I know about csc.rsp and indeed it was tempting to use it. Though I had to abandon this idea. These are the reasons:
  • csc.rsp is only one of the possible assembly referencing defaults. For example Visual Studio doesn't use it at all and relies on a very different set of ref assemblies. Roslyn and Mono also use different mechanism.
  • If csc.rsp is used then every script should unconditionally reference some rather exotic assemblies from rsp (e.g. System.Data.OracleClient, System.Deployment, System.Workflow.Activities, System.Web.Extensions.Design). I found it hard to justify.
  • csc isn't typically directly exposed to the user so referencing 38 assemblies (just in case) doesn't annoy the end user. Though CS-Script (similarly to Visual Studio) directly shows to the user the whole set of the referenced assemblies and if we go this way I will be facing a plenty of "please explain" requests.
  • If csc.rsp is used then user have to either surrender the ability to modify CS-Script default assemblies or modify them via csc.rsp and this cannot be done without affecting the whole system.
  • Linux doesn't have csc.rsp thus the alternative mechanism needs to be used anyway.
    That is why CS-Script uses css_config.xml to define default referenced assemblies.
Keep in mind that apart from css_config.xml CS-Script use an interesting alternative technique. You can define your assemblies in a globally available scriopt that has no C# code (e.g. default_refs.cs):
//css_ref System.Web.Mobile.dll
//css_ref System.Web.RegularExpressions.dll
//css_ref System.Web.Services.dll
//css_ref System.Windows.Forms.dll
//css_ref System.Workflow.Activities.dll
//css_ref System.Workflow.ComponentModel.dll
//css_ref System.Workflow.Runtime.dll
//css_ref System.Xml.dll
//css_ref System.Xml.Linq.dll
And now you can just reference all these assemblies in your script with a single 'include' directive:
//css_inc default_refs
your script code