Fun fact, the Mono Linker project started 10 years ago during the second edition of the Google Summer of Code!
It was originally used to reshape the entire Mono class library into a subset to expose the Silverlight class library API surface for Moonlight.
It was then used to link iOS and Android applications in MonoTouch and Mono for Android, and Xamarin continued to use and improve it.
The Mono Linker has an open architecture making it reasonably easy to customize how it processes code , and detect patterns specific to each platform to link them away. Xamarin added linker steps to do more than tree-shaking, and remove dead code inside methods. For instance:
if (TargetPlatform.Architecture == Architecture.X64) {
// ..
}
The entire if body can be removed if the linker knows that TargetPlatform.Architecture will not be X64.
And now, it's the base for the .NET Core linker. Quite a journey!
The «immediate» experience is pretty awesome. You just open the web page and you're playing.
It takes longer to download, probably the size of the engine and the assets, but I've been very much impressed with the Unity3D WebGL export of this FPS:
It's pretty cool to see .NET catching up with Mono on that front ;)
Fun fact, MonoTouch applications are built with a very similar pipeline, except that LLVM does the compilation in the end.
The steps 4 and 5 in the blog post map quite exactly to the Mono.Linker and the Mono.Tuner. Both tools are using a XML file format for whitelisting pieces of code that need to be included, that's useful if you're calling code with reflection at runtime which is not statically discoverable at build time.
I've been using this since the beta. The entire code of my startup is on GitHub so it really helps to be able to monitor and triage incoming changes quickly.
The app itself is still missing some things for my particular workflow: I'd like to have visibility on incoming code that's not part of pull requests. Like simple pushes to branches.
I'd also have the possibility to unsubscribe from repos directly from the app.
> It is my company, my private property. I should be able to do as I please with it as long as don't mess with other's freedom, this is a constitutional right in the declaration of human rights, private property is sacred.
No you should not, and no, that's really not what the declaration of human rights is about.
When you create a french company your create a “personne morale”, a legal entity, an entity on its own, that is viewed more like a living entity and not like an inanimate object. You do have rights on this entity, but you do also have obligations, not the least of which is to follow the law.
So no, just because you want to you can't employ underage kids for instance.
And just because you want, you can't just fire people at will without reasons.
One could argue that laws could be improved, but that's really not the point you're making.
You can add a post build task to your csproj to run Mono's pdb2mdb, you'll have a .mdb debug symbol file that Mono can use, and you'll get line numbers in stack traces.
As a long time fan of C# and how it evolved (started with .net beta 1), and even more so of Roslyn, I for one would be very disappointed to see C# not being considered from Microsoft as I consider it.
Good luck in your next position, I heard that Coverity for .net is using Cecil :)
Huh, I'm definitely not going “all conspiracy theory” on you. And by you I guess I mean Microsoft?
The perception from the outside, or let say, my perception, is that both .net and C# along (C# being the flagship language for the platform) don't have the same place in Microsoft's strategy than they had say 4 years ago.
Eric being one more visible .net profile leaving Microsoft, I'm just saying it's interesting to wonder if that's related.
they're looking for someone to work on a C# to native code compiler. Even if .net as a VM and the C# to IL compiler are far from gone (and probably never will be), it doesn't look like C# and .net are in favor at Microsoft nowadays.
Given the very sad state of the extensibility of Visual Studio (I wrote about it earlier this year http://evain.net/blog/articles/2012/02/27/visual-studio-your...), it turns out that not only are the Python Tools an excellent plugin to write Python code in VS, it's also one of the best example of how to implement support for a new language or a debugger in Visual Studio >= 2010.
Some things we do in my product would not have been possible without having access to the source of the Python Tools (which again say a lot about the sad story of extending VS).
Shameless plug, if that's still too much work for you, you can contact my company to integrate your language in VS.
We're currently using FastSpring but both the recent opening of Braintree towards Europe and the price getting a clear 2.9% + $0.3 are making it pretty interesting.
Make a similar promotion for Europe and I'll probably switch.
Obviously I failed at conveying my point. Greatly sorry about that.
I think it's mad that in 2012, it's so hard to extend Visual Studio using C# and .net.
I'm not saying it drives .net developers away. I'm saying it hurts the .net platform as a whole.
Would VS's extensibility be easier, with better APIs and documentations, we would see a lot more third party plugins to improve our programming experience with VS.
It was originally used to reshape the entire Mono class library into a subset to expose the Silverlight class library API surface for Moonlight.
It was then used to link iOS and Android applications in MonoTouch and Mono for Android, and Xamarin continued to use and improve it.
The Mono Linker has an open architecture making it reasonably easy to customize how it processes code , and detect patterns specific to each platform to link them away. Xamarin added linker steps to do more than tree-shaking, and remove dead code inside methods. For instance:
The entire if body can be removed if the linker knows that TargetPlatform.Architecture will not be X64.
And now, it's the base for the .NET Core linker. Quite a journey!