by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dan Siegel
    @dansiegel
    but I'm happy to invite you to the project
    Simon Cropp
    @SimonCropp
    ok
    GioviQ
    @GioviQ
    Geert van Horrik
    @GeertvanHorrik
    @GioviQ not for me, since it does not allow replacement of existing user code (e.g. rewrite public string FirstName { get; set; } as a dependency property).
    So people will end of with all kinds of hacks (e.g. define a field and dynamically add a property for that), but I think that experience is worse than Fody where you can at least write regular properties (or anything else you would prefer). So it might work great for some weavers, not for all of them
    Simon Cropp
    @SimonCropp
    @GioviQ looking at the existing ~50 actively maintained weavers, i think there are 3 that could be changed to source generators.
    Dan Siegel
    @dansiegel
    @GioviQ Source Generation is pretty awesome and has some benefits over IL weaving with Fody... however to give you an idea... there are limitations with Code Generation that mean you're going to have to look at ways to generate code and then use IL weaving to hook into your generated code.. and there's a lot that just can't be done very well at all with Code Gen...
    kind of where I'm at right now... if I can figure out how to call a method and pass a parameter lol
    Kevin B
    @Keboo
    @dansiegel if you want some assistance I am happy to help as well. In general the IL should look something like: push instance of source object (if static method, omit this) onto the stack, push all arguments onto the stack, invoke method with either call/callvirt depending on the type of method you are trying to invoke.
    The other common problem is forgetting to call ImportReference on everything (types/methods) you want to use.
    Dan Siegel
    @dansiegel
    @Keboo I'd be happy to take you up on that... right now I feel like a total idiot not being able to figure out something that should be pretty basic haha
    Simon Cropp
    @SimonCropp
    @dansiegel i feel like an idiot most of the time when playing with IL. i mostly use decompilers to help me paint by numbers
    ndrwrbgs
    @ndrwrbgs
    @SimonCropp and @ltrzesniewski , I know that's the standard scenario, but given that I was at one point having issues with code signing happening before fody, I'm led to believe that fody is operating on the completed binary. Therefore shouldn't it be possible to run it post-hoc on other assemblies?
    Lucas Trzesniewski
    @ltrzesniewski
    @ndrwrbgs I'm not sure I understand what you're saying... If you're talking about strong naming, then Fody handles that fine (it reuses the key provided for the build). If you're talking about actual code signing, then I believe that's done outside of the MSBuild build process, but I don't know much about that topic. In any case, Fody operates on the compiled assembly (the compiler's output is taken as Fody's input), but it also uses various other data gathered from MSBuild. I suppose you could try to run it in a standalone mode but it will require some effort to provide all the input data it needs - it has not been designed to run outside of MSBuild.
    ndrwrbgs
    @ndrwrbgs
    It sounds like it's possible with this "stand alone mode". Do you have anything you could point me towards to get a running start or should I just try to read what the msbuild targets are doing with Fody?
    Lucas Trzesniewski
    @ltrzesniewski
    There's no "stand alone mode" :) You need to replicate what MSBuild is doing. You can inspect a build with this tool: https://msbuildlog.com/
    Also, note that the weavers have unit tests which execute the weaver on test assemblies, but there are some differences between the test run and the real run. For instance there's a different assembly resolver.
    Mike Marynowski
    @mikernet

    I'm struggling a bit trying to find a suitable approach and was hoping someone better versed in Fody/Cecil/MSBuild could point me in the right direction. I want to get the value of a project property from the Execute() method in a Fody add-in. What's the best approach to take here?

    I tried using Microsoft.Build package to load the project and get the property but then you need to figure out what the current framework moniker is, what the configuration is, etc so that the right properties are parsed. Unfortunately I can't figure out how to get the current configuration (DefineConstants isn't suitable for this) and it's also a rather complicated approach...after going down that path I was convinced that there has to be an easier way.

    BaseModuleWeaver has DefineConstants exposed so I thought that perhaps there's also a way to get other project properties somehow. I've dug around through Fody and FodyHelpers in an attempt to locate something appropriate but so far I can't figure it out. Any idea how I can do this?

    I'm really slamming my head against the wall right now, appreciate any help <3
    Simon Cropp
    @SimonCropp
    @mikernet atm i dont think it is possible. what is your use case? perhaps we can find an alternative solution. if not we might be missing an extensibility point in Fody
    Mike Marynowski
    @mikernet
    I wanted the option of using csproj project properties instead of FodyWeavers.xml for add-in configuration so that you could use directory.build.props for weaver settings as well as facilitating more complex configurations, i.e. using Condition=.... to have different settings for different build configurations or target frameworks, etc
    Mike Marynowski
    @mikernet
    Omg, haha....
    I can't believe I spent this much time trying to figure this out
    When it is already supported
    Simon Cropp
    @SimonCropp
    sorry for the burnt time. it is a relatively new feature. and the approach should prob be added to the readme for all addins
    i think it was added in May. by @tom-englert
    Mike Marynowski
    @mikernet

    That makes sense, last I looked into this was probably a few months ago and I didn't check to see if something new popped up since then. Ah well, all good, less work for me going forward either way. Having it generalized to all add-ins like this is much nicer as well.

    Thanks for the help!

    Mike Marynowski
    @mikernet
    I have a question: what .NET version do fody plugins run in? Is it based on the project they are applied to?
    Geert van Horrik
    @GeertvanHorrik
    I think it's either netstandard or netclassic
    I know that whenever I run it against .net core, it's using netclassic
    Mike Marynowski
    @mikernet
    So the actual plugin itself has to be written in netstandard <= 2.0 then?
    I wouldn't be able to use 2.1 for example, right?
    Geert van Horrik
    @GeertvanHorrik
    From the top of my head, it's indeed either netstandard2.0 or netclassic (net472)
    tom-englert
    @tom-englert
    @mikernet it's the dotnet version that your build system runs in. For MSBuild e.g. it will be the netclassic that you have installed on your system.
    So just make sure you have the proper dotnet version installed.
    This is from MSBuild.exe.config: <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
    </startup>
    Mike Marynowski
    @mikernet
    Great, thanks
    tom-englert
    @tom-englert
    So when running in MSBuild 16.0, you can rely on having at least 4.6, but it might be higher
    Mike Marynowski
    @mikernet
    In some of your weavers you have added peverify code 0x80131205 to the ignore list - do you know what causes it? The full message text of the error reads:
    [MD](0x80131205): Error (Structural): Table=0x00000001, Col=0x00000000, Row=0x0000000a, has coded rid out of range.
    Simon Cropp
    @SimonCropp
    @mikernet it had been a while. but i think it is due to the fact that we dont run test as a real build would run. are u seeing it in a resulting assembly?
    Mike Marynowski
    @mikernet
    I'm seeing it in the weaver solution that has a test assembly with a the FodyWeavers.xml file that contains:
    <Weavers VerifyAssembly="true">
    I think I found a bit of a strange bug as well
    It only happens if the weavers are configured in csproj instead of FodyWeavers.xml
    Mike Marynowski
    @mikernet
    But if they are configured in csproj then fody adds multiple ProcessedByFody classes so I get a PEVerify error - it happens when all I do is make a trivial change to a source file in the test assembly like add a space and delete it again and then build.
    If I move the exact same config to FodyWeavers.xml then it no longer exhibits that behavior.
    Everytime I build Fody stacks on another conflicting ProcessedByFody class
    Mike Marynowski
    @mikernet
    And it magically stopped doing it now...some kinda heisenbug it seems.
    And it magically stopped doing it now...some kinda heisenbug it seems.
    I deleted FodyWeavers.xml and uncommented the csproj config to go back to how it was when it was adding multiple ProcessedByFody classes and it's back to normal now, lol