flaub / dotweb Goto Github PK

I'm still not happy with the current approach

Currently, developers will reference the mscorlib assembly in their own Script assemblies. This is required right now so that Hosted-Mode works properly. However, this prevents the compiler from reporting errors for methods and types that are not supported by the DotWeb.System.

I've experimented with having script developers reference a separate DotWeb.System assembly by using the /nostdlib+ option. Hosted-mode requires real object and reflection services from the dotnetfx. So there is a conflict here. I've tried 2 things to fix this issue:

• Compile-time build of a 'twin'. This version of the assembly references mscorlib instead of DotWeb.System. The problem with this approach is how to deal with nested references and how to get all of their dependencies to be properly loaded only by hosted mode.
• Run-time modification of assembly references, creating a 'twin' assembly on the fly. The current version of Mono.Cecil.Pdb doesn't produce pdb files that work with Visual Studio, which is a deal-breaker for hosted-mode (debugging being the most important aspect).

An entirely different approach would be to have a separate compile step that would be to verify and report errors in case a developer did reference an unsupported type or method. Preferably this check would occur during compile time, but it could also occur only in web-mode when the translator tries to do it's thing.

A compile step would probably mean a custom build task. It would attempt to build the target assembly using /nostdlib+. The output could either be safely ignored, or it could be merged into the target assembly so that the translator could be simplified (removing the need to treat the System.* specially).

If i create a simple delegate like Action and call it:

Action action = ()=>Global.Window.alert("test");
action();

DotWeb generates:

action.Invoke();

Instead of

action();

Error types in javascript need to be wrapped in a way that their interface is .NET-like. This is needed to support catching native javascript errors with .NET catch clauses. These wrapped types should be derived from System.Exception so that a catch(Exception) will properly catch all exceptions.

I'm not sure why this is happening. One possibility is that the server's thread is being aborted because the client might be reloading the plugin on start.

A workaround for now is to simply refresh the page, this causes the plugin to connect successfully.

A possibly solution would be to have the client be resilient to connection failures by trying to reconnect to the server. It also might make sense to have the client connect to a well-known port on the server side, so that the plugin loading can be downloaded and executed ala ajax.

If i create the following class (here a simple wrapper for native jQuery):

namespace jQuery13
{
[JsNamespace]
[JsIntrinsic]
public class jQueryTest : JsObject
{
public extern jQueryTest(Document document);
}
}

and then call it like this:

new jQueryTest(Global.Document);

DotWeb puts the namespace in front of the call in generated Javascript.

new jQuery13.jQueryTest($doc);

Since jQuery have no namespace in front if it, this call dose not work.

Will add a test case for this soon. For now the DotWeb.Translator.Test/TranslationTest/Callback unit test shows that a throw is causing an errant break; to be emitted.

The following simple class will generate a wrong lambda declaration.

public class Class1
{
    public void Call(Action action)
    {
        action();
    }

    public Class1()
    {
        Call(() => Global.Window.alert("test"));
    }

}

Will generate this:

Web.Script.Class1._.ctor_b__0 = function() {
$wnd.alert("test");
};

Since javascript doesn't have a char native data type, we'll need to emulate it somehow. The closest analog is either an integer or a string with a single element. Neither of these are exactly what a .NET Char type is, and this causes problems when trying to use APIs that take char types.