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.
You’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.
This 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.
Sorry - 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").
The cool thing about being in 2023 is that you don't have to believe me. Winding up a Windows XP virtual machine with Visual Studio of your choice takes 15-20 minutes.
This was likely ASP.NET code. In the early days many folks just FTP'd their whole ASP.NET project folder to IIS, including the source code (e.g. .aspx.cs code behind etc) when you didn't need to. There was a lot of misunderstanding about how to deploy ASP.NET applications, many folks were still working with a Classic ASP mindset. I speak from experience as my company's .NET go to engineer and developer for a shared hosting company back in the day and having to explain to customers how to deploy their apps sans the source code.
No, it wasn't lol. I wish people would stop telling me what I very clearly remember. I did a report on this in high school - how C# programs (desktop programs) could have their source recovered under certain build conditions.
> how C# programs (desktop programs) could have their source recovered under certain build conditions.
Yes, using a tool such as .NET Reflector, but the source was never embedded in the compiled binaries, or anywhere else if you were competent with the toolchain.
I've worked with .NET since the pre-1.0 betas back in ~2001 (I know...appeal to authority). The source code was never included in .NET debug or production builds. You could however use tools such as .NET Reflector (now owned by RedGate) to decompile the IL and reconstruct code as C#, VB etc. If you had the PDB files then you also had the symbols and could decompile to a close representation (variable names) to the original source.
This was a very useful feature because the .NET Framework managed code DLL's were and still are shipped obfuscated. This meant you could in the early days use ILDASM, and then .NET Reflector to find out what was going on inside the .NET Framework code.
Of course this created a market for obfuscators so that commercial and paid for shipping code was more difficult to reconstruct (especially since you wouldn't have the PDB files available).
You could do pretty much the same thing with Java.
Now if your binaries were NGEN'd [0], your chances of reverse engineering were reduced considerably because the IL is now gone and you're working with pre-compiled machine code rather than pre-JIT'd IL.
At 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.
I 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.
That 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.
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.
I 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.
Just a fun anecdote. I don't know if this is the case anymore.