Fody.WeavingTask task fails unexpectedly (due to missing directory)
ramondeklein opened this issue · comments
I am using Fody v3.3.3 with the PropertyChanged.Fody v2.6 weaver and I often get the MSB4018 error during build in Fody\build\Fody.targets(32,5). It shows the following stack-trace:
The "Fody.WeavingTask" task failed unexpectedly.
System.IO.DirectoryNotFoundException: Could not find a part of the path '...\MyAmazingProject\obj\Debug\'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.StreamWriter.CreateFile(String path, Boolean append, Boolean checkHost)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize, Boolean checkHost)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding)
at System.IO.File.WriteAllLines(String path, IEnumerable`1 contents)
at Fody.WeavingTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
When I check the directory does exist and when I build the failing project again, then sometimes it works. It's quite random, but I have never seen this with v3.2.10.
Thanks Ramon
Just checking have u read the issue template? https://github.com/Fody/Fody/blob/master/.github/ISSUE_TEMPLATE/bug_report.md
Yes, so I don't expect that the Fody team will fix this and this issue will be closed. I'm sorry to hear that Fody went this path, but this issue report is not the place to discuss it...
unfortunately it is the place to discuss it since it is the point where much of the time and effort is spent https://github.com/Fody/Fody#honesty-system--enforcement
As for the other points in the issue template, you have not provided a repro, nor have you shown how you have attempted to fix the issue
The problem is that it isn't reproducable. When I do a full rebuild of our solution (about 60 projects), then some of the projects fail with the error listed above. When I build the failing project, then it often fails 2-3 times and then it works fine. I have created a smaller solution, but that solution always works. Just wanted to report the issue, because I never encountered it with v3.2.10 and it started with v3.3.3. I locked to v3.2.10 and have no problems.
To get back at the 'Patron' matter. It's difficult to start paying for software that always has been free to use. I use Fody for a commercial company and our team (7 developers) use Fody. This means that we suddenly we need to pay at least $21 per month to keep using Fody. We only use free software or software that has one-time license fee, because these recurrent payments make it very difficult to administer. If all open-source projects start charging money, like Fody does, then it becomes a hell to administer. What makes it also a bit hard is that Fody changes the rules, while playing the game.
Don't get me wrong, but I get that developers need to be paid for their work. I am a professional software developer myself, but I have also some open-source projects on GitHub that I support for free. It's still a hobby to me. I do support it on a best effort basis and if you need professional support, then look elsewhere. Maybe Fody has become too popular and it takes too much time or the situations has changed with the maintainers.
I really like Fody (although I only use PropertyChanged.Fody) and think it's professional grade software, but we need to reconsider what to do. The current model makes it a bit hard to use in commercial environments.
so this looks to be the offending line https://github.com/Fody/Fody/blob/master/Fody/WeavingTask.cs#L91 which would point to this https://github.com/Fody/Fody/blob/master/Fody/Fody.targets#L49 passing in a strange value. can u enable detailed logging in msbuild
then after the build has failed check what the value of $(IntermediateOutputPath) and $(FodyCopyLocalFilesCache) resolve to so we know what is being passed in to IntermediateCopyLocalFilesCache.
Looking back through the history the last time that was touched was here #583, so perhaps @tom-englert has some insight.
Also can u try fody version 3.2.13 to see if the problem was introduced in 3.2.14.
I have re-ordered some of you statements so i can answer them in a grouped way
It's difficult to start paying for software that always has been free to use. I use Fody for a commercial company and our team (7 developers) use Fody. What makes it also a bit hard is that Fody changes the rules, while playing the game. Maybe Fody has become too popular and it takes too much time or the situations has changed with the maintainers.
Unfortunately i was getting so little help from the community and fody was getting more popular. Like most of the my OSS efforts, i dont actually use fody and havnt done so for over 12 months. but it was consuming a min of 5 hours a week of my personal time. At one point last year I did experiment with taking a break from fody. issues piled up and the community did no step in. In several interactions i effectively pleaded with the people consuming fody to help support it with their time eg Fody/PropertyChanged#247 (comment). so this has been a long time coming. It was either find a way to buy some time/help, or lock all the fody repos as readonly and let competing forks battle it out
I suggest you also have a read of some of these https://github.com/Fody/Fody#why-charge-for-open-source
This means that we suddenly we need to pay at least $21 per month to keep using Fody. We only use free software or software that has one-time license fee, because these recurrent payments make it very difficult to administer. If all open-source projects start charging money, like Fody does, then it becomes a hell to administer.
recurrent payments can seem daunting, but you must be already doing them? Every cloud hosted service works this way, most orgs license MS software this way. And unfortunately it has to be an ongoing fee, since the const of maintaining software is ongoing, especially in the .net space with how fast netcore and netstandard is evolving. You are a developer, would you sign up to a single payment job to build software on the caveat that you need maintain that software in perpetuity. Note that many software vendors are moving this way, even where companies seem to be a "once off payment" it is often "one year of free upgrades and support".
I really like Fody (although I only use PropertyChanged.Fody) and think it's professional grade software, but we need to reconsider what to do. The current model makes it a bit hard to use in commercial environments.
How can i make this easier? Would a yearly payment option help?
I will work on the project on Thursday and we'll try some versions of Fody and use detailed logging and get back to you...
It's great to notice the amount of responsibility you have to the Fody project. But your responsibility ends with releasing the code as-is. You shouldn't feel obliged to answer GitHub issues or release bugfixes, make it compatible with new frameworks, ... Don't get me wrong, because your work is highly appreciated, but you shouldn't feel obliged to do it. If you don't want to maintain it anymore, then feel free to terminate your involvement. Eventually, the community will take over or the project will come to an end. Or you make it a commercial product and expect people to pay for it (one-time fee would be best).
Recurring payments are a pain, when you work in a larger organization. Especially the variable amounts (like with Azure) are a problem. Managers want to work with budgets and Azure can ruin your budget in a month if your developers go crazy. We try to minimize recurrent payments to the things that we really have to use. I think, when I bring up Fody for $250/year that it won't pass :-(
Another issue is that most companies need to have an invoice to make sure that something is paid. Without an invoice, the company cannot process the payment. Companies can substract these costs from their profits and reduce taxes and get VAT returns. For that reason, most companies don't pay anything without an invoice. And if they can keep using it (like Fody), they will probably won't do anyway.
I am a freelance software engineer, so I wouldn't mind to pay $36/year to support your software. I just became a Patron, because I understand your problem and appreciate your work. Unfortunately, I am not the decision maker at the company I work for, but I will bring up the issue.
Another issue is that most companies need to have an invoice to make sure that something is paid. Without an invoice, the company cannot process the payment
OpenCollective produces invoices for backers https://opencollective.com/faq/backers
Recurring payments are a pain, when you work in a larger organization. Especially the variable amounts (like with Azure) are a problem.
fody wont be variable amounts. if a company wants a yearly or fixed amount i attempt to accommodate that when it occurs
And if they can keep using it (like Fody), they will probably won't do anyway.
thats fine, if they are willing to take the risk of bugs and features possibly being ignored, closed, or prioritised very low. but i suggest they compare the perceived saving, of not paying for fody, with the cost of a bug taking longer to get fixed, if at all. just one estimate but from https://crossbrowsertesting.com/blog/development/software-bug-cost/:
The costs go up as the bug moves through the SDLC. For example, IBM estimates that if a bug costs $100 to fix in Gathering Requirements phase, it would be $1,500 in QA testing phase, and $10,000 once in Production
I will work on the project on Thursday and we'll try some versions of Fody and use detailed logging and get back to you...
any luck?
Hi @SimonCropp, I'm not the original issue opener, but I did recently run into this problem. It was originally only happening on a fresh run of the solution, essentially only after a clone or manual clean of all non tracked files/folders, but recently started to happen at random.
Unfortunately when I run with detailed or diagnostic output, I'm not able to find any information corresponding to
Hope this info helps in some capacity!
Edit: I can also confirm that 3.2.13 appears to not have this bug. However, as it is intermittent I am not 100% certain.
Looking at
Lines 3 to 12 in 55f9d7a
its hard to understand how
$(FodyCopyLocalFilesCache) can be ever empty, or missing at all?
I think @KairuByte may have a different problem than @ramondeklein.
$(FodyCopyLocalFilesCache) is not empty in the OP, as you can see obj\Debug in the error message. It rather seems that the directory itself doesn't exist. But it definitely should exist at this point.
@KairuByte if you use the old (non-SDK) csproj format, make sure you import the Fody.targets file from the correct version. Sometimes you may end up with a messed project file (for instance after a bad merge). Try uninstalling Fody, and remove every mention to Fody in the csproj file, then install it again.
Also, detailed or diagnostic output is a mess. Use a binary log instead (call msbuild with the /bl switch). see http://msbuildlog.com/ for more info.
@SimonCropp I have not been able to reproduce this issue. If I encounter this issue again, then I'll rerun with detailed logging enabled.
@ltrzesniewski We use Paket to manage all our packages, so we shouldn't have any differences between package versions. We are still working with the old CSPROJ format.
@ramondeklein oops sorry, I just noticed my message above was actually intended for @KairuByte, sorry about that.
I'm currently on Version 3.3.2 and am experiencing this problem in isolation on my laptop. The same code works fine on a desktop machine I have.
While I don't think its relevant, the laptop is running Windows 10, and the desktop is running Windows 7
I use Visual Studio 2017 on both machines, and the CSProj is the old format.
I have attempted to clean up my packages and restore all my packages but it made no difference.
I've verified that the FodyWeavers.xml are setup correctly, and I've also verified entries for fody in the csproj are correct.
While I am able to reproduce this bug, is there any troubleshooting steps I can take that would be helpful in furthering the analysis?
@PassivePicasso upgrade fody to 3.3.5, there is some additional logging to narrow down this issue.
@tom-englert
I should note, I didn't even think about it at first, but Rebuild seems to work fine, however if I start the project which runs a normal build then it fails, even if I first do a rebuild.
However, after upgrading to 3.3.5 the solution built without issue.
Undoing all changes via git causes the bug to come back
Undoing only the changes to the app.config has no effect
Reverting the version back to 3.3.2 after upgrading to 3.3.5 via NuGet also builds without issue.
At this point If all app.config changes are removed it continues to build without issue
At this point I used git to undo all changes and manually implement the changes to the CSProj files, the solution continued to build without issue.
These were mostly ordering changes, however one project did have an import for an older version of fody 1.29.4 which I removed.
However, at this point I reverted all changes via git and now I can no longer reproduce the bug.
Everything builds now even without there being any changes to the project files.
I did try to do a clean and then build to see if it could reproduce the issue at this point but it built without issue.
Perhaps there is some meta data that is causing the issue, such as data in the .vs folder for the solution.
This would align with the fact that the exact same solution setup compiled in one VS instance, while not in another.
The .vs folder data may not be the same in this case as it is not carried across in source control.
Next time I encounter this issue I'll try to remember to do some additional tests. I'll probably start with blowing away the .vs folder to see if it has an impact
one project did have an import for an older version of fody 1.29.4 which I removed
This could pretty much be the cause of the issue. The old version can override the MSBuild targets that Fody provides. The code could work fine on your desktop machine because I suppose that version of Fody was never restored there and the file was unavailable.
Anyway it's not the first time a bad restore or merge causes issues (there have been cases with multiple references to the Fody.targets file from different versions in the same project etc). Maybe we should add a version check.
I did remove the entire contents of the packages folder and do an Update-Package -Reinstall and that didn't resolve the issue, this was my first attempt to resolve the problem. It did not work.
That doesn't necessarily mean it didn't also install the wrong version along side the right one, I didn't check for this specific case.
I have manually restored the wrong version into the packages folder, and while the error has changed it did cause the solution to fail to build.
Once I removed the wrong versions it went back to building correctly.
I don't believe this is definitive however, as the error did change, I'm not receiving the DirectoryNotFoundException.
The odd thing is, it seems to change each time I remove the bad version, compile, put it back, compile.
After the first time restoring the bad version I received a different error about an assembly load failing due to a weaver task missing some element, unfortunately I didn't record the error so I'm not sure about the specifics.
After I removed it and was able to compile successfully, I added it back and got a separate error;
Note: I removed the actual solution path and replaced it with $(SolutionPath)
error MSB4062: The "Fody.UpdateReferenceCopyLocalTask" task could not be loaded from the assembly
I'm not sure if this is related to this issue or if its a red herring. Other users might check to see if they have a faulty version in their $(SolutionPath)\Packages folder and see if any of their CSProj files has an extra import for an older fody version.
I can reliably break my build by having an extra import for Fody 1.29.4 targets, as well as having that version in my $(SolutionPath)\Packages folder while having the packages.config targetting 3.3.2
Edit: I removed the solution path above but I realized there may be a relevant factor there, which is that my path contains spaces...
$(SolutionPath) == C:\Projects\Dashboard\Pro Dash Solution\
Yeah that MSB4062 error is right, because UpdateReferenceCopyLocalTask did not exist in 1.29.4. If you're importing multiple versions of Fody.targets, they will interfere with each other and cause such errors. Nothing surprising here.
If you manage to get the DirectoryNotFoundException and you don't have multiple versions of Fody.targets referenced, it would be helpful if you could get a binary log of the build. The easiest way is to call msbuild YourSolution.sln /bl from the VS developer command prompt, you may need to add /t:Rebuild if you want to rebuild the solution. Another way to capture such a log is to use the "Project System Tools" VS extension. Make sure you have no private info in your environment variables, as they will be captured in the log. Check with http://msbuildlog.com if the resulting binlog file is safe for you to upload.
I unexpectedly got this error while looking into another issue, and I can't explain the behavior I see:
This happens on the first build of https://github.com/jakubsuchybio/fody-costura-build-repro in an isolated environment (separate globalPackagesFolder in nuget.config).
IntermediateCopyLocalFilesCache is supposed to be set to $(IntermediateOutputPath)$(FodyCopyLocalFilesCache) but $(FodyCopyLocalFilesCache) ends up blank. The target gets a directory path but it expects a file path, and it goes boom 💥 .
It seems that the <PropertyGroup> in Fody.targets was ignored (the Fody properties are clearly not set, as if the MSBuild evaluation phase was skipped), but the task is still called somehow, and it requires the FodyAssembly property to be set in order to be located in the first place.
If you restart VS then everything works fine afterwards. Also, everything works fine in the first place if you compile from the command line. This leads me to believe it's a VS caching quirk, but has anyone experienced this kind of behavior before?
Here's the VS binary build log: dir-not-found.zip
I also get this error after cloning a repo and building the project in it for the first time. The problem goes away after a few rebuilds (I do not even need to restart VS).
The error message is:
Fody: Error writing IntermediateCopyLocalFilesCache: Could not find a part of the path ...
@drapka r u using the old or the new project system?
BTW to be using Fody you should be a patron of Fody.
I am still using the old project system (with VS 2015). However, I can confirm that his happens even with VS 2017.
Thank you for your note about being a patron of Fody, I will consider it (I like the Open Collective idea).
can u try version 4.0.1
I should have some time this week, I'll attempt to recreate the problem and then implement this latest version to see if it will resolve it.
I have the same problem with the old version and I have no issues with Fody, but hasn't anyone wondered what the hell is going on with FodyCopyLocalFilesCache ? How come it disappears into a thin air? I mean this could be a bug in Visual Studio (I use VS 2017) or in msbuild itself.
@MarkKharitonov the current version of Fody no longer uses FodyCopyLocalFilesCache. i suggest you update to the current stable version
@SimonCropp - absolutely, I have already done it. But the fact itself that a property disappears. Does not it bother anyone? I mean this could be a serious bug in Visual Studio or msbuild. How come the property does not exist when it was clearly defined? How come the code compiles cleanly on the command line with msbuild, but fails when compiling the same from scratch in VS? Aren't anyone curious as to what on Earth happens there?
@MarkKharitonov perhaps raise it with the msbuild team
Yes, need to create a minimal reproduction. Will take time. Because it bewilders me.