Statically linking dependency assemblies
-
Hi Friends I have a console application that produce assembly in .EXE. This app has some dependency assemblies which it reference in the project. Now i want to give my client only the .EXE file. So i want to statically link the dependency assemblies in this .EXE . The Assembly Linker tool(al.exe) only links the modules or the resource files. Any pointer and idea is most welcome. Thanx a lot Naveen
-
Hi Friends I have a console application that produce assembly in .EXE. This app has some dependency assemblies which it reference in the project. Now i want to give my client only the .EXE file. So i want to statically link the dependency assemblies in this .EXE . The Assembly Linker tool(al.exe) only links the modules or the resource files. Any pointer and idea is most welcome. Thanx a lot Naveen
Static linking is not supported by the .NET framework. True, you can combined a few assemblies, but its purely a hack, not static linking in the true sense. .NET is designed around dynamic assemblies that are self-describing. top secret xacc-ide 0.0.1
-
Static linking is not supported by the .NET framework. True, you can combined a few assemblies, but its purely a hack, not static linking in the true sense. .NET is designed around dynamic assemblies that are self-describing. top secret xacc-ide 0.0.1
-
hi leppie Thanx for info. Yes my main requirement is to combine few assemblies into one main assembly(.EXE) nad just give my client the .EXE file. If you the solution or any idea ,please do let me know Thanx a lot Naveen
softp_vc wrote: Yes my main requirement is to combine few assemblies into one main assembly I am curious. Why? What is wrong with distributing a few assemblies? If this was really an important requirement why didn't you build it as one exe in the first place?
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
-
softp_vc wrote: Yes my main requirement is to combine few assemblies into one main assembly I am curious. Why? What is wrong with distributing a few assemblies? If this was really an important requirement why didn't you build it as one exe in the first place?
"If a man empties his purse into his head, no man can take it away from him, for an investment in knowledge pays the best interest." -- Joseph E. O'Donnell Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
-
Hi you are right at your place. But right now my concern is to link the dependent assembly into the main assembly file. Hope any body would be having the idea for this Regards, Naveen
I don't think you understand: it isn't supported. And if you're referring to the .NET base class library assemblies (mscorlib.dll, System.dll, etc.), then I'm guessing you also don't want the client to have the .NET Framework installed, huh? Guess what - that's not possible, either. The .NET Framework is more than just .NET assemblies - it's a complete runtime made up of system components and must be installed. There is a project somewhere on the web that attempts to circumvent this, but all it really does is collect only the required components of .NET for a particular application and install them locally into a directory. It's still the .NET Framework, just a hack and not installed as system components, thus bloating the system. Just like Java requires a JVM and VB6 and lower requires a VB VM (virtual machine), .NET requires the CLR. Colin is right, though: if the dependent assemblies are ones you created, then don't create dependent assemblies and create all the code into one .EXE assembly.
Microsoft MVP, Visual C# My Articles
-
I don't think you understand: it isn't supported. And if you're referring to the .NET base class library assemblies (mscorlib.dll, System.dll, etc.), then I'm guessing you also don't want the client to have the .NET Framework installed, huh? Guess what - that's not possible, either. The .NET Framework is more than just .NET assemblies - it's a complete runtime made up of system components and must be installed. There is a project somewhere on the web that attempts to circumvent this, but all it really does is collect only the required components of .NET for a particular application and install them locally into a directory. It's still the .NET Framework, just a hack and not installed as system components, thus bloating the system. Just like Java requires a JVM and VB6 and lower requires a VB VM (virtual machine), .NET requires the CLR. Colin is right, though: if the dependent assemblies are ones you created, then don't create dependent assemblies and create all the code into one .EXE assembly.
Microsoft MVP, Visual C# My Articles