-
Notifications
You must be signed in to change notification settings - Fork 0
/
plan.txt
87 lines (76 loc) · 3.58 KB
/
plan.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
A derivative caching lib would scan the entire assembly and reweave according to marker attributes - not functional ones.
Certain info would need consolidating from their dispersion before weaving decisions could be made.
As is, attributes are NOT expected to be functional.
But we DO insist on targeting code to be present in the given assembly. This makes no sense for derivative libraries, which would
insinuate themselves into the project by NuGet, with no requirement for further user interaction.
Fody, in its emplacement, alters the build script. Could a further user library do similarly? Could it set a variable in the project file
to relay instructions to Cuckoo?
What else could be done? A special file in the root folder, like FodyWeavers.xml? Shouldn't rely on Fody in this, so can't jump that file
in particular. Files are lame though. If the build script would work, that would be the avenue.
.targets file is merged in somehow... this would spec the assembly of the targeter, and the assembly to target.
See here (I think): http://haacked.com/archive/2014/04/15/nuget-build-dependencies/
*******************************************************************
TO DO:
> Gatherer should be named, more substantial part
> Sign it all
> With signing in place, reduce public surface
> Test package on Mono again
> Remember to switch nuget to Release!
*******************************************************************
DONE
> Targeters to be specified by param - to be done by Cuckoo.Fody and passed to the gatherer DONE
> Ensure monikers handle gen params well enough to allow matching to target methods DONE
> TypeMonikers DONE
> Targeters should return specs with methodbases; tokens should be internal only DONE
> Rebuild nuget package after any changes DONE
> Propogate nuget package to example project DONE
> Att ctors with optional args DONE
> Att ctors with params arrays DONE
> Test ctor args and named params on att ctors - of all types! DONE
> Test args of type Type on atts DONE
> Separate gathering from weaving DONE
> Weaver should take AssemblyDefinition DONE
> Test picking up of private + public methods DONE
> Providers can't be abstract or generic DONE
> Ensure Cuckooeds are not virtual DONE
> Separate Cuckoo.Weave and Cuckoo.Weave DONE
> General roost-targeting mechanism DONE
> Rewrite attributes to use roost-targeting DONE
> NuGet DONE
> Mono tesing DONE
> CallArgs of arrays and nullables DONE
> Fill in metadata DONE
> Now references Fody.Cecil DONE
> Hide stack as much as we can DONE
> Struct values are written back into place after cuckooing DONE
> Clean away MethodDecorator remnants DONE
> Remove and sort all usings DONE
> structs rather than classes DONE
> virtual methods DONE
> check attributes not inherited DONE
> Test Cuckoos declared in other assemblies DONE
> Extension methods DONE
> ICuckooProvider DONE
> Property accessors DONE
> Beware array types: in both ctor args and gen params! DONE
> Nullable types in generic args DONE
> async DONE
> Return value to police its type DONE
> Cuckoos on Constructors DONE
> Static roost field to be nested within Call class DONE
> Static classes DONE
> Static methods DONE
> Optional args in CuckooAttributes DONE
> Optional args in cuckooed methods DONE
> CallArg<T> classes, deriving from exposed ICallArg DONE
> CallArgs should check type of value set DONE
> ByRef parameters DONE
> Cooler lambda-based MethodTester DONE
> Generic classes DONE
> Multiple cuckoos in one nest DONE
> Init to be called DONE
> Change returned value DONE
> Args wrapped in classes DONE
> Name-provision encapsulated DONE
> Generic methods: generic args + generic return DONE