by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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
    Oh there it is, back again after I closed and reopened VS
    Mike Marynowski
    @mikernet
    Everytime I build it adds another one even without changing anything in the files:
    image.png
    Mike Marynowski
    @mikernet
    Rebuild cleans it up again
    Those tokens all point to AssemblyName_ProcessedByFody classes with conflicting names. Behavior stops when xml instead of csproj config is used.
    Simon Cropp
    @SimonCropp
    can u raise an issue and include a repro
    Mike Marynowski
    @mikernet
    Yup. This lib is getting posted shortly - I'll post the issue after so you'll be able to pull it and repro it on your end
    Simon Cropp
    @SimonCropp
    @tom-englert do we need this https://www.nuget.org/packages/PropertyChanged2.Fody/ ? can it be unlisted?
    tom-englert
    @tom-englert
    Right, that is no longer needed, I'll it
    unlist
    Mike Marynowski
    @mikernet
    Lucas Trzesniewski
    @ltrzesniewski
    I'm pretty sure this covers the ProcessedByFody issue described above: Fody/Fody#895
    Congrats for the weaver BTW! You should do a PR on Fody/Home to include it to the weaver list.
    Mike Marynowski
    @mikernet
    Thanks 😊 I absolutely will!