HN user

jbevain

480 karma

Engineering manager at Microsoft, running the Visual Studio Tools for Unity experience.

Founded SyntaxTree a developer tools company doing UnityVS, acquired by Microsoft.

Author of Mono.Cecil and other .net niceties.

Long time Mono contributor, former member of the Mono team at Novell.

* http://github.com/jbevain * http://syntaxtree.com * http://unityvs.com

Posts6
Comments22
View on HN

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!

CIL - just like the LLVM IR - if human readable, is not really meant to be written by hand, unlike Java. Not sure what you mean here.

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.

Vasili Arkhipov 13 years ago

It was “A guy called Vasili Arkhipov saved the world”, a quote from a former NSA director, taken from the first paragraph of the article.

F# end to end 13 years ago

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.

Thanks for the feedback Eric.

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.

One has to wonder if that's not related to how C# and .net are being treated as second class citizens nowadays at Microsoft.

As we saw recently:

http://news.ycombinator.com/item?id=4842024

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.

Oh well, as long as Eric keeps on blogging...

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.

Interesting move. Too bad it's US only for now.

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.

Note that I'm not asking for VS to be rewritten. I actually don't think it would make a lot of sense.

I'm simply asking for good bindings, well documented and respecting the expectations (API wise) of a managed programmer.

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.

I hope it makes more sense if you replace this snippet in the context of the post.

Visual Studio is a great IDE for the .net programmer.

It's terrible as a platform for which you build managed addins/plugins.