Skip to content


Subversion checkout URL

You can clone with
Download ZIP


.cs -> .js Dependent Files #305

Michael-DST opened this Issue · 6 comments

2 participants


One of the cool things that I appreciate about TypeScript is that it provides the generated .js file from a .ts file as a dependent file (that is, a child file -- much like a code behind in an aspx) in the Solution Explorer. This is great as you have direct coupling with the file and you don't have to go digging around for a file on the file system.

Might it be possible to incorporate this functionality in Script#?


The generated script file (per project, not per source file) is in the bin\Debug|Release folder. By default this is hidden in the solution explorer, but if you turn on Show All Files, it will be visible.

Are you suggesting it should be made visible? There are things you can do in msbuild to cause the generated file to be added to the project (this is how the reference to mscorlib.dll is added in scriptsharp.targets) ... but where would/should the generated scripts show up?


Ah... no, what I'm suggesting is to do what TypeScript does with its .ts files, what ASP.NET does with its aspx/aspx.cs files, and what WPF does with its xaml/xaml.cs fies. That is, when you add a new "Script# Code File" to a project, it adds a .cs file, with another .js file "attached under" it. That JS file is what gets created when the .cs file is saved and/or the project is compiled. The build process is then just a matter of collecting all the assembled .js files, combining them into one file, and then minifying them into a single .js file (or dare I say Script# Assembly? :)).

That Script# Assembly is then what is added to a project when a Script# Assembly reference is made.


The input to the compiler is a set of c# files. The compilation and script generation does not happen per file ... it happens at the project level. In fact other than error reporting, the compiler doesn't even care about individual files. Think about scenarios like code in one file referring to code in a sibling file, or even partial classes. The compiler generates multiple script files for each set of sources - specifically happens to be a cross product of flavor (normal, minimized, test) and locales (for each locale-specific resx in the project).

As such the mapping is not 1:1 but rather N sources:M scripts or 1 project:M scripts.


Hmm... OK. I see what you're saying. I appreciate your patience as I try to wrap my mind around all of this. What I am suggesting would be tantamount to an ".il" file being attached to every .cs file in a project, as that is what the .cs file gets compiled to when the .dll is created.

Which is no good. :) I would argue that the .js that is created is the same. At the end of the day, when I build an application -- whether it's script or otherwise -- its final form should be transparent to me as the developer. And it is in every way in the development universe until you get to JavaScript (which obviously Script# is attempting to address).

I guess at the core here, my primary concern (and frustration) is the apparent divergence between "script-based development" and the consistency that exists with every other language in the .NET universe.

When I build an application, I don't want to worry about managing reference paths (i.e.


Yes, go ahead and share a more concrete representation of what you're after from an experience point of view.

A few things to add that provide some context here:

It has never been the goal of script# to hide the javascript. In fact hiding it or abstracting it away would likely be an anti-feature for many. The reality is you need to interact with the source in many scenarios: debugging (as has been covered), deployment (along with other existing scripts you reference), handing generated script to someone who is going to them manually, script combining etc.

The point is script# is one tool in a large ecosystem of workflows, frameworks, tools, and host environments. The common language, or mechanism of integration, is the javascript. You can combine things at the javascript level, produce javascript, or consume/execute javascript. As such the script is quite in front of the developer stitching different things together to achieve their goals... and hiding script (for example, packaging it in the produced assembly, and written out to the response) is possible, but comes at the expense of not integrating well with the larger ecosystem.

You'll see script# tries to apply .net and c# concepts where they make sense. For example, project to project references just work, and you don't have to manually copy around scripts.


I see. Thanks for the perspective. Being a traditional Windows developer, I'd rather never ever see Script... I'd much rather work with the languages that make sense to me and have the compiled deliverables be transparent to the experience. Much like how IL is handled in the compilation process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.