fody / fody Goto Github PK

I had to change the two occorances of $(KeyOriginatorFile) to $(AssemblyOriginatorKeyFile) in the Fody.targets file to get Fody to re-sign the assembly. The AssemblyOriginatorKeyFile property is set in my (csproj) project file while the KeyOriginatorFile property is not.

Hello,

Have been using Fody for quite some time now, never experienced this issue before. Today I found some Fody addins cannot be installed while others work just fine.

Steps to reproduce the issue:

1. Create a new solution;
2. Right click solution/project, select "Manage NuGet Packages...";
3. Install Fody;
4. Install PropertyChanged.Fody, will get the following error:

"Received an unexpected EOF or 0 bytes from the transport stream"

Here is a short video demonstrating the issue:
https://dl.dropbox.com/u/46508238/github.com/Fody-Issue-2013-03-26%205.54.35%20PM.mp4

See https://github.com/SimonCropp/Fody/issues/5

So people can config AddinSearchPaths without hacking Fody.targets

I have a library Harden which would be perfect for an addin. It lets you easily create dynamic guard clauses and validation rules for your objects. It currently uses Castle DynamicProxy to do something along the lines of:

public class User
{
    public void DoSomething() { ... }
    public bool? AllowDoSomething() { ... } //dynamic guard clause method
    public void ValidateDoSomething() { ... } //dynamic validation method
}

into

public class User
{
    public void DoSomething() 
    {
        if (!Harden.Allow.DoAllow(this, doSomethingMethodInfo))
        {
            throw new HardenException("Not allowed to call " + doSomethingMethodInfo.Name);
        }
        Validation.Execute(invocation.Proxy, invocation.Method, invocation.Arguments);
    } 

    public void AllowDoSomething() { ... } //unchanged
    public void ValidateDoSomething() { ... } //unchanged
}

I think it's a really useful library, somewhat let down by it's proxy requirements. I would love to see it as an AddIn. I will look into it if you can suggest me an appropriate addin to fork, although if you find yourself with a spare evening... (sorry, so cheeky!)

The other thing that might be cool would be interop with dynamic proxy, so you could have a static ConcurrentDictionary<Type, ConcurrentList> InterceptorRegistry, and the types could execute the interceptors automatically. This would provide re-use of existing castle interceptors without needing virtual methods everywhere.

Upgrade version to 1.0.0.0 since stability looks good.

Nevermind

Should Fody report an error instead of a warning if there are no weavers found?

For new users, this will help because they may miss the warning message. This is what happened to @shanselman in that Tekpub video.

If the warning is still needed for some reason (as in you need Fody on, but no weavers, although why?) we could make it a config in the FodyWeaver.xml. That way the user has explicitly said they know what their doing, carry on.

Hi.

I'm trying to use the MethodDecorator Fody, but to place my attribute (and its IMethodDecorator interface) in some common project. This will allow me to use the attribute across my solution, in more than one project, rather than redefine it in each project.

The addin doesn't seem to support this, I get: Could not find type 'IMethodDecorator' or 'MethodDecoratorAttribute'. Rummaging through MethodDecorator's ModuleWeaver.cs, it seems that it indeed only looks for types named IMethodDecorator or MethodDecoratorAttribute in the same assembly.

I'd be glad to help out and submit a pull request. However, extending this to support external assemblies seems like it would be heavy - walking through the entire assembly dependency to see if any attributes implement an interface with the name IMethodDecorator. It seems like a case where simply forcing the user to extend a Fody-provided IMethodDecorator could be saner?

Let me know what you think...

Shay

PS There is no issue section in the github project page for MethodDecorator, which is why I'm posting here...

This happens both when building locally with VS2012 and also on out build server (teamcity).

After a build there is always a msbuild.exe still running. This process locks fody.dll and prevents a clean on the build server.

• scan projects in current solution and check if they have Fody configured. if they do re-use the Tools\Fody dir
• look in the same location you store your nuget packages. if there is a Tools\Fody at the same level then use that

I believe there is an issue with where the notify event happens when using AlsoNotifyFor.

