application fails to load...

[lostcontrol]

Hi

Of the xx applications we have out there, occasionally we get an error that the application will not start.
The most recent one was 'root element' not found.
Move the complete application folder to a different directory/path & it works without any issue.
I used to think this was a windoze thing, but now not so sure..

Any ideas on what this could be?


from the error, it looks like the app is using the 'C:\Users\7 User\AppData\Local\' directory, even though where i have the app is in a different location.
I can provide the complete error if need be?

[Archie]

How are you deploying the application? Are you using the Application Settings that are built into Visual Studio such as for DB connection strings?

[lostcontrol]

Just by copying the entire VS application project, then creating a shortcut to the .exe under the BIN folder.
My assumption was that this was the preffered method to conform with the GPU thing..?

[Archie]

That is the preferred method of deployment. In that case, it should not be using anything in any other directory unless your program explicitly saves settings.

The next time you get an error, see if it lets you show more details that may point to a certain line of code, then post what you get.

[DanieLoche]

That is the preferred method of deployment. In that case, it should not be using anything in any other directory unless your program explicitly saves settings.

The next time you get an error, see if it lets you show more details that may point to a certain line of code, then post what you get.

The best way to get some "error messages" is to launch the application from the console.
With Linux it's quite simple. With windows... almost the same but the navigation through the documents to go to the folder of the application is annoying. ^^

If an error occurs, you will have the precise feedback in the console !

[lostcontrol]

That is the preferred method of deployment. In that case, it should not be using anything in any other directory unless your program explicitly saves settings.

The next time you get an error, see if it lets you show more details that may point to a certain line of code, then post what you get.

The program does save settings explicitly.
So if this is the cause, is there a fix?
I could look at modifying program so the settings that saved are read from PLC, but requires a bunch of rework most likely.

[Archie]

The program does save settings explicitly.
So if this is the cause, is there a fix?

Are you using the "Settings" feature that is part of VS or writing to something like an INI file via your own code?

[lostcontrol]

Using the 'settings' feature..
Going to assume by your question of a file (INI or similar) that maybe a file is better?

[Archie]

The "settings" tool is easy, but you have less control of where and how it stores the information. Typically the data will store in an XML file in the same directory as the executable. But as you move to different OS's I'm not sure where it all wants to access files.

[lostcontrol]

So suggestion is to change to an INI file or similar?
And the reason for the original post was due to the moving to different directory solved it.
So is likely that using the settings was/is he cause?

[Archie]

This is why I suspect the Settings as being the culprit

The error about 'root element' means it is trying to access an XML file that it either no longer there or corrupt. If you do not explicitly access the \AppData directory, the only other thing that I am aware of is the Settings. The Settings are also stored in an XML file which means it would be looking for a 'root element'

Now here is the one thing that doesn't quite make sense. If you are using XCOPY deployment, the XML setting files should be in the same directory as your exe. As opposed to using the Publish method which will store those files in the application data directory.

[lostcontrol]

Not explicitly using XCOPY, rather standard windoze copy with ctrl+c/ctrl+v etc.

[Archie]

XCOPY deployment is a phrase meaning to use a direct copy and not any setup, install, or publish program to install the software. It's a carry over from way back in the DOS days when you literally used the XCOPY command to copy everything including subdirectories.

[lostcontrol]

Ok, thanks.
I sort of recognized it.

But back to my issue, I am also writing to the settings on a product change (not regularly).
Since all the products are stored in a file on the HMI, I use the settings to keep track of it by name.

By copying the complete application to another directory does not indicate file corruption though, maybe a permissions issue?

I have been contemplating a re-write of the application, as have been adding & adding to it & thing could be better. (as always).