{"action":"created","issue":{"url":"https://api.github.com/repos/Fody/NullGuard/issues/90","repository_url":"https://api.github.com/repos/Fody/NullGuard","labels_url":"https://api.github.com/repos/Fody/NullGuard/issues/90/labels{/name}","comments_url":"https://api.github.com/repos/Fody/NullGuard/issues/90/comments","events_url":"https://api.github.com/repos/Fody/NullGuard/issues/90/events","html_url":"https://github.com/Fody/NullGuard/issues/90","id":273545226,"node_id":"MDU6SXNzdWUyNzM1NDUyMjY=","number":90,"title":"NETStandard 2.0 library + NullGuard 1.6.2 breaks breakpoints","user":{"login":"SirUppyPancakes","id":12754240,"node_id":"MDQ6VXNlcjEyNzU0MjQw","avatar_url":"https://avatars1.githubusercontent.com/u/12754240?v=4","gravatar_id":"","url":"https://api.github.com/users/SirUppyPancakes","html_url":"https://github.com/SirUppyPancakes","followers_url":"https://api.github.com/users/SirUppyPancakes/followers","following_url":"https://api.github.com/users/SirUppyPancakes/following{/other_user}","gists_url":"https://api.github.com/users/SirUppyPancakes/gists{/gist_id}","starred_url":"https://api.github.com/users/SirUppyPancakes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SirUppyPancakes/subscriptions","organizations_url":"https://api.github.com/users/SirUppyPancakes/orgs","repos_url":"https://api.github.com/users/SirUppyPancakes/repos","events_url":"https://api.github.com/users/SirUppyPancakes/events{/privacy}","received_events_url":"https://api.github.com/users/SirUppyPancakes/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":21,"created_at":"2017-11-13T19:16:53Z","updated_at":"2018-08-30T19:46:25Z","closed_at":null,"author_association":"NONE","body":"When using a NETStandard 2.0 library with NullGuard 1.6.2, breakpoints are not hit with the message: \"The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line...\".\r\n\r\nI have attached a VS-2017 solution that reproduces the issue. Simply place a breakpoint anywhere in the \"Test\" method of \"Class1\" and debug \"ConsoleApp1\".\r\n[ConsoleApp1.zip](https://github.com/Fody/NullGuard/files/1468154/ConsoleApp1.zip)\r\n"},"comment":{"url":"https://api.github.com/repos/Fody/NullGuard/issues/comments/417444530","html_url":"https://github.com/Fody/NullGuard/issues/90#issuecomment-417444530","issue_url":"https://api.github.com/repos/Fody/NullGuard/issues/90","id":417444530,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNzQ0NDUzMA==","user":{"login":"SimonCropp","id":122666,"node_id":"MDQ6VXNlcjEyMjY2Ng==","avatar_url":"https://avatars1.githubusercontent.com/u/122666?v=4","gravatar_id":"","url":"https://api.github.com/users/SimonCropp","html_url":"https://github.com/SimonCropp","followers_url":"https://api.github.com/users/SimonCropp/followers","following_url":"https://api.github.com/users/SimonCropp/following{/other_user}","gists_url":"https://api.github.com/users/SimonCropp/gists{/gist_id}","starred_url":"https://api.github.com/users/SimonCropp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SimonCropp/subscriptions","organizations_url":"https://api.github.com/users/SimonCropp/orgs","repos_url":"https://api.github.com/users/SimonCropp/repos","events_url":"https://api.github.com/users/SimonCropp/events{/privacy}","received_events_url":"https://api.github.com/users/SimonCropp/received_events","type":"User","site_admin":false},"created_at":"2018-08-30T19:46:25Z","updated_at":"2018-08-30T19:46:25Z","author_association":"MEMBER","body":"Given enough people think this issue is important/critical enough to remain open i will re-open this.\r\n\r\nHowever given it is unlikely to be fixed any time soon, and it is critical, i think the best course of action would be to mark this repo and nuget as \"do not use\". by this i mean adding to the nuget and the top of the readme the text\r\n\r\n> This project has a critical but that has not been fixed. link. only use this project if the bug does not effect you, or alternatively submit a pull request that fixes the bug.  \r\n\r\n\r\n### on closing stale issues\r\n\r\nClosing stale issues does not imply they cannot be re-opened, as i have done here.\r\n\r\nI admit i was perhaps to over zealous in some of the issues i closed. but i figured calling issue bankruptcy, and cleaning the back log, was better than marking the majority of my projects as abandoned and ignored.  \r\n\r\n@ulrichb \r\n\r\n> IMO this would be much better and you could use a \"-label:XXX\" filter to solve the problem on having too much noise on the issues list.\r\n\r\nIf i was managing a small number of projects i can see this helping mitigate the signal to noise. but currently i have [36 fody project](https://github.com/Fody), [18 NServiceBus projects](https://github.com/NServiceBusExtensions/), [16 active projects under my account](https://github.com/SimonCropp?tab=repositories), and probably another 5 i contribute to heavily. moving between the various mechanisms of managing a repo (octokit, email, github etc), and the differences/inconsistencies in how projects are managed means labels is not a viable way forward \r\n\r\n> When just reading the title / the reporter's description + the fact that it's closed (without any label) clearly speaks \"this bug has been fixed\"\r\n\r\nI dont think this is the case. only issues that are closed and have a milestone should be considered fixed. should i add that to the readme\r\n\r\nI could add a label. but the actual status \"closed because no one thought it important enough to put the effort in to fixing it\" seems a little verbose\r\n\r\n@j2jensen \r\n\r\n> If you'd like I can create a pull request with a stale.yml file in it. I could also create a new issue to track it. If you want to give me the appropriate permissions I'd be willing to add the stalebot app.\r\n\r\ni have installed stalebot, and will be tweaking its settings over the next few weeks. thanks for the offer of help\r\n\r\n> What's happened here, instead, is that there are zero open issues on this project, and 70 Closed issues. Someone looking at using this library is going to assume this means that you're staying on top of all the issues, and that NullGuard is very stable.....\r\n\r\ni can see \"how to choose an active project\" as being difficult. i would postulate that \"number of open issues is a poor measure. look at nullguard, this single issue is probably enough that people should avoid using it. so to get a \"picture of repo from open issues\" you would need to read every issue and judge the criticality of every issue.\r\n\r\nMy approach to picking projects to use is as follows:\r\n\r\nreview the code base. if it is poor quality the perhaps avoid. if it is too complex for me to understand, then that is problematic. since if i do find a bug or want a feature it is not possible for me to submit a PR. this is a risk and you need to consider how to mitigate it. you dont want to be in a situation where you are running a production codebase on a tool that you cannot fix and are relying on people to spend their free time to fix it for you. consider assigning someone on your team to spend the time to get up to speed. perhaps approach one of the community members to enter into a support agreement\r\n\r\nif u want to measure the responsiveness of a project, consider submitting a basic cleanup PR. add some doco, fix some spelling etc. how well that interaction proceeds will tell you much about the project.\r\n\r\nlook for abandoned PRs\r\n\r\ndoes the project have adequate tests and an automated CI to verify them."}}
{"actor":{"display_login":"SimonCropp"}}