Super-sized SnippetCompiler on the way
I'm heading out of town on the weekend, so I thought I'd give a last call for requests for the next version of SnippetCompiler. I had some free time tonight and added a bunch of the most recent requests and in doing so wound up rewriting a good chunk of it, so I won't be releasing it until I can test all of the wacky new permutations.
- Added a “Start All“ feature which compiles all of the snippets into an EXE and runs it, so long as they're all the same language.
- Added ASP.NET support. Single page ASPX files are run immediately, as compilation is done in the server process. (You can use IIS, Cassini, or anything else that serves ASP.NET.)
- If “Start All“ is selected on an ASPX file and other snippets exist, all other non-ASPX snippets are compiled and placed on the web server.
- ASP.NET codebehind is supported in this configuration. Since the ASPX pages are compiled on the server and are language-neutral during SnippetCompiler's compile, you can have different languages for your pages and their base classes.
- Likewise, pages can reference classes in the other snippets. The syntax for this isn't something people use every day, so I'm creating some sample files: a VB codebehind for a C# web page that then creates and calls a method on a VB object.
- Added a “Generate debug symbols“ option. This was always enabled previously, but source was compiled in memory, so there were no source files to reference if an exception or breakpoint was hit during execution.
- Source files are now persisted on and compiled from disk, so the above situation will result in the debugger displaying code.
- Added a “Run from Command Prompt“ option, so when the process terminates you're left with its output rather than having the window disappear.
- Many other minor requests.
If anyone knows of a better textbox control, please let me know. Using the standard textbox really makes using SnippetCompiler unpleasant.