Elements .2539
After “Register Server”, it can NOT be removed, and I have no idea where can I EDIT an existing registered CrossBox server. Also Tools -> Options, Add server NOT WORKING!
Is there a way I can “manually” edit the CrossBox info? Where is the info stored?
it’s in %APPDATA%\RemObjects\Elements\CrossBox.xml.
the Register Server in the menu works though, right?
Yes. The “Register Server” in the menu works.
1 Like
Additional Problem: It seems no matter what, the "remotes shared folder is NEVER saved in the xml file C:\Users\WXIN\AppData\Roaming\RemObjects Software\Elements\CrossBoxServers.xml?
Also when I try to launch debug (after successful Validation), from Visual Studio on Windows, I got the following. Any heads up?
Starting deploy to Crossbox Server 192.168.65.132
Uploading Test to 192.168.65.132.
Failed to deploy to CrossBox Server 192.168.65.132: Upload failed. Could not create folder '/home/wxinHmm, ill have a check…
is
Could not create folder '/home/wxin
the full path shown, and do you have access rights to the path?
I set the remote root as “~/Projects”, corresponding to the Linux servers’ /home/wxin/Projects
Again, as noted above, this remote root seems NOT stored in the CrossBox server config xml file.
Yes I have access rights to the path, I am using the username wxin, which is a su
Beside, I am connecting CentOS 8 - is that a potential problem?
Ok, the Shared Root is an unrelated issue. what thats does is forgot uploading/downloading files to the server if the ./obj folder lives in a place that both local and the remote can access. it not being stored the XML is a bug (will go now), but all that does it cause the shared root to be ignored and do the regular upload/downoad.
What confuses me is that (a) the message looks cut off (note the missing end quote) and (b) that it wold need to try and create that folder at all (id assume it should exist).
It should, not assuming CentOS provides a normal unix-compatible SSH shell.
i’d like to sort out what exactly its trying to create though. Can I see a screeenshot and/r a full copy of the log?
Is there any chance you could set me up with access to that server (whether as wxin or as a different user)? my public key is
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1q5HUvKtDRnisUp2hj31AyMZVluJclP/7yhmEAdDBST3DJwR9dQdvrwmf67odhdj8hMl62SLd62D2EWnT6/R0/AYiKn+BUsvr07aF0a55E18rwHbEXs0jUe/Ph89DjCEbLZtyJtl8Sb3eqp27RMZmem3/8u5f6vh1Jkt/vOW0xJa7KvpDs1WtQ+nFW1VJrEU6/FbLEP7dZMbt4UEeLS33Kajp2WQhcRHIgVomDFMWQ4NZF1dwCA/ATtGj0J4q7JaVMAr7hIgJG3ubPHYuklpfuPzOygEYtG0o6s5JfqOxqNco4sr6E/1zXLzRH72nKl5qH925E3SGfqFUlvXfU57AQ== mh@remobjects.com
Is this from VS or Water? if VS, do you get the same error in Water? (dito, does Water also fail to save the Shared Root?)
(fwiw, Water did add the shared root for me):
<server2 name="0.tcp.ngrok.io" platform="Darwin" architecture="x86_64" hostname="0.tcp.ngrok.io" port="14657" username="mh" localsharedroot="\\tsclient\Public\" remotesharedroot="/Users/mh/Public/"/>
(even when its not verified, which is to nice and I’ll fx, too). That said, an invalid shared root will be detected as such during build and ignored)
That part is fixed; as the other part is VS specific I’ll have to leave that to the VS team…
Hi Marc,
Thank you very much for your attention.
Yes - Water can save remotesharedroot, no problem. It is the Visual Studio that does NOT save.
Also - I finally was able to make the redebugging working on CentOS8, after I did the following:
-
First I disabled screenFetch, inside .bashrc
-
Then I installed gdbserver
But I notice that, even thougth I set remotesharedroot="/home/wxin/Projects/", the remote dubugger didn’t touch that folder, but instead created a folder /home/wxin/.EBuild directly.
I was expecting a duplicate copy of the project files to be inside Projects — did I misunderstand anything?
Yeah. thats not what thew Shared Root does.
1 Like