When I do an export, I'm unable to import it again. 2 errors may occur:
I wanted to give my colleague an subset of my connections, but this did not work. We both use 1.75 RC1.
Its pretty easy to reproduce. Hope your able to fix this.
Many thanks!
|||
|--:|---|
|Operating system | Windows 10 x64 |
|mRemoteNG version| 1.75 RC1 |
You can't import mremote connection files. You have to open them with file -> open. Did you attempt that? Did that work?
No, that didn't work either.
If I do an export from mRemoteNG, I can not import it again. So you could test it yourself.
Currently, connection files exported from mRemoteNG are not valid to import into mRemoteNG. This is working as designed (it's a legacy thing..). However, there is currently no technical reason for this to be the case. We should be able to take this on as a feature request to allow mremoteng exports to be importable.
The problem is that you cannot import XML file which was previously exported.
Of course it's OK that you cannot import regular settings XML (it should be opened not imported).
How to reproduce:
Tested on 1.75 RC1
In reply to sparerd:
So what for is this functionality? What for to export XML if you're not able to import it?
I'm pretty sure that it worked in previous releases.
It's preposterous to make an feature request to functionality that existed before but now it's broken.
You are right - exported files were importable in previous versions. It was only the regular (non-exported) mRemoteNG files that were not importable.
Seems there was a small bug where the "export" flag was not set on the exported confcons file. The app checks for this "export" flag to be set and will disallow import if it is not set. Changing the exported xml file and setting export="true" should provide a work around.
The "export" flag bug is now fixed in commit f419bff and will be available in the next release (1.75, either RC or final). There is also no long any reason to do this check, so the code that checks for the export flag will be removed in the next version.
Sorry if I caused any confusion over this issue.
@sparerd - was this one fixed and included? Can this be closed out?
Yep, this is resolved in the current stable release