Using the code:

        [AlsoNotifyFor("CanEnterText")]
        public ListCodeResultObject Selection
        {
            get { return selection; }
            set
            {
                if (selection == value) return;
                selection = value;
                Dto.ServiceCommitmentText = selection.AdditionalInfo;
                Dto.ServiceCommitmentTemplateId = selection.CodeId;
            }
        }

        public bool CanEnterText { get { return Dto.ServiceCommitmentTemplateId != (int)SpecificCode.None; } }

causes the CanEnterText property to be ready by the UI before the DTO has been updated as opposed to when the entire setter has completed. The results being that the CanEnterText property shows what was previously chosen instead of the current selection. I would expect that AlsoNotifyFor should put all additional notify actions at the end of the property like NotifyPropertyWeaver did.

In a new project with no other bits, I get an error from the fody installer.

PM> Install-Package Fody
Successfully installed 'Fody 1.13.2.0'.
Successfully added 'Fody 1.13.2.0' to ClassLibrary1.
Exception calling "RemoveChild" with "1" argument(s): "Parameter "child" cannot be null."
At F:\src\ClassLibrary1\packages\Fody.1.13.2.0\Tools\install.ps1:23 char:32
+         $buildProject.Xml.RemoveChild <<<< ($importToRemove) | out-null
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

It seems to have installed correctly though. I then build, get the fody error telling me that I haven't configured any weavers. Then I uninstall.

PM> Uninstall-Package Fody
Successfully removed 'Fody 1.13.2.0' from ClassLibrary1.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\Fody.dll' is denied.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\FodyCommon.dll' is denied.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\FodyIsolated.dll' is denied.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\Mono.Cecil.dll' is denied.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\Mono.Cecil.Mdb.dll' is denied.
Access to the path 'F:\src\ClassLibrary1\packages\Fody.1.13.2.0\Mono.Cecil.Pdb.dll' is denied.
The directory is not empty.

Successfully uninstalled 'Fody 1.13.2.0'.
One or more packages could not be completely uninstalled: Fody.1.13.2.0. Restart Visual Studio to finish uninstall.

I thought you had a fix for msbuild locking everything.

Not sure if this is a in issue or I'm referencing the project incorrectly but I am unable to use a type defined in a non system dll and outside the Weaver project.

Please find the attached minimal project. Look for ModuleWeaver::MakeGenericWrapper(..) Line 48 and 49.
https://github.com/ilengyel/Catfood/blob/master/IssueAttachments/TestFodyIssue4.zip

    var typeRef = ModuleDefinition.Import(typeof(Wrapper<>));   // throws: Could not load file or assembly 'AspectData, Version=...
    var typeRef = this.GetWrapperType();                        // throws: Member 'AspectData.Wrapper`1' is declared in another module and needs to be imported'
// I also tried suffixing .Resolve() to the previous two lines

    var typeRef = ModuleDefinition.Import(typeof(Wrapper2<>));    // works when type is in the weaver project

private TypeReference GetWrapperType()
{
    var assemblyRef = ModuleDefinition.AssemblyReferences.First(ass => ass.Name == "AspectData");
    var assemblyDef = AssemblyResolver.Resolve(assemblyRef.FullName);
    var typeRef = assemblyDef.Modules.Select(mod => mod.Types.FirstOrDefault(t => t.Name == "Wrapper`1")).First(type => type != null);
    return typeRef;
}

Is there a forum I can post these queries?

See https://github.com/shiftkey/Fody.AsyncErrorHandling/pull/1/files#L22R4

The link to NullGuard in the 'Why' section is wrongly set to:
https://github.com/Fody/NullGuard.Fody
instead of
https://github.com/Fody/NullGuard

Resulting in a 404 error.

Is it possible to create parametric weaver?

Scenario:
PropertyChanged weaver that will work for Prism
ModuleInit where custom class can be specified (Critical for Prism too)

It would be greatly beneficial if the file and location information can be parsed from the message string and passed onto the BuildEventArgs. The most important fileds are File, LineNumber, and Column number
Take a look at https://github.com/ilengyel/Catfood/blob/master/IssueAttachments/ParseMessage.diff, for an example, and parses a string of the format <file>(<line>,<column>): <category> <code>: <message> which is i think the standard msbuild / visual studio format. If going to take that diff, the regexpresion may need a bit more work,

