Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanding on /internalize functionality #40

Open
Stevie-O opened this issue May 1, 2013 · 4 comments
Open

Expanding on /internalize functionality #40

Stevie-O opened this issue May 1, 2013 · 4 comments

Comments

@Stevie-O
Copy link

Stevie-O commented May 1, 2013

This isn't an issue, per se, but I couldn't find a better place to put it.

I'm working on a project that involves merging several individual assemblies into a single DLL.
I ran into two problems:

  1. Internalization was pretty braindead: Internalize all types not in the primary assembly.

    This created a problem because I had some things like this:

    MainAssembly:
        public class Foo : Bar
        {
            public Baz baz;
        }
    
    OtherAssembly:
        public class Bar {}
        public class Baz {}
    

    The internalization of Bar and Baz created a mess with Foo.

  2. For various reasons, there were some public methods on Foo weren't appropriate to expose externally, but had to be public when everything was split across multiple assemblies due to various limitations.

    I needed a way to change those methods to 'internal' when they no longer needed to be used.

I created a fork for ILRepack here: https://github.com/Stevie-O/il-repack/commits/smartmerge

and added the following features:

  • Extended the /internalize exclude file syntax to support the following:
    • Inverted rules (if a type matches the regex, it will be internalized, even if it is in the "main" assembly)

    • Internalization of individual class members

      With a properly constructed line, individual members (properties, fields, methods, events) of a type may be changed to internal.

  • Automatically exclude types from internalization if they are exposed by another, non-internalized type somehow:
    • An exposed type exposes its base classes.
    • A public field exposes the field's type.
    • A public property exposes the property's type
    • A public method exposes the return type and all parameters' types.
    • A public event exposes the delegate type for the event's handlers.

If someone looks at the code and thinks it's decent enough, I'll create a pull request.

@jahmai-ca
Copy link

jahmai-ca commented Oct 7, 2016

I am currently looking at IL-Repack because ILMerge, Fody.Costura and LibZ all failed to meet my requirements. I was about to drop IL-Repack due to lacking internalization options and then I found this. I think this is exactly what I need. 👍

EDIT: Seems something like this has already been implemented in the main repo but isn't well documented?

@jahmai-ca
Copy link

The new functionality wasn't quite as good as what you had, so I forked the current branch and implemented the implicit export of transitively exposed types, which is pure gold and makes using IL-Repack so much easier.

@emysa341
Copy link

Hi, I need this too. Where is the documentation for using the smart internalization ?

@KirillOsenkov
Copy link
Collaborator

The master branch now has a subset of this functionality:

  • you can now specify a set of assemblies to internalize (`/internalizeassembly:System.Foo /internalizeassembly:System.Bar)
  • types which appear in the public API of the main assembly remain public
  • /excludeinternalizeserializable will leave serializable types public
  • there's a regex to exclude some assemblies or types from internalizing

However the opposite is still not implemented: forcing types to be made internal even if they're in the main assembly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants