by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    sekulicb
    @sekulicb
    Hi. How to reset validation errors in Validar, once the form is validated and saved. If we clear previous data, the user is presented with adorned boxes making form all in red next time the form is opened. Is there a way to revert all validation errors and clear the form from red borders? Thanks
    Simon Cropp
    @SimonCropp
    @ndrwrbgs yep fody only runs on the assembly produced by the csproj
    Simon Cropp
    @SimonCropp
    @sekulicb you need to provide a repro that illustrates what you are trying to achieve
    @bhattvishal you need to provide a repro that illustrates the problem
    Dan Siegel
    @dansiegel
    hey @SimonCropp I might be jumping into the deep end here... but hoping you can help point me in the right direction... I get how to walk the types, methods and properties in a compiled assembly... but what I'm trying to figure out is the correct way to build the new instruction I want to weave in...
    public void SomeMethod(ISomeService someService)
    {
        // What needs to be weaved...
        SomeGeneratedMethod(someService);
    }
    
    private void SomeGeneratedMethod(ISomeService someService)
    {
        // Generated Code
    }
    Simon Cropp
    @SimonCropp
    @dansiegel your best bet is to look at the method u want to in ilspy. that will show u what instructions to inject
    Dan Siegel
    @dansiegel
    thanks I'll check that out
    Kevin B
    @Keboo
    @dansiegel another thing I have done is leverage dnSpy since it lets you inspect an assembly and then mutate its contents either in IL or C#. Makes for a tighter development loop.
    Dan Siegel
    @dansiegel
    thanks @Keboo appreciate the tips
    Simon Cropp
    @SimonCropp
    @dansiegel is it an OSS project?
    Dan Siegel
    @dansiegel
    this one isn't... doing it as a project for my GitHub sponsors... and OSS authors who ask ;)
    Simon Cropp
    @SimonCropp
    fair enough. was going to offer to review it.
    Dan Siegel
    @dansiegel
    there really isn't much there right now... still trying to get a working prototype now that I finished the code gen side
    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>