now with this the error list for visual studio would look like:
https://github.com/ilengyel/Catfood/blob/master/IssueAttachments/ErrSample.png
notice that the second warning raised by the weaver is rendered the same way as the warning raised by the C# compiler

alternatively can have the LogError/Warning/Info delegates be declared with the many parameters which would save the formatting & parsing, but this might be cruddy.

    public class ModuleWeaver
    {
        public Action<string,string,string,int,int,string> LogWarning { get; set; }
        // ..
     }

and for reference, the code I used to format the message:

    if (!propertyDefinition.IsAutoProperty())
    {
        var seqPt = propertyDefinition.SetMethod.Body.Instructions[0].SequencePoint;
        var location = string.Format("{0}({1},{2})", seqPt.Document.Url, seqPt.StartLine, seqPt.StartColumn);
        this.LogWarning(string.Format("{1}: warning: '{0}' is not an auto property. Enity attributes must be applied to auto properties.", propertyDefinition, location));
    }

Looking at the readme, it's not obvious how to set up/get started with Fody. That information is all in the SampleUsage wiki page, but the name of the page doesn't really help me find it (I missed it the first time I was looking at Fody). I'd suggest renaming the page to "Getting started" or "Setting up Fody" or something.

Likewise, in the README.md, rename the "Usage" heading in the same way. And I'd also recommend removing the "Visual Studio Addin" section from that page, as it doesn't explain what the Addin is for. The SampleUsage/Getting started page explains that much better.

see #39

To refactor existing code that calls method of static classes to use constructor DI, colleague of mine created StaticClassWrapper .
The class creates an instance wrapper around a static class and for each interface method creates corresponding Proxy public method using reflection. The disadvantage is that it is required to declare( and then maintain) an interface which should have method signatures that correspond to the static methods.

When I found a reference to  Virtuosity add-in for Fody In http://stackoverflow.com/questions/12174304/is-it-recommended-to-mock-concrete-class, I hoped that I could use it instead of the wrapper. However Fody/Virtuosity doesn't processed static methods. 

Would it be possible to extend Virtuosity to create proxy instance class to wrap each static method with virtual member method?

Say I have a web service NameService with the following interface:

[ServiceContract]
public interface INameService
{
    [OperationContract]
    Person GetRandomPerson();
}

[DataContract]
public class Person
{
    [DataMember]
    public string FirstName { get; set; }

    [DataMember]
    public string LastName { get; set; }
}

And a consuming Silverlight app, which extends the Person class:

public partial class Person
{
    public string FullName { get { return string.Format("{0} {1}", FirstName, LastName); } }

    public string AddressLine1 { get; set; }
    public string AddressLine2 { get; set; }

    public string FullAddress { get { return string.Format("{0}\n{1}", AddressLine1, AddressLine2); } }
}

Using Fody and PropertyChanged, I get the following compiled code (dotPeek)

[DataMember]
public string FirstName
{
  get
  {
    return this.FirstNameField;
  }
  set
  {
    if (object.ReferenceEquals((object) this.FirstNameField, (object) value))
      return;
    this.FirstNameField = value;
    this.RaisePropertyChanged("FirstName");
  }
}

[DataMember]
public string LastName
{
  get
  {
    return this.LastNameField;
  }
  set
  {
    if (object.ReferenceEquals((object) this.LastNameField, (object) value))
      return;
    this.LastNameField = value;
    this.RaisePropertyChanged("LastName");
  }
}

public string FullName
{
  get
  {
    return string.Format("{0} {1}", (object) this.FirstName, (object) this.LastName);
  }
}

public string AddressLine1
{
  get
  {
    return this.\u003CAddressLine1\u003Ek__BackingField;
  }
  set
  {
    if (string.Equals(this.\u003CAddressLine1\u003Ek__BackingField, value))
      return;
    this.\u003CAddressLine1\u003Ek__BackingField = value;
    this.RaisePropertyChanged("FullAddress");
    this.RaisePropertyChanged("AddressLine1");
  }
}

