Add "Include" and "Exclude" attributes with pattern matching

[OmegaExtern]

For example:
Say, assembly is marked: [assembly: DllExportInclude("exportme_*")]
It would export all static methods from assembly whose name matches the specified pattern (in this case exportme_*).

It would also be nice to have DllExportExclude attribute which could be applied to assembly, types, methods (etc.), but that would work exactly the opposite of DllExportInclude.

Edit:
Here are some notes:

• Inner-most member should have the highest priority, e.g:

[assembly: DllExportExclude("exportme_*")]
// ...
[DllExport]
public static void exportme_Method()
// ...

In such case, since exportme_Method method is explicitly marked to be exported, but assembly is marked the opposite of it, exportme_Method should still be exported.

[3F]

It would also be nice to have

I don't think so... I mean the export-functions are not regular or common thing for something like this.

It's the same as to declare all protected methods as virtual and control all this via black/white list.

also will be a big surprise what's going on, for anyone else who will see source code in first time

and also important problem will be with the exported names by default:

your #10 related

How about:

public static void Print(int a) { }
public static void Print(bool b) { }

What name the Dllexport should set as export-functions for first and second C# method by default ?

[OmegaExtern]

What name the Dllexport should set as export-functions for first and second C# method by default ?

Their mangled names ;)

Edit: Just like C++ does it. Read wiki.

also will be a big surprise what's going on, for anyone else who will see source code in first time

It is already a surprise since metadata for DllExport is removed from compiled assembly...

Edit 2:

I mean the export-functions are not regular or common thing for something like this.

That's what you think.
If this were implemented, then a managed library whose all public static functions are meant to be exported (and used in unmanaged project) would simply do:
[assembly: DllExportInclude("*")]
Which would save tons of DllExport metadata on each method (file size), and development time.. Think about it again.

[3F]

Their mangled names ;)

:) good

how about to help me first with my 3F/Conari#3 (Undecorate functions from C++ compilers)

I already have impl. of C linkage for __cdecl, __stdcall, __fastcall, __vectorcall

but as you should know the any overloading for this is not supported by their format.

so... C++ mangling for different compilers - is there any open source implementations of this ?

btw, in Visual Studio folder we can find console tool - undname (for Dllexport it probably a good way)

It is already a surprise since metadata for DllExport is removed from compiled assembly...

it's not related for source code. For below, we can see export-func for dll:

[DllExport]
public static bool ess(string data, string filter, bool ignoreCase)
{

}

for C++

REGXWILD_API bool ess(const tstring* data, const tstring* filter, bool ignoreCase);

without DllExport or REGXWILD_API above it can be problem for some cases
generally, simply a human understanding

[OmegaExtern]

it's not related for source code.

See my previous comment (made 2nd edit).

without DllExport or REGXWILD_API above it can be problem for some cases

Again, then it is not your nor mine problem, if somebody goes up to strange code-base and he/she looks at source code for the first time, there will be already plenty of surprises, and especially for new programmers, who are not even aware of the power of attributes and MSIL injection... (So, just you know, I disagree with your point there.)

P.S. Some obfuscators already provide such functionality (include/exclude and pattern matching) through (assembly) attributes.

C++ mangling for different compilers - is there any open source implementations of this ?

I know of demangler, but I have never looked into name mangling much, in short, it enables the concept of polymorphism, etc.
There might be something about this in Roslyn, not sure.
Anyway, what is stopping you from doing own/DllExport (.NET) name (de)mangler?

[3F]

I'm still not sure that's useful way, and probably I see more problems than good.

but ok, I marked it as a [suggestion], so it can be considered later.

what is stopping you from doing own/DllExport (.NET) name (de)mangler?

my conscience :)

for Conari, it other history of course.