15 replies to this topic

[Corey Kosak]

The following may or may not be worth doing, but I thought, why hold back, maybe someone else cares about this issue. I think people may not realize that every character in their namespace identifiers, class names, method names, field names, and so on costs them a byte (*) when they deploy their app. Normally this is not a problem but I was wondering what one ought to do in large programs when space gets tight.

You'd rather not encourage people to use tiny class and method names, which would make their code unreadable. I thought it might be nice to provide a tool that automatically squishes the identifiers down to the shortest names possible. You could incorporate Dotfuscator or similar into the toolchain: a little checkbox in the build properties that says "rename all my identifiers to the shortest thing possible". This would have to be optional because it would break reflection calls that look up by hardcoded string, but many programs don't do that anyway. But it's always safe to rename compiler generated identifier since they're supposed to be anonymous anyway.

I started caring about this because I was emotionally traumatized to discover that the utterance "x=>x" adds 108 bytes to one's deployment, 38 of which are owing to Bill Gates' decision to use chatty anonymous field names like "CS$<>9__CachedAnonymousMethodDelegate1". Anyway, something to think about. I complained about this here but there wasn't much reaction.

Second, I don't know about anyone else, but I'm a promiscuous user of extension methods. However, Bill Gates seems to have left the ExtensionAttribute out of the micro framework. For my programs, I've needed to mollify the compiler by putting the following in my code somewhere.

namespace System.Runtime.CompilerServices {
  [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method)]
  public sealed class ExtensionAttribute : Attribute { }
}

I usually keep it in an entirely separate project just so all my other libraries can reference it. I wonder if SecretLabs would be willing to stash that in one of its standard libraries. If it ought to be done, that's sort of the logical place for it. It's easy enough to undo: as soon as Microsoft comes out with a new version of the micro framework that has this missing attribute, you can take it back out of your firmware at the same time.

(*) it costs you that character's representation in UTF-8, so one byte if you stick to 7-bit ASCII but more otherwise.

[CW2]

I wonder if SecretLabs would be willing to stash that in one of its standard libraries.

You could also vote for it on CodePlex.

[Chris Walker]

Hi Corey, I believe that Dotfuscator supports .NET MF these days. Also, a _lot_ is stripped out during deployment; I'm not sure if the field names actually make it to the device. Reflection could show that pretty quickly I suppose We'll look at including the extension attribute in a future library. Very useful indeed. Chris

[Illishar]

Yeah, I saw your post in the netmf forum. However, in the name of KISS, I can live without a builtin obfuscator.

[Corey Kosak]

I'm not sure if the field names actually make it to the device.

They do. I checked before complaining about it . The one thing I believe is stripped is method parameters. At least, I couldn't find them. Code for the others is below.

MyVeryLongNamespace.MyVeryLongClassName
MyVeryLongNamespace.MyVeryLongInterfaceName
myVeryLongFieldName1
myVeryLongFieldName2
MyVeryLongMethodName
Main
ToString
Equals
GetHashCode
Finalize
GetType
MemberwiseClone
Equals
ReferenceEquals

I believe that Dotfuscator supports .NET MF these days

Yeah, I played with the version built in to Visual Studio but I didn't have either the intelligence or the patience to figure out how I could interpose it between the build and the deployment to the device so that it would run automatically.

However, in the name of KISS, I can live without a builtin obfuscator.

Well, simple projects of course don't need it, and you may not yourself care about it. But there are certain projects (web servers, quad copters, fluent frameworks?) which may eventually encroach on the code size limit. And the free version of Dotfuscator is already sitting there inside everyone's Visual Studio. In the spirit of pushing this device to its very limits, it could turn out to be one of several techniques that can be used to get a little more breathing room.

Maybe the solution is as simple as finding out the right post-build step to paste in. Anyone want to volunteer to find out?

using System.Reflection;
using Microsoft.SPOT;