public string AddressLine2
{
  get
  {
    return this.\u003CAddressLine2\u003Ek__BackingField;
  }
  set
  {
    if (string.Equals(this.\u003CAddressLine2\u003Ek__BackingField, value))
      return;
    this.\u003CAddressLine2\u003Ek__BackingField = value;
    this.RaisePropertyChanged("FullAddress");
    this.RaisePropertyChanged("AddressLine2");
  }
}

public string FullAddress
{
  get
  {
    return string.Format("{0}\n{1}", (object) this.AddressLine1, (object) this.AddressLine2);
  }
}

As you can see, the (locally) derived property FullAddress works as expected.
However, for the derived property FullName, nothing is added to the FirstName and LastName setters!

Request: Is it possible to weave correct setters for properties in web service references? This would be a great help :)

This is a fantastic tool - thank you! But it seems wrong to require a reference to the plugins in use.

To provide more detail, when I install the PropertyChanged.Fody NuGet package, it adds a reference to my csproj, and a reference to my packages.xml. The addition to packages.xml makes sense (it needs to be download to build), but the new reference in my csproj should not be required. Due to that reference, the nuget package build from my project transitively has a reference to PropertyChanged.Fody; which means that any projects that use my project will also download and depend on PropertyChanged.Fody. It seems to me this shouldn't be necessary, since PropertyChanged.Fody is a build-time tool, and there is no actual binary reference (please correct me if I'm wrong).

If you remove the from your *.csproj file, the weaving still works, but unfortunately NuGet doesn't have a way to exclude the package as a transitive dependency for other projects (http://nuget.codeplex.com/workitem/1956 ).

I think the right fix is to modify the nuget package so it puts the DLLs in a /tools subdir instead of a /lib subdir. After all, this is a tool, and not a dependency. I'd be happy to take this on for at least one of the plugins to ensure that this will work.

Hi!

I just wanted to let you know of another method to get the path to peverify.exe

private static string GetPathToPEVerify()
{
var peverifyPath = Path.Combine(
ToolLocationHelper.GetPathToDotNetFrameworkSdk(TargetDotNetFrameworkVersion.Version40), @"bin\NETFX 4.0 Tools\peverify.exe");
return peverifyPath;
}

Requires a reference to Microsoft.Build.Utilities.v4.0.

I suspect that the existing code in Verifier.cs might break for non-english versions of windows where the programfiles folder has another name.

Regarding this page:
https://github.com/Fody/Fody/wiki/SampleUsage

The last link on this page, labeled “Virtuosity” and linking to https://github.com/SimonCropp/Virtuosity, is a 404.

Could you make a Fody package, that inserts itself into a project and sets up Fody, without having to install the Visual Studio extension?

That way all the other fody packages could depend on it and would make getting started with Fody slightly easier.

AddinFilesEnumerator.cs line 27, the search should be on the file name not the full path.

    IEnumerable<string> GetAllAssemblyFiles(string packageName)
    {
        var packageFileName = packageName + ".dll";
        return fodyFiles.Where(x => x == packageFileName);
    }

should be

    IEnumerable<string> GetAllAssemblyFiles(string packageName)
    {
        var packageFileName = packageName + ".dll";
        return fodyFiles.Where(path => packageFileName.Equals(Path.GetFileName(path), StringComparison.OrdinalIgnoreCase));
    }

thnx

https://github.com/SimonCropp/Fody/wiki/SampleUsage

When INotifyPropertyChanged / INotifyPropertyChanging declared in a base class that is in another project that is not Fody enabled, I have to manually implement OnPropertyChanged / OnPropertyChanging in the base class.

Here is an example project:
http://dl.dropbox.com/u/46508238/github.com/TestFody-2012-10-14.zip

The example above contains 2 projects, 7 classes and 3 unit tests (Test1 pass, Test2 and Test3 fail):

• TestFody.csproj (Fody enabled)
  • UnitTest1.cs
  • ViewModel1.cs
  • ViewModel2.cs
  • ViewModel3.cs
