Archives

Archives / 2009
  • Installing FMStocks 1.0 on later platforms

    My latest version ASP Classic Compiler can now run FMStocks 1.0, an end-to-end sample application. I have uploaded a version of FMStocks at http://aspclassiccompiler.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=98236. The version that I uploaded already has the web.config file as well as the bin directory containing the necessary dlls. To run it, you need to map a virtual directory to the website directory. Use IIS manager to map the ISAPI dll for the .asp extension to the same DLL used by the .aspx extension on your virtual directory. You still need to create the database and register the COM objects. Since the setup program was written for Windows 2000/SQL Server 2003, it may not work correctly for later platforms. The following procedure shows how to install them on a later platform manually.

    1. To install the COM objects, just use regsvr32 to register the FMStocks_Bus.dll and FMStocks_DB.dll in the objects\Distribution directory.
    2. To create the database, first useISQL to open the schema.sql file and run it. This will create the database, login and the tables. Note that your sql server must be in mixed security mode.
    3. Next, open Create 10,000 test accounts.sql with ISQL and execute it. This will create the sample accounts.
    4. Lastly, use import feature to import the data in rawdata.mdb into the stocks database.
  • ASP Classic Compiler 0.6.0 released. It can run FMStocks 1.0

    I uploaded ASP Classic Compiler 0.6.0 to http://aspclassiccompiler.codeplex.com. We reached a small milestone: it can run Fitch and Mather Stocks 1.0 now. This is the first end-to-end example that we can run with ASP Classic Compiler. Our goal is to be able to run most of ASP classic applications under ASP.NET without modifications, but we actually need to make two minor modifications. Both cases are due to the difference between interpreter and compiler. With interpreter, you can have syntax error in dead code (unreached code); with compiler, the entire code has to be syntactically correct for the code to compile.

    The first change is at t_head.asp line 71, we added "dim i". That is because we have undeclared variable when the option explicit is on. Since the procedure was never executed, the ASP interpreter never caught the error but we have to fix it for the ASP Classic Compiler.

    The second change is at SellStockAction.asp line 17. We added  "dim m_strMainPrompt". Again, this is an undeclared variable. Since the “on error resume next” is on, the VBScript interpreter would actually skip over the syntactical errors but the code will never work correctly. For the compiler, “on error resume next” cannot trap compilation errors.

    In addition, several pages use @Transaction declaration. They are ignored since we do not have Com+ transaction support at the page level. Transaction for objects in Com+ packages are supported. 

    I have uploaded preconfigured FMStocks with web.config and .net DLLs to http://aspclassiccompiler.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=98236. It is still necessary to register the COM objects and install the SQL database. Since the setup program was written for Windows 2000/SQL Server 2000, it does not work correctly for the later platforms. I will document how to install it in a later platform in a separate blog entry.

    Here is the plan and call for action:

    1. I will come out with some debugging aid in the next version. Trouble shooting both asp problem and the compiler problem without debugging aid is painful.
    2. The parser is 90% done. If you use ASP Classic Compiler to run your application, I do want you to report all syntax errors so that I can fix them.
    3. The code generator quality is at 60-70% level. I want you to hold on the report of runtime errors until I provide better debugging aid.
    4. I will continue test ASP Classic Compiler using some open source samples/applications. Drop me a not if you have any suggestion.
    5. I originally envision to have class support after the 1.0 release, but it looks like now that I will implement the Class feature before the 1.0 release.
  • Uploaded ASP Classic Compiler Version 0.5.6.34834 to http://aspclassiccompiler.codeplex.com

    With feedbacks from several enthusiastic users, I have fixed many little bugs. Give the latest version a try. Post bugs on the forum as usual. Happy computing!

    I am running into a little bit of difficulty with CLR debugger integration. In order to generate the debug symbol, I need to use LambdaExpression.CompileToMethod(). However, this method does not support DynamicExpression that I heavily rely on. So I am back to research and trying to figure out how to use Microsoft.Scripting.Debugging.dll. In the mean time, I am going to enable tracing in near future so that at least we can figure out problems through tracing.

  • C# 4.0 dynamic and Dynamic Language Runtime presentation at LA Code Camp

    I did a two session presentation at LA Code Camp today to talk about the C# 4.0 dynamic feature and the dynamic language runtime. The presentation materials could be downloaded here.

    The zip file contains the source code of several demos that I did today:

    1. DynamicTest: A simple C# dynamic example.
    2. BoxUnbox: Example demonstrates the boxing/unboxing behavior of C# dynamic variables.
    3. PrivateMember: Example demonstrate that code in full-trust can access private member but it will throw exception when running in partial-trust. A partial-trust sandbox is used to simulate the partial-trust environment in the demo.
    4. MultipleDispatch: This example was from Curt Hagenlocher’s blog.
    5. MOR: This example demonstrates accessing unknown type or dynamic object using dynamic variable. The MOR means minimalist OR Mapper; it converts query results in anonymous types dynamically.
    6. TypeModel: This demo shows how to access static members of a unknown type using dynamic variable. The unknow type is wrapper in the TypeModel object which implements IDynamicMetaObjectProvider interface. The TypeModel class is extracted out of the DLR Symbl example.
    7. DLRTreeTest: This example demonstrate factorial function implemented using System.Linq.Expression (Microsoft.Script.AST in .NET 3.5 version of DLR).
  • Execution Assisted Code Converter

    As I am working on my VBScript.net and ASP Classic Compiler, I came the realization why the existing asp classic to ASP.NET converters do not work very well. The primary difficulty is those converter do not get many type information during static analysis when converting a scripting language such as VBScript to strongly-typed VB.NET or C#. For the same reason, editor intellisence usually does not go very far when editing VBScript or Javascript.

    Executing the dynamic code will bring in the type information at runtime. I think that I just need to enhance my callsite binder to capture some information and then I will be able to convert the code that flow through my binder much more accurately. Mostly likely the converted code should work correctly right away. So I will just give it a name called Execution Assisted Code Converter. I will try to put together a prototype if I get a little bit of time.

    Note: There are refinements to the thought through discussions of this post below.

  • Uploaded Asp Classic Compiler Build 0.5.5.34834

    I just uploaded ASP Classic Compiler Build 0.5.5.34834 to http://www.codeplex.com/aspclassiccompiler.

    In this release, I have:

    1. Setup the infrastructure to map from generated code back to the source code so that we can report the location accurately in asp files. With that, I will be able to provide debugging experience using either Visual Studio or another CLR debugger fairly soon.
    2. If a file has multiple syntax errors, chances are that we are able to report all the errors at once. In contrast, Asp Classic only reports one error at a time. That is because our parser attempts to recover from the error and continue parsing the file. This is also essential for intellisence support in VS integration that will come in the near future.

    The next build will be in two weeks as I am preparing for my presentations at the LA Code Camp right after PDC. I have blocked two sessions to discuss the C# dynamic feature and the Dynamic Language Runtime. My first talk will be mainly on the C# dynamic feature and the second talk will be mainly on the Dynamic Language Runtime. Here are the abstract of the sessions:

    http://www.socalcodecamp.com/session.aspx?sid=ecbdbbc5-844b-4024-9012-b6ad8827546d and http://www.socalcodecamp.com/session.aspx?sid=7af7eb5a-913d-46fb-a3f8-144fdc77ed3c

  • Revisiting ASP.NET logging and tracing solutions

    It has been several years since I researched the logging and tracing solutions last time so I need a revisit. ASP.NET always had tracing that can be turned on at the page level through page directive or the application level through the web.config file. The trace output can be either appended to the end of a page and viewed via trace.axd. ASP.NET tracing is different to System.Diagnostic tracing. Fortunately, ASP.NET 2.0 or later allows integration between the two. Dino has an excellent article on this subject.

    The ASP.NET tracing is most useful tracing events relating to page life cycle. For flexibility in filtering and sending trace data to different target, there are a few logging frameworks available, such as log4net, nlog and the Enterprise Library Logging Application Block. If an application can not be tied to a particular logging framework, then one can either use a common library, or roll your own.

    In .net 2.0 or later, there is actually an enhancement to the static Trace class called TraceSource. TraceSource is quite flexible and it allows filter both on the writer side through TraceSwitch and on the listener side through listeners configuration and filter. For a comparison between TraceSource and other frameworks, see the discussion on stackoverflow. For projects that need to minimize external dependency, TraceSource is an excellent choice. The only limitation to the TraceSource solution is the availability of listeners. .net framework comes with the 10 listeners:

    Microsoft.VisualBasic.Logging.FileLogTraceListener
    System.Diagnostics.ConsoleTraceListener
    System.Diagnostics.DefaultTraceListener
    System.Diagnostics.DelimitedListTraceListener
    System.Diagnostics.Eventing.EventProviderTraceListener
    System.Diagnostics.EventLogTraceListener
    System.Diagnostics.EventSchemaTraceListener
    System.Diagnostics.TextWriterTraceListener
    System.Diagnostics.XmlWriterTraceListener
    System.Web.WebPageTraceListener

    The KUADC project comes with 6 listeners:

    SqlTraceListener
    SmtpTraceListener
    OutputDebugStringTraceListener
    ConsoleTraceListener
    CustomTraceListener
    InMemoryTraceListener

    There are a few other trace listeners such as TCPTraceListener and UDPTraceListener can be found on searching Google.
  • Uploaded Silverlight sample for VBScript.net compiler

    I have uploaded Silverlight sample that uses my VBScript.net compiler to http://www.codeplex.com/aspclassiccompiler. It is available under the source tag in change set 31328 or later.

    I am not quite using the capabilities in Microsoft.Scripting.Silverlight yet. I want to take advantages of it when its document becomes available. For the time being, I created my own little host called VBScriptHost in the SilverlightApplication1 project.

    I modified App.xaml.cs to create an instance of VBScriptHost and expose it. In MainPage.xaml.cs, I created a ScriptScope object. This is the object that I feed host variables to VBScript. I then parse this object to the Execute method of a CompiledCode object.

    In the example, I passed MainPage itself with the variable name "page" to the VBScript. In order to expose the object hierachy of the MainPage, I have to expose MyButton using the x:FieldModifier="public" attribute; otherwise, it is an internal property and is hidden from the dynamic code. In future versions, I will modify my binder in an attempt to access the internal properties so that we do not have to change the access level of objects in the page.

  • Uploaded ASP Classic Compiler Build 0.5.4.34834. This build supports VS2010 and Silverlight.

    As usually, it can be downloaded from the source tab of http://www.codeplex.com/aspclassiccompiler.

    1. This version is built with DLR 0.92. It is compatible with VS 2010 beta 2.
    2. We have resolved all API difference with Silverlight so that Silverlight build of our VBScript.net compiler is available for the first time. We will upload some samples in the next weekly release.
    3. All the binaries are consolidated into the bin folder.

    Going forward, we will stay on DLR 0.92 for a while so that we have a stable build so fix the bugs in core features.