How to use BeforeAfter[https://github.com/Fody/PropertyChanged/wiki/BeforeAfter] in a inherited class? there was no PropertyChanged.
class InheritedClass:BaseClass, some new props have been added to InheritedClass. Now how to capture the values before&after propertyChanged event?
@bhattvishal VS2017 is no longer supported with recent versions, so make sure you're using VS2019. That "forever to build" issue is strange though, you may try disabling addins to see which one causes the issue.
@ltrzesniewski Thanks for responding. I am using a pretty old version of Fody (2.1.2 to be accurate, PropertyChange.Fody 2.1.3), It was working fine until a week before, but now it just does not compile and takes infinite time. This is happening with every single person in my team, it seems to be some anti-virus thing as we all are in using it in our corporate machines. Fody Property Change tries to change the assemblies, one more thing this is happening only with projects that produce .exe as an output. Do you know, if there's any workaround, also the MSbuild.exe locks the fody.dll and we are not able to close the VS.
This is exactly the issue we are facing - https://stackoverflow.com/questions/59603131/msbuild-hangs-forever-when-fody-writes-assembly any help will be greatly appreciated, we are not able to find any breakthrough. @SimonCropp @ltrzesniewski
@ltrzesniewski I has a lot of child classes (Class1.cs Class2.cs etc) inherited from BaseClass. I want to check the property in the inherited classes. i.e. Check Class_X's properties in Class_X.cs. How to implement this? I can capture all propertychanged event in BaseClass but if that the code will be too long.
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
@bhattvishal you need to provide a repro that illustrates the problem
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
}
but I'm happy to invite you to the project
May this https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ be a replacement for Fody?
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
@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
@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.
The other common problem is forgetting to call ImportReference on everything (types/methods) you want to use.
@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?
@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.
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.
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
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
I can't believe I spent this much time trying to figure this out
When it is already supported
i think it was added in May. by @tom-englert
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!