• ClassLibrary1.csproj (Fody not enabled)
  • BaseViewModel1.cs
  • BaseViewModel2.cs
  • BaseViewModel3.cs

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void Test1()
    {
        // Base class has OnPropertyChanged & OnPropertyChanging implemented.
        // Text property declared in sub class.
        Test(new ViewModel1()); // Pass
    }

    [TestMethod]
    public void Test2()
    {
        // Base class DOES NOT have OnPropertyChanged & OnPropertyChanging.
        // Text property declared in sub class.
        Test(new ViewModel2()); // Fail
    }

    [TestMethod]
    public void Test3()
    {
        // Base class has OnPropertyChanged & OnPropertyChanging implemented.
        // Text property declared in base class.
        Test(new ViewModel3()); // Fail
    }

    static void Test(dynamic vm)
    {
        bool isPropertyChangedFired = false;
        bool isPropertyChangingFired = false;

        (vm as INotifyPropertyChanged).PropertyChanged += 
            (sender, e) => isPropertyChangedFired = true;
        (vm as INotifyPropertyChanging).PropertyChanging += 
            (sender, e) => isPropertyChangingFired = true;

        vm.Text = string.Empty;

        Assert.IsTrue(isPropertyChangedFired);
        Assert.IsTrue(isPropertyChangingFired);
    }
}

public class ViewModel1 : BaseViewModel1
{
    public string Text { get; set; }
}

public class ViewModel2 : BaseViewModel2
{
    public string Text { get; set; }
}

public class ViewModel3 : BaseViewModel3
{
}

public class BaseViewModel1 : INotifyPropertyChanged, INotifyPropertyChanging
{
    public event PropertyChangedEventHandler PropertyChanged;
    public event PropertyChangingEventHandler PropertyChanging;

    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    protected void OnPropertyChanging(string propertyName)
    {
        if (PropertyChanging != null)
            PropertyChanging(this, new PropertyChangingEventArgs(propertyName));
    }
}

public class BaseViewModel2 : INotifyPropertyChanged, INotifyPropertyChanging
{
    public event PropertyChangedEventHandler PropertyChanged;
    public event PropertyChangingEventHandler PropertyChanging;
}

public class BaseViewModel3 : INotifyPropertyChanged, INotifyPropertyChanging
{
    public string Text { get; set; }
    public event PropertyChangedEventHandler PropertyChanged;
    public event PropertyChangingEventHandler PropertyChanging;

    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }

    protected void OnPropertyChanging(string propertyName)
    {
        if (PropertyChanging != null)
            PropertyChanging(this, new PropertyChangingEventArgs(propertyName));
    }
}

Improve docs on Gallery page for INotifyPropertyWeaver folks to get the right Weaver. Wasn't obvious.

Both Fody and Nuget assumes that each dll belongs to one solution. With regards to nuget, this isn't so much of an issue, since it will just add a reference in the proj file to the required dlls.

However Fody doesn't store the paths to the weaving dlls and hence needs to search for them. It apparently does so in the solution folder and the nuget folder (which is in the solution folder).

A common pattern when dealing with WCF is to have a common project that defines the service contract across the WCF connection. For obvious reasons this project belongs to both the client and the server solutions.

This is where problems start. When I create a client-server solution pair with a common interface project. When building the common interface project (with Fody enabled) either project will look for the weave dlls in their own solution's nuget folder.

I've tried overriding the nuget directory in the project but its not working. I can't override the nuget directory on the solution level because I am using MsBuild/MsDeploy, which you have to target the website you want to deploy.

Error 6 The "Fody.WeavingTask" task failed unexpectedly.
WeavingException: Invalid MessageImportance in config. Should be 'Low', 'Normal' or 'High' but was ''.
at BuildLogger..ctor(String messageImportance) in d:\BuildAgent-01\work\f05c4749eee8ee8f\Fody\BuildLogger.cs:line 25
at Processor.Execute() in d:\BuildAgent-01\work\f05c4749eee8ee8f\Fody\Processor.cs:line 36
at Fody.WeavingTask.Execute() in d:\BuildAgent-01\work\f05c4749eee8ee8f\Fody\WeavingTask.cs:line 29

