Allow "Flatten to XML" and "Unflatten from XML" to work without internet access.

[Braggel]

Hi all,

In my program i'm using the Unflatten from XML and the Flatten to XML vis. On my development computer it all works well. As soon as I put it in the production environment, it stopped working. I narrowed it down to the fact the in my production environment, there is no internet access and I will never be able/allowed to have internet access there.

Does anyone have an elegant way to fix this problem? (By 'elegant' I don't mean manually changing every .xml file that I produce to include the path to the local LVXMLSchema.xsd) Is there a .manifest or .config file that we can change to point my compiled program to the right xsd file? Another method maybe?

Thanks!

Kind regards,

Filip.

[crossrulz]

My guess is that your problem is actually the lack of the LVXMLSchema.xsd.  Not entirely sure how you are to use that with your executables.

You may want to look into using the GXML library.

[Braggel]

Hi Crossrulz,

I'm actually flattening LabVIEW classes to XML. I didn't try it, but from the doc it looks that GXML doesn't support flattening classes? (They are not in the list of supported types.)

Greets,

F.

[Intaris]

---

@Braggel wrote:

Hi all,

As soon as I put it in the production environment, it stopped working. I narrowed it down to the fact the in my production environment, there is no internet access and I will never be able/allowed to have internet access there.

Filip.

---

Are you serious that this doesn't work on a PC without Internet access? File this as a bug ASAP, that's a ridiculous limitation.

[tst]

Just for a sanity check, are you sure this is about the XSD file? As in, did you do something to with the XSD file to make it work on the production machine?

The reason I ask is that I don't have experience with flattening to XML, but I do know that classes are finicky when unflattening. Unflattening an object requires it to have the same class name and a clear mutation path from the flattened data to the new version. There are many things which can cause this to break, such as renaming the class (e.g. maybe in your application you move the class into a packed library?).

You can probably test this by running the EXE (I'm assuming you're using an EXE) on the dev machine. You can also try flattening and unflattening to string to see if that works.

[Intaris]

---

@tst wrote:

Just for a sanity check, are you sure this is about the XSD file? As in, did you do something to with the XSD file to make it work on the production machine?

---

You can probably test this by running the EXE (I'm assuming you're using an EXE) on the dev machine. You can also try flattening and unflattening to string to see if that works.

---

Yes, I think this is a very important test to rule out the possiblity of name changes to classes (or mutation history problems) during the build process.

[Braggel · Accepted solution]

Hi all,

I seem to have found the solution.

In the end, it wasn't internet access. It was the inclusion of the classes in the compiled code or not.

Carefull! It wasn't enough to just uncheck everything in the 'Additional Exclusions' section of the build. I actually had to instantiate every possible class that could be converted by the "Unflatten from XML" in the .vi. I even tried to put the lvclasses in the always include section of the source of the build. This didn't work either.

Thanks for all your suggestion guys!

Kind regards,

Filip.

[tst]

Yes. It might appears obvious when stated this way, but you can't unflatten to a class which doesn't exist, and stuff doesn't get included unless someone actually uses it. The exclusions section is irrelevant, as that refers to things which are included automatically, and your classes aren't. If you would want them to be included automatically, you would need to make a static call to them from something that's included in the build. For example, you could have a VI with a constant for each class and include that VI in the build.

[crossrulz]

What you probably really needed was the "Always Include" part of the Source Files section of the build specification window for the application build.  You should just be able to Always Include the classes instead of somehow calling them in your code and then not actually use them.