Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Microsoft rewrote its C# compiler in C# and made it open source (2017)

medium.com

Post reply on HN
Print view View original

21–30 of 136 posts

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#21

Post by rafaelvasco »

moron4hire wrote: post #14
rafaelvasco wrote: post #9

Earlier quoted context omitted.

At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's ju…

DLL Hell doesn't refer to "lots of DLLs", it refers to conflicting versions of DLLs not being easily manageable across multiple applications. Outside of putting assemblies in the GAC (which was always a hack of last resort anyway), .NET has never had "DLL Hell".

Yeah, lots of assemblies is kinda like .NET dll hell ;) .NET Core had this problem in earlier versions. Not anymore;

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#22

Post by rafaelvasco »

fultonfaknem42 wrote: post #17
rafaelvasco wrote: post #9

Earlier quoted context omitted.

At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's ju…

Maybe Assembly unloading, in which case if you wanted to swap out new dlls in memory you'd have to tear down the process and restart it. Definitely not sexy. That being said: I think Assembly Unloading is a thing now (and AppDomains don't exist in .NET Core last I heard).

Yeah, if I remember correctly it's indeed a thing in latest versions of .NET Core;

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#23

Post by rafaelvasco »

thrower123 wrote: post #16
rafaelvasco wrote: post #9

Earlier quoted context omitted.

At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's ju…

Roslyn is very powerful, but it is still pretty cumbersome. At one point I spent quite a while trying to get a game scripting system akin to the way that Lua is commonly used working, and I just couldn't get it working fast enough to be viable. I essentially wanted to have a core C# engine that provided services, and then have it call an initialization function and a gameloop function that were defined in designated…

Well, it's not cumbersome at all. The problem is really lack of real documentation and most importantly real world examples; About the performance, if you use the real scripting support for Roslyn , yeah, I think you'll have bad performance. But if you compile the code to memory at runtime and execute it like I did, it's pretty fast;

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#24

Post by WorldMaker »

moron4hire wrote: post #14
rafaelvasco wrote: post #9

Earlier quoted context omitted.

At some point I wrote a barebones scripting system using roslyn for a project of mine. At runtime I got a piece of code compiled to a DLL in memory and then executed this DLL; Worked well; But at that time there was no support for destroying AppDomains or something, don't remember the exact name. Still pretty fun; But yeah, there's no real complete documentation anywhere; And the DLL hell was real. Dozens of DLL's ju…

DLL Hell doesn't refer to "lots of DLLs", it refers to conflicting versions of DLLs not being easily manageable across multiple applications. Outside of putting assemblies in the GAC (which was always a hack of last resort anyway), .NET has never had "DLL Hell".

Yeah, the closest .NET equivalent is Binding Redirection hell, and NuGet and Visual Studio and .NET Core have spent years of work making that better than it was at its worst in the early NuGet days. There's a couple of low level APIs that are still annoying problems to redirect if you need to support particular sets of .NET Framework and .NET Core, but beyond that a lot of it is managed for developers automatically these days.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#25

Post by fultonfaknem42 »

rafaelvasco wrote: post #22
fultonfaknem42 wrote: post #17

Earlier quoted context omitted.

Maybe Assembly unloading, in which case if you wanted to swap out new dlls in memory you'd have to tear down the process and restart it. Definitely not sexy. That being said: I think Assembly Unloading is a thing now (and AppDomains don't exist in .NET Core last I heard).

Yeah, if I remember correctly it's indeed a thing in latest versions of .NET Core;

This looks like a pretty cool demonstration of what we're talking about: https://www.strathweb.com/2019/01/collectible-assemblies-in-...

See the section titled: Collecting a dynamically emitted assembly

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#26

Post by [deleted] »

alexlesuper wrote: post #11
nudpiedo wrote: post #8

I find amusing how microsoft moved from the closed source referent in the industry into such an open source player. Right now even allows to hook some of their tools and platforms to its competing platforms and tools.

I think they are really repositioning the company as powering general computing through their cloud platform as opposed to powering general computing through their OS.

[deleted]

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#27

Post by m0xte »

nudpiedo wrote: post #8

I find amusing how microsoft moved from the closed source referent in the industry into such an open source player. Right now even allows to hook some of their tools and platforms to its competing platforms and tools.

Their intent is still entirely market share. We need to be vigilant on how they get there. History has taught us a lot of lessons we seem to have forgotten because shiny and new layer of marketing. There is still a massive cultural and technical impedance mismatch.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#28

Post by thrower123 »

Ididntdothis wrote: post #12
alexlesuper wrote: post #11

Earlier quoted context omitted.

I think they are really repositioning the company as powering general computing through their cloud platform as opposed to powering general computing through their OS.

I think they will slowly turn into IBM. Maybe a better version of IBM though.

I hope that they have no interest in becoming a global services company...

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#29

Post by thrower123 »

moron4hire wrote: post #13
eropple wrote: post #5

Earlier quoted context omitted.

Personally speaking, I'd love to, but I'd then have to figure out how to make them work with an IDE. I'm very tired of waiting for record classes to show up and I could have written a (to be clear: inferior ) set of stuff around regular classes that magics one into "everything is readonly and we autogenerate a `copy` method", much like Kotlin does for its data classes...but my IDE isn't gonna understand it unless I d…

I'm not sure that it would be that difficult with Roslyn and Visual Studio these days. There are Roslyn-based syntax-highlighters and linters and snippet-generators and code-transformers. I use one for making sure all of my code is not just formatted the way I want it, but auto-inserting "readonly" modifiers for fields that don't get re-written outside of the constructor, one that treats not implementing IDisposable…

What is the name of that IDisposable checking one? That sounds very, very useful.

Re: How Microsoft rewrote its C# compiler in C# and made it open source (2017)

#30

Post by m0xte »

fultonfaknem42 wrote: post #3

I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.

From my perspective I’d love to but from writing c# for nearly 20 years now it’s a rough ride for anyone trying to keep up with the platform. Knowledge is thrown in the trash faster than you can learn it and direction changes of all sorts jump on you. I’m not in for investing my time in that any longer.
Post reply on HN