In Service Builder 7.0.65.1067, I have set my library’s namespace field to something other than the default namespace in my VS2008 project. But if I choose ‘Regenerate files from RODL’ in Visual Studio, the generated classes are assigned to the project’s default namespace, not to the namespace I’ve specified in the RODL file.
I’ve edited the intf, invk and events files and corrected the namespaces, but now I’m getting a raft of compilation errors in the intf file, along the lines of " does not contain a definition for TriggerPropertyChanged …" and “Argument 1: Cannot convert from ‘System.Uri’ to 'RemObjects.SDK.IRemoteService”.
I am upgrading a VS2008 project from RO v6.0.39.777 to the latest version. I figured a good place to start would be to regenerate the interface code from the RODL, but I seem to have fallen at the first hurdle.
In Service Builder 7.0.65.1067, I have set my library’s namespace field to something other than the default namespace in my VS2008 project. But if I choose ‘Regenerate files from RODL’ in Visual Studio, the generated classes are assigned to the project’s default namespace, not to the namespace I’ve specified in the RODL file.
Thank you for the report. I have reproduced the problem. Corresponding issue is registered as #60165 .As workaround please use RODL Command Line tool (Documentation | RemObjects Software). It generates files according to Library Namespace value.
I’ve edited the intf, invk and events files and corrected the namespaces, but now I’m getting a raft of compilation errors in the intf file, along the lines of " does not contain a definition for TriggerPropertyChanged …" and “Argument 1: Cannot convert from ‘System.Uri’ to 'RemObjects.SDK.IRemoteService”.
Unfortunately, I can’t reproduce the problem. Can you send us small testcase with the problem to investigate it in details?
The compilation errors went away when I removed and re-added the references to the new RO dlls, despite VS telling me that it was already referencing the v7 files after I upgraded from v6.
I installed v7.0.65.1067 ‘on top of’ 6.0.39.777, without manually uninstalling v6 first. Perhaps this has something to do with it?
Has this issue been fixed?
It was a year ago, yet I seem to have the same problem in service builder 7.0.73.1111
(I can’t seem to find how to check on issue #60165).
2015 and this is still a problem in version 8.3.91.1167.
If the namespace in the RODL appears to be ingored when the interace and invoker files are regenerated from within the VS IDE. We still have to manually generate the files using Service Builder outside the IDE.
(BTW, should we care about the version number shown in the generate file. Sometimes it is version 2, and sometimes it is version 4 and this does not seem to be related in any way to the actual version of RemObject we are using. Very confusing!)
My apologies. i’ll make sur this gets fixed froth next beta. FWIW, VS and Service Builder use desperate code paths, which probably explains (but not excuses) why this was fixed for SB but not for VS.
You’re probably referring to the version of the .NET runtime? .NET codegen uses CodeDom, a standard .NET APOI for generating code, and that always emits the version of .NET that was used when generating the code, in the header. It does not correspond to the version of RemObjects SDK itself.
Followup: after discussing this with the team, the current behavior is considered “as designed”. Inside VS (and Fire), code will be generated using the default namespace set for the current project, not the namespace in tine RODL. When generated outside of the IDE, we don’t know about a default namespace, so we’ll use the one set in the RODL.
My two bits:
Suggestions
1: remove the name space from the RODL - either its part of the definition or its not (service builder can ask if it doesn’t know)
2: in service builder change the label ‘Namespace:’ to be 'Namespace (maybe/sometimes/it depends):'
3: when service builder is invoked from the IDE throw up a warning saying RODL namespace is incorrect and (optionally) correct it. I like this one because it is not so much a breaking change to existing users.
Understand it would be a breaking change, but if you have a few RODL files in a project then can be nice if the RODL namespace was honoured. Otherwise if the RODL generation took the project default namespace and added the directory it is in it would be better than what it does now (ie the developer has some control over the namespace).
The IDE integration is useless to us (and breaks our code if people accidentally open the RODL from within the IDE). We will continue to manually generate code from the RODL.
I hear you. i’ll ring this up for further discussion, as i can definitely see the argument both for using the NS from the RODL and for using the NS from the project, when generating code. I’ll see what we can do to resolve this.