Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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!
    P.S. If you put Verify="true" on the <Weavers> config it goes absolutely bonkers on assemblies that use the new interface features (i.e. default methods, private/internal/static members, etc)
    Lucas Trzesniewski
    @ltrzesniewski
    Yeah, that's not really surprising, as PEVerify is quite old
    Mike Marynowski
    @mikernet
    Any plans to replace it with ILVerify? Apparently that's the new way of doing this. I'm guessing it would probably need to keep the current way for backwards compat but introduce a new setting for ILVerify=true?
    I could PR something for this
    Mike Marynowski
    @mikernet
    (Unless the error codes and messages are still the same, then we could just replace it - I haven't looked too far into it yet)
    Lucas Trzesniewski
    @ltrzesniewski
    Yeah I suppose we'll have to embed the ILVerification library (the underlying logic of ILVerify) sooner or later to replace PEVerify, but there are no plans yet AFAIK. I don't know how it compares to PEVerify though, but I suppose it will be a breaking change.
    Shimmy
    @weitzhandler
    Hi, is there an "EmptyCollectionGuard" similar to the NullGuard?
    Shimmy
    @weitzhandler
    Simon Cropp
    @SimonCropp
    @weitzhandler i dont think that is maintained
    Shimmy
    @weitzhandler
    Thanks for your heads up @SimonCropp!
    You appear as a monderator there, so I thought it's kinda official...
    Simon Cropp
    @SimonCropp
    i think i helped out with it for a while @weitzhandler so i was given push permissions. if you want to take over ownership i can try to arrange it
    Shimmy
    @weitzhandler
    @SimonCropp My IL skill sucks. Lemme think it through until the weekend.
    Simon Cropp
    @SimonCropp
    my IL skills also suck
    Shimmy
    @weitzhandler
    Oh wow, really?
    Are you in touch with @thirkcircus?
    I mean are there a lot to take care of in that library?
    Simon Cropp
    @SimonCropp
    perhaps reach out on twitter https://mobile.twitter.com/justinthirkell
    Dan Siegel
    @dansiegel

    I'm trying to make it a little easier to consume the Fody part of my package with an embedded FodyWeavers.xml and I added the following prop:

    <ProjectWeaverXml Condition="!Exists('FodyWeavers.xml') And $(ProjectWeaverXml) == ''">$(MSBuildThisFileDirectory)FodyWeavers.xml</ProjectWeaverXml>

    For some reason though Fody seems to be copying or generating the FodyWeavers.xml/xsd in the project directory. Is there a way I can stop that behavior?

    Lucas Trzesniewski
    @ltrzesniewski
    Well, Fody doesn't really use the value of the ProjectWeaverXml property down the line, and it's not even documented. I suppose you could open an issue if you'd like it to be customizable.
    To work around this, you could define a WeaverConfiguration property in a Directory.Build.props file, with the config inlined (without an external file). See the docs here.
    Dan Siegel
    @dansiegel
    @ltrzesniewski that seems to be working... perfect. I wasn't really tied so much to having to do it a specific way, I just wanted to make it totally transparent that Fody was even being used under the covers to achieve the necessary IL manipulation. Thanks for pointing me in the right direction
    Dan Siegel
    @dansiegel
    hey silly question... is it possible to weave a referenced assembly? The scenario I'm looking at is to have an attribute on the Application assembly for a Prism application... and be able to weave any referenced Prism Module assembly to change the default naming used to register Views for navigation... So HomePage might become homePage or just home depending on the naming preferences of the consuming application.
    Kevin B
    @Keboo
    @dansiegel sure, do similar using Cecil directly in AutoDI. And it will work in most cases. There is a bit of an edge case where the assembly compiled against is different than the runtime assembly (NuGet bait and switch trick). However, I suspect for your use-cases that will not be an issue. There can also be issues with strong named and signed assemblies. If you make some assumptions about dependent assemblies naming and signing this can also be overcome as well.
    Dan Siegel
    @dansiegel
    awesome... thanks @Keboo
    Mike Marynowski
    @mikernet
    Someone is having a problem getting a System.ValueTuple assembly not found error when using my fody addin, but only in CI for some reason. He mentioned ltrzesniewski/InlineIL.Fody#19 - is there a general issue using ValueTuple in addins, i.e. should I be changing my code not to use them?
    Mike Marynowski
    @mikernet
    It appears this is the case. There's gotta be a relatively simple workaround for this other than "don't use VT in build tasks", like using binding redirects or something
    Lucas Trzesniewski
    @ltrzesniewski
    That problem appeared with SDK 3.1.401 - I didn't try to understand why, as removing the value tuples seemed like the easiest way out for me (you can't really control the binding redirects of MSBuild).
    If it can help, I wrote a unit test that makes sure you don't reference a value tuple in the weaver, it's mentioned in the issue.
    Mike Marynowski
    @mikernet
    I've done "manual" assembly binding redirects via tapping into the assembly load event before. I'm guessing that could be implemented in Fody to avoid this issue for fody addins but frankly that's too much work right now...going through and attempting to find all my usages of VT and replacing them with hand coded structs atm.
    I'll give your unit test a shot
    Mike Marynowski
    @mikernet
    Thanks for that unit test code, seems to work well. I'll leave it in there to prevent future inadvertent VT usage.
    Simon Cropp
    @SimonCropp
    yeah i noticed the VT issue. will look into it
    Simon Cropp
    @SimonCropp
    seems the VT issue is still a bug in dotnet dotnet/runtime#27533
    I was not able to find a workaround so i released a version of fody that gives a more descriptive error when it is detected
    kampilan
    @kampilan
    Is there a way to control the name of the backing field added by PropertyChanged. I want it to be _propertyName for PropertyName not just propertyName. Trying to get EF Core to bind to the back fields. Thanks
    Simon Cropp
    @SimonCropp
    @kampilan the backing field is done by the compiler, not PropertyChanges
    kampilan
    @kampilan
    Ahhh. Thanks for the quick reply!
    Francois Botha
    @igitur

    Hi @SimonCropp and everybody. I realise it's been discussed to death, but hope it's OK if I raise the patron model too.

    We are 2 developers who maintain https://github.com/ClosedXML/ClosedXML (MIT licensed). We both have families and being inundated with issues and some PRs I can fully appreciate the move to the new model. However, ClosedXML doesn't have an income, nor do we ever intend to go that route.

    We've been using Janitor for a while now. We don't ever intend to raise a PR with Fody or Janitor. We don't intend to open issues or use up any time of the Fody developers (besides this discussion we're having :-) ). We just want to consume Fody and Janitor and not bother anyone. And of course not pay anyone out of our own pockets.

    We understand that, as an open-source project, there's nothing technically from stopping us using it, but we're sticklers for rules and would like to play according to them. So is there a way forward for us to use the latest Fody with your blessing, without paying, and without raising issues/PRs to waste your time?

    Francois Botha
    @igitur
    And by 'use the latest Fody' I mean to just consume the NuGet package.
    Lars Shakya Buch-Jepsen
    @larsbuch

    I like using Fody but I have one issue I cannot find a solution for: I use Fody on a project from which I make a Nuget package. The Nuget package gets the reference to Fody and other Fody packages but they are only development and build dependencies and does not need to be references i the deployed Nuget. It contaminates the Nuget references. Is there a way to avoid the references ? Fx a Fody package that removes the reference of Fody packages. I think I can make a deployment script that does that but it complicates my CI pipeline a lot.

    Edit: Oh. Found it. Saw that it was a Fody without <PrivateAssets>all</PrivateAssets> in the project file

    Simon Cropp
    @SimonCropp
    @igitur yeah thats fine. re the PrivateAssets>all, you should have had a build warning instructing u to make that change
    Dan Siegel
    @dansiegel
    I'm trying to figure out what I'm doing wrong here... when I decompile, the Text property is the result of the weaver... the Text2 property is a hand coded version that I'm trying to match. The IL looks like it's correct, but I seem to be getting the static Property reference on the type instead of the instance... What am I doing wrong here?
    public string Text
    {
        get
        {
            return (String)base.GetValue(SomeControl.TextProperty);
        }
        set
        {
            base.SetValue(SomeControl.TextProperty, value);
            return this;
        }
    }
    
    public string Text2
    {
        get
        {
            return (String)base.GetValue(this.TextProperty2);
        }
        set
        {
            base.SetValue(this.TextProperty2, value);
        }
    }
    Kevin B
    @Keboo
    @dansiegel can you share the IL for the Text property?
    Dan Siegel
    @dansiegel
    .property instance string Text()
    {
        .get instance string SampleApp.Controls.SomeControl::get_Text()
        {
            IL_0000: ldarg.0
            IL_0001: ldarg.0
            IL_0002: ldsfld class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty SampleApp.Controls.SomeControl::TextProperty
            IL_0007: call instance object [Xamarin.Forms.Core]Xamarin.Forms.BindableObject::GetValue(class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty)
            IL_000c: castclass [netstandard]System.String
            IL_0011: ret
        }
        .set instance void SampleApp.Controls.SomeControl::set_Text(string)
        {
            IL_0000: ldarg.0
            IL_0001: ldarg.0
            IL_0002: ldsfld class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty SampleApp.Controls.SomeControl::TextProperty
            IL_0007: ldarg.1
            IL_0008: call instance void [Xamarin.Forms.Core]Xamarin.Forms.BindableObject::SetValue(class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty,  object)
            IL_000d: nop
            IL_000e: ret
        }
    }
    
    .property instance string Text2()
    {
        .get instance string SampleApp.Controls.SomeControl::get_Text2()
        {
            IL_0000: ldarg.0
            IL_0001: ldarg.0
            IL_0002: ldfld class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty SampleApp.Controls.SomeControl::TextProperty2
            IL_0007: call instance object [Xamarin.Forms.Core]Xamarin.Forms.BindableObject::GetValue(class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty)
            IL_000c: castclass [netstandard]System.String
            IL_0011: ret
        }
        .set instance void SampleApp.Controls.SomeControl::set_Text2(string)
        {
            IL_0000: ldarg.0
            IL_0001: ldarg.0
            IL_0002: ldfld class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty SampleApp.Controls.SomeControl::TextProperty2
            IL_0007: ldarg.1
            IL_0008: call instance void [Xamarin.Forms.Core]Xamarin.Forms.BindableObject::SetValue(class [Xamarin.Forms.Core]Xamarin.Forms.BindableProperty,  object)
            IL_000d: nop
            IL_000e: ret
        }
    }
    Kevin B
    @Keboo
    so the difference is the ldsfld vs ldfld. So you are looking to change your weaver to emit a ldfld. To get the "this" you need it on the stack the the ldarg.o (which it looks like you already have)
    Dan Siegel
    @dansiegel
    well :poop: .... I cannot believe I missed that... I've been looking at this for the last 2 hours... thanks @Keboo
    Kevin B
    @Keboo
    @dansiegel np. Done that plenty of times myself.