search

NeVeSpl / NTypewriter

File/code generator using Scriban text templates populated with C# code metadata from Roslyn API.
https://nevespl.github.io/NTypewriter/
MIT License
117 stars 24 forks source link

Changes from GIT not picked up by NTypewriter #100

Open vickevire909 opened 6 months ago

vickevire909 commented 6 months ago

I have this very weird issue when I switch to another branch in my repo in which someone else has made changes to .cs files that should be rendered.

If they have for example added an enum value in the .cs file, then rendered that template so that the corresponding .ts file has been output correctly with the new value and pushed the changes, this bug happens.

When I switch to their branch and pull their changes with the new value, if I render the same template, the new value is removed from the output .ts file. It is as if NT does not recognize that the .cs file has been changed and renders the output based on some locally cached value from my previous branch? Of course I don't know if this is the case, I'm just speculating. This is kind of what it seems like though. Any ideas? Have anyone else had this problem?

How does NT actually determine if it should read the .cs file as it is right now on disk before rendering? The local file does have the new value, and so it should reflect in the output .ts file. The preview in Visual Studio even shows that it should have the new value, but it does not render it...

NeVeSpl commented 6 months ago

Indeed, there is a lot of caching going on behind the scene, and NT was written when integration VS with git was not a thing yet.

I will look into that when I have time.

vickevire909 commented 5 months ago

@NeVeSpl I just found out that if I restart VS after checking out the branch, the problem goes away after re-rendering.

NeVeSpl commented 5 months ago

I have done some research, and in terms of doing render there is no cache on NT editor side, it uses compiled Solution symbols returned straightforwardly from VS. VS does all change detection in c# files and NT uses whatever VS will return. It is strange that preview and render commands yield different results, they use the same code, with only one small difference in how Solution symbols are obtained from VS which may be key here.

Right now I am leaning towards that the problem is on VS side.