What components end up in the compiled EXE ?

What components end up in the compiled EXE ?

• Thomas Madsen

  The referenced DLLs are not merged with the exe regardless of the namespace. If you want to construct a single .exe containing all referenced assemblies then you can use ILMERGE from Microsoft to do it.
  
  Even using ILMERGE you will still only create a .exe with all your own DLLs in it, it will still refer to other DLLs that are part of the BCL.
  
  
  

• Erik M

  dll means dynamic link library. Because it is loaded from a different file inside an exe at runtime. What you're talking about is static linking and has nothing to do with .NET.
  

• Giminiani

  I'm not sure what that has to do with my question.

  I can make DLL's in .NET

  I can make EXE's in .NET

  If I reference some .NET DLL's I have made in my main project, and I compile that project into an EXE, where do those DLL's go As far as I know, I can deploy the EXE without the DLL's it referenced and it works fine. So where is the information coming from to make the EXE work Are the DLL's being compiled into the final EXE

  
  
  

• Vikas Dhevarshetty

  Hi There,

  Dll's which are a part of the system namespace end up to be a part of the exe. If you are trying to refer any other dlls (.Net or COM), then they need to be a present in the output path. If you are making a setup project they are automatically copied to the application path on installation (if you have chosen primary output) . Bottom line is such dll's need to be present in the application path for the application to run.

  Regards Sandeep.

  
  

• DarkPressure

  But if I deploy an exe that referenced 3 DLL's that I made, doesn't the information from those DLL's get compiled into the EXE, because the client doesn't need to have my referenced DLL's in order for the program to work (correct ) all they need is the compiled EXE.

  
  
  

• m.schlestein

  well if these dll's are external from the framework, then you will have to include them with your deployment/setup/installation otherwise the application will not run when referencing those dll's

  Are you able to elaborate a bit more

  
  
  

• chrisanderson

  The dll's which are part of the system namespace DON'T end up to be part of the exe. Yes, sure you can deploy the exe on another PC without the system dll's because these dll's are already installed on that PC (when you installed the .NET framework). And you need to deploy all the dlls which are references directly or indirectly by your exe which aren't net framework system dll's.

  So, as a conclusion the dlls (system or not) are not linked (compiled is the wrong word) in the actual EXE.

  There is a pretty famous article wrote by Joel couple of years ago "Please sir may I have a linker" http://www.joelonsoftware.com/articles/PleaseLinker.html

  There are couple of tools which are supposed to do the job of linking - you can search with ".net linker" as keywords ... I don't know how good they are.

  
  

• Icanos

  Assembly.GetReferencedAssemblies will return the assembly references embedded in the metadata (you can see those using ildasm). Assemblies are separate files, they are just referenced from another assemblies. So they need to be available at runtime.
  

• giflen

  I'm looking for an explanation of what actually ends up in the final exe's metadata as far as what dll's were used to make the exe.

  I assume that you could start a new project, add references to a bunch of DLL's that you created, and then build the project. Well, when you build, you get one EXE regardless of how many DLL's you're referencing... correct So what happens to all the code and metadata in those DLL's you referenced, does it all get compiled into the final EXE or what.

  I want to be able to have code in the program that I can choose to activate at any time (perhaps via a menu item) that will tell me exactly which DLL's were used to make that final EXE that is running.

  Thanks

  
  
  
• What components end up in the compiled EXE ?