Water Remoting SDK template problem

Remoting SDK
1

I think there is a problem with the Remoting SDK Server (Code-First) template in Water v.2339

Steps to reproduce:
Run Water
New Project -> Echos -> Remoting SDK Server (Code-First) -> C# (Hydrogene)
“ChatServer” -> Save
Build

On the file system the “Properties” folder in the project directory is empty.
In Water, AssemblyInfo.cs, ResourceDesigner.cs and Settings.Designer.cs are all in the project navigation tree, but they are blank when you click on them.

Building gives 3 errors:

"C:\Program Files (x86)\RemObjects Software\Elements\Bin\EBuild.exe" C:\devdata\water\testing\chat-server\ChatServer.sln --logger:fire --configuration:Debug --verbosity:normal --xml:C:\devdata\water\testing\chat-server\obj\ChatServer.water.xml --build --setting:TreatFixableErrorsAsWarnings=True
RemObjects EBuild. An open source build engine for Elements and beyond.
Copyright RemObjects Software 2016-2018. All Rights Reserved. Created by marc hoffman.
Version 10.0.0.2339 (develop) built on bajor, 20181026-151802. Commit a1fc497.

   Reference 'mscorlib' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll' for target 'Echoes'.
   Reference 'System' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.dll' for target 'Echoes'.
   Reference 'System.Data' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.dll' for target 'Echoes'.
   Reference 'System.Xml' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Xml.dll' for target 'Echoes'.
   Reference 'System.Core' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll' for target 'Echoes'.
   Reference 'System.Xml.Linq' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Xml.Linq.dll' for target 'Echoes'.
   Reference 'System.Data.DataSetExtensions' was resolved to 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.DataSetExtensions.dll' for target 'Echoes'.
   Reference 'Echoes' was resolved to 'C:\Program Files (x86)\RemObjects Software\Elements\Echoes\Reference Assemblies\NET\Echoes.dll' via XML for target 'Echoes'.
   Reference 'RemObjects.SDK' was resolved to 'C:\Program Files (x86)\RemObjects Software\RemObjects SDK for .NET\Bin\RemObjects.SDK.dll' for target 'Echoes'.
   Reference 'RemObjects.SDK.Server' was resolved to 'C:\Program Files (x86)\RemObjects Software\RemObjects SDK for .NET\Bin\RemObjects.SDK.Server.dll' for target 'Echoes'.
   Reference 'RemObjects.SDK.ZeroConf' was resolved to 'C:\Program Files (x86)\RemObjects Software\RemObjects SDK for .NET\Bin\RemObjects.SDK.ZeroConf.dll' for target 'Echoes'.
   Reference 'Elements' was resolved to 'C:\Program Files (x86)\RemObjects Software\Elements\Echoes\Reference Assemblies\NET\Elements.dll' via XML for target 'Echoes'.
E: Source code file 'C:\devdata\water\testing\chat-server\Properties\AssemblyInfo.cs' does not exist.
E: Source code file 'C:\devdata\water\testing\chat-server\Properties\Resources.Designer.cs' does not exist.
E: Source code file 'C:\devdata\water\testing\chat-server\Properties\Settings.Designer.cs' does not exist.
   Project 'ChatServer' failed to build.
   Solution 'ChatServer' failed to build all projects.

I can use the same template in VS to create the project and then open it in Water and everything is good.

2

Thanks, logged as bugs://81343

3

Thank you for the report. This is a bug in the Remoting SDK templates deployment and it will be fixed for the next Remoting SDK build.

4

On a related note, if I run the project (the one successfully created in VS, but then opened in Water) I get an error in the console:

~> Process ChatServer started
!> Exception of type System.InvalidOperationException on thread 0EE0
!> Message: Service ChatServer was not found on computer '.'.

And execution stops on this line:

            server.Run(args);

I can hit F5 to continue past the error and it runs fine.

5

This one is expected and doesn’t anyhow affect stability or performance. This is a check if the app was started in a Windows Service mode

6

bugs://81343 got closed with status fixed.

7

Any chance it can get its own error type so that I can set Water to ignore it without ignoring all System.InvalidOperationException(s)?

8

It is being raised by the .NET FX itself. Even if we’ll reraise this exception with different type the initial one will always be raised. However try tu run the app with the /c or --console switch. In this case the server app will start in console mode and shouldn’t perform the check that raises this exception.

9

Will do. Thanks.

10

Whats the exact full call stack for the exception, you have that handy? I could hard-code (for now) a stack based Ignore for Water…

11

What is the best way to get a copy of the stack onto my clipboard?

12

it’s printed out in the debug console, no?

if not, then there’s currently. no easy way, as I don’t have multi-select working on the thread tree view. you could select & Ctrl+C copy the individual stack frames (just the 2-3 ROSDK relevant ones would matter. or a screenshot with the thread pane wide enough would be fine too.

13

Screenshot below:

Screenshot%20from%202018-10-31%2014-52-50
Screenshot from 2018-10-31 14-52-50.png1280×1024 60 KB

14

thanx

15

Added for vNext.

@antonk, you agree this seems safe?

            else if (type == "System.InvalidOperationException")
            {
                if (message?.Contains("was not found on computer") &&
                    getTextualStackForThread(thread).Contains("RemObjects.SDK.Server.ApplicationServer.RunWindowsService"))
                    result = true;
            }
16

I’m also adding the bt and thread backtrace debug console commands, for vNext

17

Yes, it is. However check like

getTextualStackForThread(thread).Contains("RemObjects.SDK.Server.ApplicationServer."))

(ie w/o the exact method name) would be even better. Just in case the code that raises the exception will be moved to another method.

1 Like
18

Will do.