This is a technical post for software engineers of jsc.
There is this new assembly in jsc installation ScriptCoreLib.Ultra.Components. The Ultra keyword hints that you are dealing with code that can possibly run on any target platform. The ultra assemblies will be merged on demand just before handind them over to the back end compiler. Within the Components assembly I have defined a new component. I wish to be able to use it in a custom application. It should work. But it does not. In this post I will document how I go about killing that minor bug. Yes it is sunday.
So where to start?
I have created a new test project just to define a new flash object and show it on the page. The flash object will inherit from SaveAction defined in ScriptCoreLib.Ultra.Components.
In the picture above you can see that the base class is defined as abstract and has a FileName property and methods to add files. What this SaveAction component is good for is that it will allow me to save a file from the web page to the user’s disk. Currently I have to define the flash object in the custom application, due to implementation limitations. In the future the flash objects can be defined in the referenced assemblies where the developer will be able to simply reuse them without inheriting from their implementation as I have to right now.
Great. Let’s define our local flash object.
Notice that we are inheriting from SaveAction. Also notice that we have a method WhenReady which just yields. This method is important because it will enable us to continue whenever the flash object is finally loaded in the web page.
So we have defined our local version of the flash object. Without going into details just yet I can say that in the application I am going to use a javascript component and extend it with this new flash object.
The important method here is the AddSaveTo method which is defined in the ScriptCoreLib.Ultra.Components. What makes this method different is that this method does not know your local flash object type. Instead it is expecting a generic type which inherits Sprite and implements ISaveActionWhenReady interface. If the compiler worked we would be done by now. Then again things just are not that easy are they.
In this post I am actually working on fixing this nasty bug.
Let’s build our test project.
script : error JSC1000: emmiting failed : Method ScriptCoreLib.JavaScript.Components.VisualStudioViewExtensions.AddSaveTo: type argument ‘UsingComponents.InternalSaveActionSprite’ violates the constraint of type parameter ‘T’.
Great we got an error. It looks like jsc messed up somewhere with generic rewrite and type erasure. What jsc does is when it splits the application to javascript and flash then our local flash object will inherit from a proxy object inside javascript context. Every time the project will reference a Sprite in javascript context it must actually reference the proxy.
Let’s fire up reflector to see what has jsc generated.
We are looking at the javascript version of the ultra application and we can see that our local flash object has changed its base type as expected. What about this AddSaveTo method which had a generic constraint on the Sprite type. In javascript context we do not have a type Sprite. As such if the front end were not able to successfully replace the types the back end would have a serious problem with the unavailable type.
As we can see the jsc front has been unable to replace the Sprite type reference. I have to find out why. Is it because we are merging different assemblies? There are actually two problems with this AddSaveTo method.
- The generic constraint has not been replaced.
- The generic parameter has been replaced with non generic parameter.
I will prepare a rewrite test project with similar method signature to see if the rewriter is acting correctly on its own.
The post build event I am using is:
c:\util\jsc\bin\jsc.meta.exe RewriteToAssembly /assembly:”$(TargetPath)”
Looks like I forgot to attach the generic parameter constraints.
The rewriter works as expected. Let’s continue to use this AddSaveTo method via project reference. I will add a new test project and add a reference to the current project.
Did I mention I really dislike when Visual Studio comes unresponsive or makes me wait in the Add Reference dialog?
I added the same post build event. Let’s use the AddSaveTo method and see what gets rewritten.
The rewriter did not merge them. We want the two assemblies to be merged. To do that I will add an assembly level attribute.
After building I get this:
Unhandled Exception: System.TypeLoadException: Could not load type ‘GenericConstraints.ISaveActionWhenReady’ from assembly ‘ClassLibrary1.dll.Rewrite, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null’.
It would be awesome if we were actually told the reason why this error happens. Now I have to debug 
Can I assume that a generic constraint type must be created before using it as such? Or shall the rewriter apply generic constraints after all types are created?
After a small modification to jsc, the test project now builds as expected.
Let’s retry building the original test project. Yay! Fixed. I hope everything else still works
In the picture above you can find the save button we just added.
Here is the output from updated rewriter where the two problems outlined before are now fixed.
Thank you for your attention. More cool stuff to come!
