Optimization: how to exclude unused code ?

[Maxim]

Greetings,
In my C# project, I'm using a third-party Opensource library... in
source code form. I mean no assemblies, just pure source code. It
allows me to add new application-specific functionality to that
library, finetune it, and see how things work.

Well, the problem is that the library is quite huge, so the
application's size gets not really acceptable - I'm developping for an
embedded environment. In fact, I'm using probably 5 percent of that
library. I manually excluded the big "modules " I will never use, but
there is still some unused code which could serve one day. Or not.

My question is : is it possible to tell the C# compiler (I'm using VS
..Net 2003 default compiler) to *exclude unused code* from compilation,
like many C/C++ compilers do ?

Thanks !

--
Maxim
"L'on endure tout fors que trop d'aise."
- proverbe françois

[Alan Pretre]

"Maxim" <bo************ *****@gmail.com > wrote in message
news:mn******** *************** @127.0.0.1...

My question is : is it possible to tell the C# compiler (I'm using VS .Net
2003 default compiler) to *exclude unused code* from compilation, like
many C/C++ compilers do ?

Sure, use

#define IncludeStuff

#if IncludeStuff
// Code to include
#endif

You can put the #define in the source code, or you can set it as part of
project properties for the build in VS.NET, or if building from the command
line, you can use the /define flag.

-- Alan

[Maxim]

Alan Pretre écrit:

"Maxim" <bo************ *****@gmail.com > wrote in message
news:mn******** *************** @127.0.0.1...

My question is : is it possible to tell the C# compiler (I'm using VS .Net
2003 default compiler) to *exclude unused code* from compilation, like many
C/C++ compilers do ?

Sure, use

#define IncludeStuff

#if IncludeStuff
// Code to include
#endif

You can put the #define in the source code, or you can set it as part of
project properties for the build in VS.NET, or if building from the command
line, you can use the /define flag.

Sure, but there is too much code to get it done manually. And it's
sometimes mixed, i.e., I can use a class having "huge" unused parts.

Good C/C++ compilers usually just don't compile unused code (if you
tell'em), and I'm wondering if it's possible with MS C# compiler.

I've googled about my problem, and it seems like the only 2 ways to
strip unused parts of an application are: use a third pary linker (like
Salamander), or run a "high-end" obfuscator on the assembly (e.g.,
Dotfuscator Professional).

--
Maxim
"Qui ne s'adventure n'a cheval ny mule."
- proverbe françois

[Sean Hederman]

"Maxim" <bo************ *****@gmail.com > wrote in message
news:mn******** *************** @127.0.0.1...

Good C/C++ compilers usually just don't compile unused code (if you
tell'em), and I'm wondering if it's possible with MS C# compiler.
Not directly. C/C++ is statically linked, so it's easy to exclude code.
However the .NET distributable is the dynamically linked assembly, and it is
impossible for the application to anticipate what usage will be made on an
assembly once it is "out of sight". By putting code into an assembly you are
saying that it is important for that code to be there, the compiler won't
second-guess you, since it does not know all the things that may call it.
I've googled about my problem, and it seems like the only 2 ways to strip
unused parts of an application are: use a third pary linker (like
Salamander), or run a "high-end" obfuscator on the assembly (e.g.,
Dotfuscator Professional).
A linker will result in the wiping out of redistribution, sharing, and
security feautures. An obfuscator will not remove the code, but will
compress all your code by cutting down the size of the symbols. I would
suggest that the "best" approach is Alan's suggestion combined with an
obfuscator.
--
Maxim
"Qui ne s'adventure n'a cheval ny mule."
- proverbe françois

[lionel]

May I suggest trying XenoCode, which contains a linker, an obfuscator
and dead code elimination features. Besides, we are 75% cheaper than
Dotfuscator Pro.

Lionel Lindemann,
http://www.xenocode.com