Pages: 1
Print
Author Topic: XMAX12: Could not get initialized if %appdata% is mapped to a network share  (Read 508 times)
MichaelLohr
Member

Posts: 12


« on: February 04, 2019, 07:08:40 AM »

Hi Derek,

we are using XMAX12 in a C# application.

One of our customers have a terminal server where the %appdata% folder for every user is mapped to a network share.
On this system it is not possible to initialize the XMAX control.

Do you know this problem and do you have a solution for this?

Best regards,
Michael


Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #1 on: February 04, 2019, 04:19:24 PM »

Each user needs to have their own separate %appdata% location for XMAX (which I think would typically be created for each user/account on a Terminal Server session, or maybe I don't understand how you can configure such a system). If a folder is being shared among users then temp files written there by each copy of XMAX might trigger a race condition and that is not something the software is designed to handle.

If that doesn't sound like the issue you are seeing we will need more information about the setup.
If a Terminal Server is involved and you are not using concurrent licensing then perhaps that is part of the issue?
« Last Edit: February 04, 2019, 06:46:02 PM by Derek Read » Logged
MichaelLohr
Member

Posts: 12


« Reply #2 on: February 05, 2019, 04:54:10 AM »

Hi Derek,

Thanks for your fast reply.

You can reproduce the problem by the following steps:
* Go to your local %appdata%
* Move the "roaming" directory to a network share by folder properties tab "Pfad" in german.
=> See the attachment for the preceding steps.

* Remove the folder "SoftQuad"
* Start XMAX
=> You get an error while initializing XMAX

Even though the folder "\\data03\temp\mil\roaming\SoftQuad\XMetaL XMAX\12.0" is created by XMAX there seems to be a problem with
user rights in this folder or one of its files.

On our customer's terminalserver each user have its own appdata on a network share like "\\data03\USERNAME\roaming\..." and they are using concurrent licences,
so this is not the problem.

Any ideas about this?

Best regards,
Michael








* ChangeAppData.png (47.95 KB, 621x685 - viewed 28 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #3 on: February 05, 2019, 04:52:14 PM »

I've followed your instructions, though not on a Terminal Server (I have no access to such a system) on a regular installation of Windows 10 Enterprise instead, and I do not see the issue.

Perhaps if you map the location to a drive letter that will help?

So, instead of having \\data03\USERNAME\roaming\
Map "data03" to a drive letter so that the path is R:\USERNAME\roaming

What kind of error is raised for you when it fails?
Logged
MichaelLohr
Member

Posts: 12


« Reply #4 on: February 06, 2019, 02:29:46 AM »

On my regular windows 10 the application crashes with the steps mentioned before so its strange that you could not reproduce it.
It is important to delete the "SoftQuad" folder else it does not occur.

Attached you find a demo application.

The application crashes in MainForm.cs in line 60
_xmControl.Document.RulesChecking = true;
because the "Document" property is null.

Maybe it could work with a mapped drive but the IT department at our customer explicitly does not allow this.

Also I think it would be better to solve the root cause than fixing the symptoms.

Thanks for your help.

* XMax-InitLicTest.zip (89.23 KB - downloaded 12 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #5 on: February 06, 2019, 02:15:46 PM »

I will have a look.

I am testing with XMAX 13 so that might be the difference. You should also try the current release of XMAX on your side to see if that helps. There isn't much point in testing with 12. If there is an issue with that version a fix for it won't be created. If the issue is reproducible in version 13 then (given current development workflow) it would likely be addressed in version 14.
« Last Edit: February 06, 2019, 02:23:00 PM by Derek Read » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #6 on: February 06, 2019, 05:44:49 PM »

This is what I see when testing with XMAX 13 and your solution, after having moved my %appdata% folder to a Windows share that is mapped to the O: drive (something I already have in place), and making sure there is no SoftQuad folder there (which there isn't by default of course since the "roaming" folder was just created by me and is new). After XMAX created it the first time I removed it again and XMAX had no trouble creating it again, nor writing into it.

In this dialog XMAX is telling us that it is writing out it's minimum set of customization files. I'm not sure if that is normal for your setup. I assume there is no document-level customization simply because this is a stress test. If for whatever reason you cannot work around this problem perhaps providing a full set of customization files will avoid XMAX having to write here (since it can simply load them all from the DTD location).

Here are some guesses:

1. Somehow (without knowing about this issue, nor knowing how to reproduce it) we have altered the way XMAX 13 accesses %appdata% and reads/writes to it. I think that is unlikely as we are using standard Windows APIs for this. It is possible that the Microsoft compiler or code that we used for XMAX 12 is different for 13 (some update has been applied or similar) though I don't think that is the case.

2. Somehow the folder you have pointed %appdata% to on your test system is not functioning the way Windows needs it to, or at least those APIs that we use to read/write files.

3. Something else is interfering with all of this, perhaps some additional 3rd party code is required to reproduce the issue that I do not have. This might be part of your own code, or perhaps it is something entirely separate, such an an anti-virus or other kind of security software, or perhaps the server where these files are stored is somehow behaving oddly when it comes to Windows client machine access.


* customization_autogen.png (12.5 KB, 412x258 - viewed 30 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #7 on: February 06, 2019, 05:54:49 PM »

I have repeated the same test but this time without mapping the drive letter and instead using a network path similar to yours:

\\servername\data\home\dread\roaming

No problems in this case either.
Logged
MichaelLohr
Member

Posts: 12


« Reply #8 on: February 07, 2019, 06:34:32 AM »

Thanks for your help.

I tested it again with XMAX 13 and now I got the same message box as you. And after that XMAX is working.
With XMAX 12 this message box was not shown, so there must be some kind of improvement.

So I will check on our side if it is possible to upgrade to XMAX 13.

Do you know when XMAX 14 will be ready because updating all our customers is not that easy and if we could
change to the newest version this would be very helpfully?

Best regards,
Michael




Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #9 on: February 14, 2019, 02:19:06 PM »

We have been releasing major versions annually for quite a while, but specific dates for XMAX are hard to nail down. "Summer" is a good guess.

XMetaL Author Enterprise typically comes out in March (this is the biggest selling product and is always released first) followed by XMetaL Author Essential (essentially the same product minus a bunch of features), then XMAX. All of those products have a large shared codebase.

XMetaL Developer (if we do one that year) and the CMS integrations that we maintain ourselves usually follow in the fall (XMetaL Author Enterprise for SharePoint and Documentum).
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2601



WWW
« Reply #10 on: February 14, 2019, 02:20:01 PM »

If you have time to test XMAX 13 now is a good time to provide feedback on it that might make it into version 14.
Logged
XMetaLOldTimer
Global Moderator
Member

Posts: 55


« Reply #11 on: March 04, 2019, 03:57:18 PM »

A similar issue was reported by another customer last September and repaired in late October last year.   Redownload the v12.0 which contains XMAX binary v12.0.0.081 and the problem should be fixed there.

Here is the summary of the related issues fix in the latest XMAX 12.0 software:

ArchitectureCannot open document if its corresponding DTD or XSD was located in a deeply nested folder structure. The per-user generated folder path XMAX made for writing compiled rules file was longer than Windows would permit.
ArchitectureCannot open document if its corresponding DTD or XSD was located in a deeply nested folder structure AND APPDATA is set to a UNC-based folder path. The per-user generated folder path XMAX made for writing compiled rules file was longer than Windows would permit.

Logged

Addam Smith, XMetaL Project Lead & Architect
JustSystems Canada Inc.
Pages: 1
Print
Jump to:  

email us