In ExceptionExtensions you have IsNoDefinition method detecting "property not found" exceptions. Unfortunately it depends on english only .NET installation. In localized versions, this error message varies. I actually get this one (russian variant):
"ModuleWeaver" не содержит определения для "AssemblyPath"
StackTrace:
в CallSite.Target(Closure , CallSite , Object , String )
в System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
в WeaverInitialiser.SetAssemblyPath(Object instance) в d:\BuildAgent-02\work\7fc5d38aa1be8266\FodyIsolated\WeaverInitialiser.cs:строка 170
в WeaverInitialiser.SetProperties(WeaverEntry weaverEntry, Object weaverInstance) в d:\BuildAgent-02\work\7fc5d38aa1be8266\FodyIsolated\WeaverInitialiser.cs:строка 45
в WeaverInitialiser.SetProperties(WeaverEntry weaverEntry) в d:\BuildAgent-02\work\7fc5d38aa1be8266\FodyIsolated\WeaverInitialiser.cs:строка 32
в WeaverInitialiser.Execute() в d:\BuildAgent-02\work\7fc5d38aa1be8266\FodyIsolated\WeaverInitialiser.cs:строка 20
в InnerWeaver.Execute() в d:\BuildAgent-02\work\7fc5d38aa1be8266\FodyIsolated\InnerWeaver.cs:строка 36
Source:
Anonymously Hosted DynamicMethods Assembly
TargetSite:
System.Object CallSite.Target(System.Runtime.CompilerServices.Closure, System.Runtime.CompilerServices.CallSite, System.Object, System.String)
HomeDesign.Model

Here is another one: http://catel.codeplex.com/discussions/391648
This seems to be German message.

Seems like detecting exception types by Message isn't good idea. Maybe reimplement it with reflections? (GetType().GetProperty... etc.).

Edit: This may just be a FluentAssertions problem. You can close this.

If all traces of tests can be removed before deployment then we can have test collocated with the functionality they are testing. ie test can be located in the same assembly. This allows for a much more logic grouping of functionality.

so for example the PersonCreationHandlerTests.cs can exist in the same directoy as PersonCreationHandler.cs

So far the plan would be to perform the following

• Remove types marked with [TestFixture] attribute (or equivalent for diff test tools)
• Remove types ending in Mock. Perhaps configurable so people can use Stub or something else
• Possibly remove types in certain namespaces. eg TestHelpers. Possibly configurable
• Remove references to test frameworks, nunit, xunit etc
• Remove references to mocking frameworks, moq, nsubstitute, FakeItEasy etc
• Allow removal of other references via configuration
• Possibly a [Remove] attribute to be applied to specific types and members
• Option to validate final assembly for referential correctness

Anything missing? Thoughts?

[Enhancement] Would like to specify a weaver path directly in the config file e.g.

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <PersistibleIEntity WeaverPath="..\PersistibleIEntity\bin\Debug\PersistibleIEntity.dll" />
</Weavers>

https://github.com/ilengyel/Catfood/blob/master/IssueAttachments/SpecifyWeaverPath.diff

Further enhancement: support MsBuild properties eg, specify $(Configuration) instead of hardcoding Debug in the path

• scan projects in current solution and check if they have Fody configured. if they do re-use the Tools\Fody dir
• look in the same location you store your nuget packages. if there is a Tools\Fody at the same level then use that

failing above two prompt using a combination of

• sibling Tools dir to nuget packages dir.
• Tools dir from a tree walk. perhaps stop on .git or .hg found
• Solution\Tools

WeaverInitializer.cs

    public void SetProperties(WeaverEntry weaverEntry, object weaverInstance)
    {
        // ....
        SetLogError(weaverInstance);
    }


   void SetLogError(dynamic instance)
    {
        try
        {
            instance.LogError = new Action<string>(s => Logger.LogError(null, s));
        }
        catch (RuntimeBinderException exception)
        {
            if (exception.IsNoDefinition())
            // ...
        }
    }

So I solved the assembly locking issue without compromising performance.

It involves boostraping the assembly loading in MSBuild. see here for an example
https://github.com/SimonCropp/Pepita/blob/master/PepitaGet.targets
Yes it is something like MSBuild inception but it works.

So this opens the door to make Fody a nuget package and decommissioning the VSIX.
Fody addins nugets would then be dependent on this new Fody nuget

Before I go off and do the final research/work Is this even worth doing?

