4 ms·
I remember when the entirety of your C# binary would include the source code, and back before the concept of Release or Debug was prolific enough, closed source
by junon 3y ago
I remember when the entirety of your C# binary would include the source code, and back before the concept of Release or Debug was prolific enough, closed source C# binaries would be distributed in Debug mode erroneously, allowing someone to extract pretty much a 1:1 replica of the codebase.
Just a fun anecdote. I don't know if this is the case anymore.
- landr0id 3y agoI don't think it ever included actual source code, but .NET IL is just so rich that it made it extremely trivial to decompile, no?
- junon 3y agoIt indeed did, you could open up the .exe in notepad for example. It was all there.
- orphea 3y agoThis doesn't sound right. C# has always been a compiled language (to MSIL), from the earliest versions of .NET.
- xen0 3y agoBut that doesn't mean the source code wouldn't necessarily be exuded in a debug build. I don't know the truth of the original statement, but it isn't too unbelievable.
- pjerem 3y agoThis does sound unsurprising if you talk about a debug binary. It would allows you to debug it with the original source code. You are not supposed to run debug builds in production. But nothing will prevent you from doing it. Production binaries of course doesn’t embed any source or debugging symbols. It’s like erroneously shipping source maps files into your front end production build. It shouldn’t happen and it’s not necessary, but it’s just one configuration variable away so it happens a lot.
- sacrosancty 3y ago[dead]
- junon 3y agoNever said the source was used to run the program. It was included for debug builds.
- orphea 3y agoSorry - I wasn't able to convey my thought. There was no reason for the C# compiler to include the source code into the binary. Into the debugging symbols (which is a separate file) - maybe..? Anyway, I went ahead and compiled a debug app on .NET 1.1. The binary does not include the source code. And neither does the PDB. It includes a file path to the source though ("Visual Studio Projects\ConsoleApplication1\Class1.cs").
- junon 3y agoBack then things were different. I'm talking c. 2008.
- orphea 3y ago.NET 1.1 is 2003, should be "back then" enough. When compiled with VS 2008 and .NET 3.5, the binary does not include the source code either. You might confuse readable parts in the binary with the metadata. [0] https://stackoverflow.com/q/65699183 https://stackoverflow.com/q/65699183 [1] https://stackoverflow.com/q/4700317 https://stackoverflow.com/q/4700317
- deleted 3y ago[deleted]
- magicalhippo 3y agoI can't recall this from C#, though I only started using it when .Net 1.1 was released. I do recall good old Visual Basic did this though, as it ran interpreted. The executable it generated was just a small loader with the source code appended.
- majikandy 3y agoI remember this too. Actually I (maybe incorrectly)think release builds contained it too. You used to have to actively obfuscate to make sure it was protected. I definitely used decompilers and got great results with very readable code that felt very close to the original.
- junon 3y agoThat could be, actually. I don't know if it was release or just debug, but I remember obfuscation tools definitely being a thing, in large part because of this.
- orphea 3y agoMSIL is easily decompiled back to C# (or VB.NET if you prefer), it has always been a thing, yes. But binaries never included the source code.
- junon 3y agoI am perfectly aware of what IL decompilation is. I've written a decompiler before before. That's not what was happening.
- moron4hire 3y agoThere was never a time when the distinction between Release and Debug was not "prolific".
- junon 3y agoYes, there definitely was.
- moron4hire 3y agoMaybe if you started life as a VB6 developer. But your original post especially doesn't make sense because the default Debug configuration has always put the debug symbols in a separate PDB file. So even if you were arguing that early C# developers didn't understand how to use their tools, they wouldn't have had the source embedded in the EXE.
- junon 3y agoI guess I'm lying then. :)
- masterofmisc 3y agoI think you may be miss-remembering.
- daigoba66 3y agoYou’re probably thinking of debug symbols, i.e. the PDB file that is generated alongside the binary. You can generate this for both Debug and Release builds (should be on by default in fact). It’s super useful for debugging crash dumps from production, and for exception logging in web apps. You can think of this like a source map, but only files and line numbers.
- nazgulsenpai 3y agoAt least according to the format and specification since VS 2005, .NET 2.0, the assembly format has been consistent and doesn't have any section for source code. It has always been trivial to load an assembly in something like dnSpy or another IL Disassembler and generate C# code and patch .NET assemblies. At least in the versions < 5. https://learn.microsoft.com/en-us/dotnet/standard/assembly/file-format https://learn.microsoft.com/en-us/dotnet/standard/assembly/f...