Automatically linking only referenced components of a managed, C# class collection into a dll or application

A development partner's recent, non-negotiable, platform migration has forced me into .NET 3.5 Compact Framework development for Windows CE 6.0 using Visual Studio 2008.

In other environments, I am accustomed to aggregating a large framework of "feature" classes/modules/etc. into a static library to be linked with smaller bodies of "product configuration" code, in order to generate a variety of application and/or dynamic library images containing only those components actually referenced.

While the static linkage is incidental, the paring of unused code is of critical importance: it satisfies not only footprint concerns, but security requirements in a market where customers view unused code—especially any that might add capability if executed—as an unacceptable vulnerability.

Unfortunately, this seems to b开发者_运维技巧e at odds with the .NET worldview (not to mention solution and project templates provided with VS2008), which appears to favor building DLLs (assemblies, class libraries, netmodules, etc.) to be reused via deployment in entirety. Indeed, information to support this approach is in such vast majority that I am rapidly becoming frustrated trying to find anything contrary.

So, can I accomplish a dead-code paring effect equivalent to the artifacts of static linkage, where source code references to components, coupled with a product or solution reference to an aggregated collection thereof, are sufficient to ensure all and only the required components are included in the deployment?

For example, can a tool like ILMerge accomplish this without significant manual intervention or maintenance overhead (e.g. lists of components other than in client code or a framework-library build configuration) and with only limited explanation to other developers facing even steeper learning curves; or better still, is there some means already present in VS2008?

--

egr

Yes, such tools exist, but are not widely used in .NET.

One tool I've seen mentioned before is Remotesoft Salamander .NET Linker. I haven't used this tool so I cannot comment on its merits beyond what's on their web site:

Salamander .NET Linker and mini-deployment tool allows you to link .NET assemblies together into a single file, and to deploy your application without installation of the whole Microsoft .NET Framework. The linker selectively links MSIL code putting together only the required classes and methods, and it is capable of linking into the Microsoft .NET framework class libraries.

Following are my conclusions based on additional research and on comments and answers received:

1. Without introducing third-party tools my company's development partner will refuse to support, it has become apparent that the only way to produce a closed, fully-utilized, subsystem consistent with customer requirements, is probably to manage the collection of classes included in the final, product assemblies explicitly, in the build configuration, independent of references by other classes.

2. In order to avoid error-prone, manual, parallel modification of source code, it becomes necessary to make presence or absence of referent classes in product final assemblies sufficient to enable or disable the features they support, without leaving dangling references available for exploit.

3. Ignoring for the moment the dangling reference issue, two approaches come to mind: use reflection to find potential referents implementing interfaces known to their prospective referrers; or have potential referents inherits a base class with knowledge of the referrer class. In either case, both referrer and referent must be in the same assembly, and the mechanism must confine itself to that assembly.

4. Since our development partner's system architecture requires not only managed, C# .NET components specific to this platform, but also unmanaged, C++ components that we wish to reuse in their other platforms that neither incorporate C#/.NET nor permit RTTI, the latter approach seems wiser, for the sake of design consistency.

5. Given the chosen approach, a good candidate for the referent base class, in either language, is one nested in the referrer class (and friended in C++, if the compiler fails to treat nested classes as members).

6. Regarding the dangling reference issue, if it is possible that no referent class will be included in the assembly, an instance (possibly static and possibly treated specially) of the referent base class can be included in the referrer class, to avoid failing to refer to and/or execute (again, the customer would look for this with coverage tools) the referrer interface used by the reference base class.

7. Finally, since the partner's architecture requires only that a small number of well-defined interfaces be presented by our product, the vast majority of our C# classes will be internal to the final assemblies, the required confinement of resolution is achieved.

--
egr