I like the idea of moving to a fully nuget solution. But it has been point out to me that "Simon is not a typical user".

So any thoughts/feedback would be appreciated

So, I have solution with common Portable Library project and projects for WinRT, WP8, WP7 and so on
How can I use AsyncErrorHandling?
Do I have to put custom AsyncErrorHandling class into every project? Or can I create one class in Portable Library project and then weaver will find it by reference from UI project?

Some directories - such as SQL Server in the example below - have directories with specific access restrictions that a build user may not be able to see. The scan should just ignore these directories and continue.

MSBuild log excerpt:

"C:\Builds\Test\FodyTest.sln" (default target) (1) ->
"C:\Builds\Test\FodyTest\FodyTest.csproj" (default target) (2) ->
(WinFodyTarget target) ->
MSBUILD : error : Fody: An unhandled exception occurred:\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : Exception:\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : Access to the path 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA' is denied.\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : StackTrace:\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at System.IO.FileSystemEnumerableIterator1.AddSearchableDirsToStack(SearchData localSearchData)\r [C:\Builds\Test\FodyTest\FodyTest.csproj] MSBUILD : error : at System.IO.FileSystemEnumerableIterator1.MoveNext()\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at System.Collections.Generic.List1..ctor(IEnumerable1 collection)\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at AddinFinder.b__0(String x) in c:\Code\Fody\Fody\AddinFinder\AddinFilesEnumerator.cs:line 13\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at System.Linq.Enumerable.d__142.MoveNext()\r [C:\Builds\Test\FodyTest\FodyTest.csproj] MSBUILD : error : at System.Collections.Generic.List1..ctor(IEnumerable1 collection)\r [C:\Builds\Test\FodyTest\FodyTest.csproj] MSBUILD : error : at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at AddinFinder.CacheAllFodyAddinDlls() in c:\Code\Fody\Fody\AddinFinder\AddinFilesEnumerator.cs:line 12\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at AddinFinder.FindAddinDirectories() in c:\Code\Fody\Fody\AddinFinder\AddinSearchDirectories.cs:line 15\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at Processor.FindWeavers() in c:\Code\Fody\Fody\Processor.cs:line 111\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at Processor.Inner() in c:\Code\Fody\Fody\Processor.cs:line 88\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : at Processor.Execute() in c:\Code\Fody\Fody\Processor.cs:line 46\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : Source:\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : mscorlib\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : TargetSite:\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : Void WinIOError(Int32, System.String)\r [C:\Builds\Test\FodyTest\FodyTest.csproj]
MSBUILD : error : [C:\Builds\Test\FodyTest\FodyTest.csproj]

Look at spelling of "Exception" in method name. Fix it please, because users will copy it with error and it won't work. Weaver just won't find a right method.

public static class AsyncErrorHandler
{
public static void HandleExcption(Exception exception)
{
Debug.WriteLine(exception);
}
}

From https://github.com/SimonCropp/Fody.AsyncErrorHandling

Hi guys!

I found a (very) annoying bug that was pretty hard to localize: If I'm using Fody (the new version from nuget) in a project, it breaks somehow the ability to inspect variables while debugging. Please have a look on the two screenshots. The first one is taken without Fody activated (I'm using notifypropertychanged.fody for this demonstration).
The second is taken with Fody.
Do you see the difference? The application is a very simple console application, doing in fact nothing than adding two integer values.

Can you reproduce this behavior? And more important: Can you solve it? Everything was working fine with Fody not from Nuget.

Best regards from Germany

Rufus

Hi!

First of all I have a question about the WeavingTask and the various options that seems to be configurable. Is it some sort of user interface in the VS extension that lets the developer alter these values or do they have to edit the targets file manually?

The only menu items available are enable/disable and does not seem to have a "Configure" menu item that this blog post suggests.

http://simoncropp.com/simpleaopwithfody

My next questions is related to verifying weaved assemblies. It would be nice if the WeavingTask could have an option that make it possible to verify the correctness of the assemblies that are getting weaved. (bool VerifyAssembly).

I would be happy to contribute here as long as this is something you might consider as a valid pull request.

Best regards

Bernhard Richter