Dynamic definitions of namespaces

[3F]

Updated

via Cecil or direct modification:

I implemented byte-structure for v1.2+

// byte-seq via chars: 
// + Identifier        = [32]bytes
// + size of buffer    = [ 4]bytes (range: 0000 - FFF9; reserved: FFFA - FFFF)
// + buffer of n size
D3F00FF1770DED978EC774BA389F2DC901F4 // 01F4 - allocated buffer size
.B00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 // 100
.C00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.D00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.E00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.F00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
//= 536

... and you can use what you want, for example System.Runtime.InteropServices or namespace of your project net.r_eg.Conari etc.

+the illustration via Object Browser of VS2015:

click on image to maximize or here

v1.4+ new configurator:

---

for old v1.1:

System.Runtime.InteropServices;

The DllExport have a special case for naming i.e. in any case cannot be 2 or more different projects for work with similar features DllExport - because it's ambiguity of logic at all, because it's a tool and not a library. So, even if this feature will appear from official MS, it not problem at all, because the any custom DllExport will be obsolete and removed from project at all.

You cannot make those kinds of assumptions.

yes, of course, but 'as is' - the System.Runtime.InteropServices exists for specific purposes only.
anyone else :) do not should use something (inc. "another library that helps e.g. with marshaling") inside this namespace because it may intersect with something else in future. And it problem should known for developers that distributed their other features.

It means for DllExport & InteropServices it more likely a theoretical-potential problems, but yes, conflicts are possible.

Therefore, to avoid any the theoretical-potential problems of this case, the easy way to provide auto-variants of this assembly, this is common way for any cases.
With vssbe scripts or something else, I will just add later 2 auto-build of nupkg or something else. So candy for all tastes ...

[3F]

for direct mod, my idea here...

of course it would be simply to provide different assemblies like:

namespace
#if NS_RG
    RGiesecke.DllExport
#elif NS_3F
    net.r_eg.DllExport
#else
    System.Runtime.InteropServices
#endif
etc., 

but it should require a lot of steps of managing of all this, and still is not a common solution. So I just don't want ...

Therefore, I think the following variant is more flexible and useful:

1. I will define byte-sequence: ~ 32 Identifier + 1 splitter + 500 buffer

D3F00FF1770DED978EC774BA389F2DC9.B00000000000000000000000000000000000000....

2. Therefore, the final assemblies should contains the following bytes:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000005B0                 00 C4 7B 01 00 00 00 2F 00 12 05       .Д{..../...
000005C0  00 00 02 00 00 00 00 00 00 00 00 00 00 00 26 00  ..............&.
000005D0  20 02 00 00 00 00 00 00 00 44 33 46 30 30 46 46   ........D3F00FF
000005E0  31 37 37 30 44 45 44 39 37 38 45 43 37 37 34 42  1770DED978EC774B
000005F0  41 33 38 39 46 32 44 43 39 2E 42 30 30 30 30 30  A389F2DC9.B00000
00000600  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
...
000007A0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
000007B0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
000007C0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
000007D0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  0000000000000000
000007E0  30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 3C  00000000000000.<

3. Now we can try to redefine it as null-terminated string with what the user wants, e.g.:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000005B0                 00 C4 7B 01 00 00 00 2F 00 12 05       .Д{..../...
000005C0  00 00 02 00 00 00 00 00 00 00 00 00 00 00 26 00  ..............&.
000005D0  20 02 00 00 00 00 00 00 00 49 2E 77 61 6E 74 2E   ........I.want.
000005E0  74 6F 2E 66 6C 79 00 00 00 00 00 00 00 00 00 00  to.fly..........
000005F0  00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00  ................
00000600  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
...
000007A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000007E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3C  ...............<

simply and works well :)

The VS IDE immediately updates our assembly and we can work without problems.
The most important to use the only allocated buffer, otherwise it will be corrupted.

[3F]

damn, forgot to control range: 0000 - FFF9; reserved: FFFA - FFFF o_o

TODO: not so critical...