Giters

Fody / ConfigureAwait

Configure async code's ConfigureAwait at a global level

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Package unlisted on Nuget

Anapher opened this issue · comments

commented

Just had troubles installing the package in a new project because I couldn't find it and then I saw that you unlisted the package. I'm using this package in every project I'm currently developing and I would really like to know the reason, it worked very well for me and saved me a lot of time. Would you mind changing the status again, because it's easier to just click install in the GUI than typing "Install-Package ConfigureAwait.Fody -Version 1.1.0" every time (that command still works).

EDIT: Just taking the chance to thank you for this project, I'm not only using the addin but I learned a lot from your code about weaving and IL code (especially how you hook up the async stuff), you made an incredible good job here, it's a shame that this repository still has so few stars, I'm recommending this addin actively to others.

commented

I would like to know the reason too:

  • If it is unlisted because it is not actively maintained, we can fork or transfer the repo.
  • It it is unlisted because it is buggy, people should stop using it.

So it would be nice to have some kind of explanation.

commented

Perhaps the reasoning behind this post may be part of the explanation.

commented

But I'm using this nuget package also with WPF applications, the article even states that

However, I still recommend that you use it in your core libraries

commented

I would really like to know what exactly is buggy/broken. Because I'm heavily using this addin, I would like contribute to it and fix these bugs (@distantcam).
Because I wanted to learn and I required this addin for my .Net Core/Standard projects, I made a rewrite (no fork because I had a few problems with the code style used in this repo, but I used the core mechanism from this repo).

commented

First of all, dotnetcore does not have a synchronizationcontext. So no issue there:
http://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html

For .NET framework projects, I found this solution, which I am using, instead of this library:
https://blogs.msdn.microsoft.com/benwilli/2017/02/09/an-alternative-to-configureawaitfalse-everywhere/

commented

@DavidLievrouw But 1) as much as I understand, .Net Standard Libraries are still affected when used in WPF/WinForms applications and 2) this synchronization context thing is kind of hacky, the developer who handels the library must know about this and the ConfigureAwait approach is much cleaner (especially with the library).

commented

@Anapher

  1. True.

  2. I understand, but that depends on how you look at it. On the one hand, when you use this library, its functionality is invisible at code-time. The hacky way makes it explicit.

It depends on how and where you use it, I guess. For example, I use it in the NancyFx pipeline. NancyFx allows it to be cleanly "decorated" around a request.

Anyway, getting off topic here. At least the reason for unlisting is clear.

commented

releasing an updated 2.0 shortly