3 ms·

This doesn't sound right. C# has always been a compiled language (to MSIL), from the earliest versions of .NET.

by orphea 3y ago

xen0 3y ago
But 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 ago
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.
- sacrosancty 3y ago
  [dead]
junon 3y ago
Never said the source was used to run the program. It was included for debug builds.
- orphea 3y ago
  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").
  - junon 3y ago
    Back 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
      - junon 3y ago
        Nope. I explicitly remember the source code being there.
        orphea 3y ago
        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.
        teh_klev 3y ago
        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.
        junon 3y ago
        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.
- teh_klev 3y ago
  > It was included for debug builds. 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. [0]: https://learn.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://learn.microsoft.com/en-us/dotnet/framework/tools/nge...

This doesn't sound right. C# has always been a compiled language (to MSIL), from the earliest versions of .NET.

by orphea 3y ago

This doesn't sound right. C# has always been a compiled language (to MSIL), from the earliest versions of .NET.

xen0 3y ago

But 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 ago

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.

sacrosancty 3y ago
[dead]

junon 3y ago

Never said the source was used to run the program. It was included for debug builds.

orphea 3y ago
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").
- junon 3y ago
  Back 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
    - junon 3y ago
      Nope. I explicitly remember the source code being there.
      - orphea 3y ago
        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.
      - teh_klev 3y ago
        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.
        junon 3y ago
        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.
teh_klev 3y ago
> It was included for debug builds. 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. [0]: https://learn.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator https://learn.microsoft.com/en-us/dotnet/framework/tools/nge...