Std lib replacement support like in Script# about jsil

[kg]

This should already work if you compile your app against their replacement libraries, but I haven't ever used Script#. Am I missing specific features you need in order to do this? It sounds like you want modified behavior in Visual Studio, and JSIL currently has no interaction with VS.

[lanwin]

Sorry for my previous deleted entry. Used the wrong tab.

In every C# project you can disable the automatic referencing of mscorelib via Build->Advanced->"Do not reference mscorelib.dll". If you do that you get a lot errors, since the C# compiler needs some basic classes like object, string, int32 to work. No you could provide your own JSILCoreLib which provides a basic impl/proxying for that. If you do that you make sure that VS could only provide intellisens for classes which are existing not for something like AppDomain which can not exist in JS.

[markusjohnsson]

Is there a specific feature JSIL has implement for this issue?

I guess what is needed is to replace/extend JSIL.Bootstrap.js & proxies with a C# assembly that would replace mscorlib?

[markusjohnsson]

I've started hacking on a mscorlib replacement. It does not work yet, but if anyone is interested it can be found at https://github.com/markusjohnsson/JSIL/tree/jsil_corlib
At least you can build everything (only the Meta & Proxies assemblies reference JSIL.Corlib), but I've not got too far with actually running anything. My initial thought was to merge the Proxies, Meta and (parts of) JSIL.Bootstrap.js and requiring JSIL projects to link to JSIL.Corlib instead of mscorlib... however, there are some things I haven't really thought about yet: how to handle cases where we actually want to provide a proxy to a third party assembly that links to mscorlib, like Kevin is doing with XNA?
Please post any thoughts or comments, will probably hack some more on this during the weekend.

[kg]

Meta needs to be a separate assembly because it contains attributes used by JSIL itself. It's possible to have those attributes be within the proxy library, I suppose, but that makes it a heavier dependency and means that JSIL can never actually reference the attribute types directly. Making it heavier is also bad since any native .NET app that uses the attributes would still have to ship that library in its native form.