Cali_West
IIncrementalGenerator and "Inheritance margin" feature hitting removed files
So I guess what I'm doing is trying to raise your issue back up to the top by commenting on it, so that maybe someone who does know what's wrong with your generator will see it and post.
4 replies
IIncrementalGenerator and "Inheritance margin" feature hitting removed files
I recently ventured into creating a source generator. Followed the same series of articles that it looks like you did. I kind of got it working. It worked when using the snapshot tester Verify. It did not work when I packaged it into a nupkg file and installed it as a package reference in a completely separate solution. It correctly installed, it saw all the namespaces in the package, but it had no idea what my attribute was. Somehow that didn't work.
4 replies
Stuck in tutorial hell
Yeah I only mentioned that because that's one of the reasons why you end up saying things like:
I get an idea to add to my code and I start to try and make it a reality. And thats where I get stuck. Its either my code dosent work as planned or dosent work at all.So, at some point between when you got the idea and when you tested it and realized it doesn't work, that's the time you spent in the dark. And at some point during that time, you erred and did something wrong. The quicker you iterate by testing what you have, the quicker you can spot where you've gone wrong and correct it.
28 replies
Stuck in tutorial hell
No, I just mean, let's say you're at a point where you have something working. It runs and does what you expect. Okay great. Now when you go to modify it (first commit what you have to your local repo of course), try and keep the number of things you modify between now (a state that you know works) and where you end up (a state that needs to be tested and you don't know for sure if it works) as small as you possibly can, like incrementally built up. I call the period of time when you're adding changes that are as-of-yet untested "coding in the dark" because anything you've added you won't have full confidence that it works until you test it, and these can compound on each other if some part you built in the dark uses another part you built in the dark, etc. I've built entire programs in the dark and had them miraculously come out working either right away or after some minor modifications, but I've also tried to do the same thing before, got lost in a deep dark rabbithole, and ended up wasting a bunch of time. So I advise against doing that. That's what I'm saying.
28 replies
Stuck in tutorial hell
Also try to code as little as possible "in the dark", so to speak. (That's what I call the period of times between compile + test runs.) Sometimes it can't be avoided, you have to code quite a bit in the dark, but it's always best to just get something working, okay good. Now make a small change and test that. Okay good, etc etc.
28 replies