Plugin not working in Visual Studio Code - Windows, Rhino 6, Visual Studio 2017 & 2019
heba-eiz opened this issue · comments
Thank you so much for this amazing plugin! I always hated the built-in editor of c# in grasshopper and this plugin is a huge help!
Unfortunately, I only managed to get it to work once and then I am no longer able to get it to work.
I get the VS project file and it gets updated when I edit the c# component from gh, but the changes I do in VS don't get sync to Gh after I save the VS file.
(it somehow worked when I used Notepad++ but not VS)
Any idea of any possible problem in my settings?
@heba-eiz Did you solve this issue? Perhaps you have a solution for people who also have this issues?
@arendvw I couldn't find a solution to get it to work on Visual Studio but it works on Visual Studio Code so I ended up using that.
I truly can't thank you enough for this plugin! I hated the gh editor so much and your plugin just made coding pleasant again :)))
I have the same issue btw, and dont want to use extra programs. If anyone finds a solutions would be awesome... What I can think of is that VS does not use the regular way to save files so no events are triggered to reload the contents to GH.
@dilomo I actually found a work around to get it to work with VS, a bit of a weird one but it works :)
Basically after you open the project once in VS (to load the assemblies), you open the code in both VS and VS Code, I do the edit in VS, and every time I save the VS, I see the VS code updated (even while it is open, you don't have to open and close it), then I simply save VS Code, and VIOLA! It is right there in gh editor :)
@heba-eiz Thats interesting solution. But it seems that the file watcher inside script parasite cannot detect files saved by VS.. That's one more pleasant thing about using windows hah
Watcher = new FileSystemWatcher(directory, filename)
{
NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.CreationTime
};
Watcher.Changed += OnFileChanged;
> Watcher.Created += OnCreated;
Watcher.Deleted += OnFileChanged;
Watcher.EnableRaisingEvents = true;
Message = "Watching";
Maybe there is something missing here? Not sure what is happening there but prob event is not detected.
I would love to edit and try but what is ScriptComponents?
This is how the code should be changed to work for visual studio:
Ok I have good news. I fixed several things around in the code without changing too much:
- File changes by VS are detected now
- Any changes to the code inside the GH's C# window is reflected back to the file in VS by pressing the Run button or the OK button
- Fixed indentation issues and now at least on my pc files are consistently shown without changes across syncs
The question I have to @andrewheumann is how do I upload my changes now? I can push back or make a separate branch? I also dont have rhino 6 so I compiled against 7 and .NET 4.8.
Cheers
@dilomo I think you'll need me and not andrew, but the easiest way for me is that you:
- create your own fork (by clicking fork in the right top)
- change the origin url of your git repository to your own fork
- push the changes to your own fork
- create a merge request here
This is the nicest way, and you'll be credited as an author on github here.
If this is somehow does not work, you can always just give me a zipped folder and I'll figure out the changes on my end.
@arendvw sorry I thought I tagged you last post.
I think I did it but not sure. You should be able to see the pull request now.
Thanks
Just as a comment btw, there might be needed some more work on first load of files with the plugin. If a gh file has a ScriptParasite and it is set to enabled the contents that are written to the external file always come with a lot of white spaces. I tried to account for it but maybe has to be better tested in different use cases. If the script is "saved" by pressing ok on the C# window formatting should be perfect. If you get a lot of spaces and you opened an old document is better to replace ScriptParasite component with the latest version. So maybe its good idea to show the current version inside the tooltip description.
I just added another commit with some more fixes. You can see detailed log in the pull request. I think if we could only manage to fix the wrong indentation for additional usings would finish all open issues right now.
@dilomo thanks a lot for all your effort! This has been very very helpful.
I did not directly merge your requests, because of some problems:
- Whitespace (see #5 for more content)
- Support for VSCode is fixed, but support for Visual Studio is now broken in this pull request on my pc, the root cause is mainly about #6
- I've adopted your method of using OnSolutionExpired in a new class ScriptComponentWatcher that checks if the content of the script has changed (the racing conditions should be fixed in a way very similar to your approach), but can also pause checking in case we're writing a file to the filesystem.
- I've refactored the OnSolutionEnd events with a GrasshopperDocumentWatcher, which will wait until the current solution is done, so we can safely update our component, expire the component and update the solution.
Does this solve your problem?
Looking at the new code looks next level to me 🥇 I compiled against Rhino7 and I see some issues that i kind of fixed but are not yet working for me..
- Updating of the parameters type does not change the external file for some reason.
- When I did look at C# editor inside GH and I did not change the code but I press ok, the file is still saved. I think we should not do that to reduce wear on the S/HDD. I implemented a simple checksum verification that would only save when there was change to the codes or to the parameters' type. I think it is also useful on parameter value change which would trigger also the expired event and we dont want to write the file that often. I wrote something like that in the code of the latest commit:
private bool WriteScriptToFile(Component_CSNET_Script script, string filename)
{
//only write the changed files and skipp attribute changes so that disk wear is decreased
var usingHash = GetStringSha256Hash(script.ScriptSource.UsingCode);
var sourceHash = GetStringSha256Hash(script.ScriptSource.ScriptCode);
var additionalHash = GetStringSha256Hash(script.ScriptSource.AdditionalCode);
// always change on attribute modification
if (AttributeTrigger || usingHash != UsingHash || sourceHash != SourceHash || additionalHash != AdditionalHash)
{
// save for next run
UsingHash = usingHash;
SourceHash = sourceHash;
AdditionalHash = additionalHash;
// can write now ... <skipped code here>
}
else
// simulate write as the text is the same as the previously written one
return true;
}The attribute trigger is triggered on all other events except SolutionExpired. I think it could be MD5 checksum as well or at least thats the way I devised. This is a way to avoid always saving on Solution Expired event even tho there are no changes. Also if the file is big saving takes time.
Actually it is a bit unpredictable:
- It worked only once and then stopped? I noticed it works once if I save from VS and then it stops..
- Now it does not save on same content but it does not save the attribute changes as well? It saved when some time passed without working on the file.
What is most important for me is (check is so far working)
- Be able to save changes from VS and vice versa but only if the content is really changed
- Be able to reflect parameter changes of their type but on value change there should be no syncs
- Consistent indentation 2, 4 or any number of spaces (in future might be selectable)
- Line number matching between scripts
- (Optional) Show which script refers to which file by guid number as name?
Can you send a binary or upload in the branch so I can try directly some other dll
I uploaded my compiled version in my fork's releases. I think on my computer all mentioned works. So difficult to make it for wide audience 😅
@dilomo Thanks for the great checklist, this helps a lot.
I've changed some logic that checks when to write: this should work better now on attribute changes.
I'm not yet able to reproduce the part where it stops working with events when working with visual studio.
Indeed, it's very difficult to test, with different editors, different platforms and different behaviours.
Attached is a binary version of the last master branch (also on food for rhino as 1.1.1 beta
@arendvw Great job! Now it works as it should (your binary) and I think you made a lot of people very happy with this new release. Thanks for the effort and quick fixes.
As far as optional stuff everyone can download and modify as they please.
Awesome, thanks for the testing, this helps a lot! I've just changed the 1.1.1 on food4rhino to non-beta, and I'll now release it to yak. I'll open a separate issue for the optional stuff.