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.
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:
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.