namespace MyVeryLongNamespace {
  public interface MyVeryLongInterfaceName {
    
  }

  public class MyVeryLongClassName : MyVeryLongInterfaceName {
    private int myVeryLongFieldName1;
    private int myVeryLongFieldName2;

    private void MyVeryLongMethodName() {
      
    }

    public static void Main() {
      var t=typeof(MyVeryLongClassName);
      Debug.Print(t.FullName);
      foreach(var i in t.GetInterfaces()) {
        Debug.Print(i.FullName);
      }

      const BindingFlags bindingFlags=BindingFlags.Public|BindingFlags.NonPublic|BindingFlags.Static|BindingFlags.Instance;
      foreach(var f in t.GetFields(bindingFlags)) {
        Debug.Print(f.Name);
      }
      foreach(var f in t.GetMethods(bindingFlags)) {
        Debug.Print(f.Name);
      }
    }
  }
}

[Joe Kuemerle]

Well, simple projects of course don't need it, and you may not yourself care about it. But there are certain projects (web servers, quad copters, fluent frameworks?) which may eventually encroach on the code size limit. And the free version of Dotfuscator is already sitting there inside everyone's Visual Studio. In the spirit of pushing this device to its very limits, it could turn out to be one of several techniques that can be used to get a little more breathing room.

Maybe the solution is as simple as finding out the right post-build step to paste in. Anyone want to volunteer to find out?

Disclaimer: I work for PreEmptive Solutiuons (the makers of Dotfuscator)

I don't know the appropriate post-build step (yet) but I do know that if you want to automate the free version of Dotfuscator the easiest way is to get the version that can be executed from a command line without the GUI popping up. The version included in Visual Studio 2010 will always run in GUI mode. Once you register you will be able to download a command line version of Dotfuscator for free. When you have that installed you can call DotfuscatorCLI.exe to build your Dotfuscator project and rename your symbols in your build script.

[Chris Walker]

Disclaimer: I work for PreEmptive Solutiuons (the makers of Dotfuscator)

Hi Joe,

That's great info. Thanks for visiting us and helping get us started down the right path here...

Welcome to the Netduino community,

Chris

[bill.french]

Disclaimer: I work for PreEmptive Solutiuons (the makers of Dotfuscator)

I have to know: how did you find this thread??

[Joe Kuemerle]

I have to know: how did you find this thread??

I am always very interested in how people use our software so I have a number of Google Alerts set. This post came up because of the mention of "Dotfuscator".

It also caught my eye because of the Netduino and the the .NET MF. Both are very interesting to the hardware hackers here at PreEmptive.

[Corey Kosak]

a command line version of Dotfuscator...

Awesome. Thanks for the info, Joe!

[Illishar]

Impressive

[CW2]

Second, I don't know about anyone else, but I'm a promiscuous user of extension methods. However, Bill Gates seems to have left the ExtensionAttribute out of the micro framework.

FYI, the ExtensionAttribute has just been included (changeset #8999). Looking forward to using it in .NET MF 4.2

[Chris Walker]

FYI, the ExtensionAttribute has just been included (changeset #8999). Looking forward to using it in .NET MF 4.2

Nice I'll see what we can do about adding it to our v4.1.2 firmware as well...

Chris

[Corey Kosak]

Sweet!

[Chris Walker]

I don't know the appropriate post-build step (yet) but I do know that if you want to automate the free version of Dotfuscator the easiest way is to get the version that can be executed from a command line without the GUI popping up.

Hey Joe, if you want to work together on this we'd be happy to show you how to compile, post-process, package (.pe -> hex) and deploy code from the command line. We're needing to do this for the Mono toolchain on Mac/Linux, so perhaps we could offer some free assistance to get full .NET Micro Framework into the excellent Dotfuscator product?

Chris

[Chris Walker]

Nice I'll see what we can do about adding it to our v4.1.2 firmware as well...

And...confirmed. Extension method support will be integrated into the v4.1.2 firmware.

Chris