none
Xml file access, poltergeist in my application

    Question

  • Hi all,

    I have a problem which is a big mystery, and I need someone light me.

    In my application we update a xml file with parameter everytime we start it. 

    Every x month the client can apply a new fix for this application, recently we experiment a weird issue.

    The current application 01 was working fine, once they tried to change it to version 2, the application crashed because it was not able to save new information in the xml file. After investigation we can see that the xml file doesn't have write right, which is obviously not logic.

    The user tell us that the right of this file never changed, but the application was working fine with older version, we checked the application and we are 100% certain that the code has not been changed. the only change was the fact that we used Visual studio 2015 instead of 2012. but the .net framework is still the 2.0.

    Do you have any idea, what could cause this issue considering that the code is identical and the write right was already missing with the older version ?

    Thanks

    Tuesday, December 05, 2017 4:09 PM

All replies

  • Hi Master_kaygee,

    You said that you created a application using Visual Studio 2012, and it works fine, but you want to update it using Visual Studio 2015, there are some issue in this application, but their target framework are all .net 2.0 and you didn't change any code? Do you try another .net framework in visual studio?

    Best Regards,

    Cherry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, December 06, 2017 2:54 AM
    Moderator
  • After investigation we can see that the xml file doesn't have write right, which is obviously not logic.

    Something has changed in the installation.   Is the XML file as the same location?  Did it get replaced in the upgrade?

    You also need to look at the installation procedure for the new version.  Perhaps the application has been installed with a more restrictive set of permissions than previously applied.  It may be because of the change in VS version, but it could also be that the application has always needed its permissions upgraded in order to get write access to that file, and the upgrade set permissions back to the default.

    Wednesday, December 06, 2017 3:26 AM
  • So to be clear, beofre I builded my code with VS 2012, still in .net 2.0

    Now we are building with VS 2015 still in 2.0

    Nothing has changed in the code.

    Also the client has functional versions installed in their test environment, just their 'prod' environment get this issue. with same dll's same application.

    Wednesday, December 06, 2017 1:04 PM
  • nothing has change, file located at the same folder.

    weird stuff the main installation is working fine, just the client installation that get exe and dll from shared folder is impacted.

    Wednesday, December 06, 2017 1:06 PM
  • nothing has change, file located at the same folder.

    This is what you posted: ".. once they tried to change it to version 2, the application crashed because it was not able to save new information in the xml file." so something has changed.  The task is to find out what it is.    Several suggestions have been provided, but only your are familiar enough with the client's environment to be able to find out what that change is.

    Wednesday, December 06, 2017 8:01 PM
  • nothing has change, file located at the same folder.

    weird stuff the main installation is working fine, just the client installation that get exe and dll from shared folder is impacted.


    If nothing changed then nothing would be altered. My suspicion would be a security issue but without checking the systems logs or providing appropriate code so when the error occurs the app provides what the issue is then you may not be able to trouble shoot the problem correctly.

    La vida loca

    Wednesday, December 06, 2017 8:20 PM
  • I agree with that

    We discovered that the xml didn't had write right, the mystery is why it was working before and not with the new version as they didn't changed anything (as the client said :-)).

    Client is not cooperative so hard to validate this .

    Thursday, December 07, 2017 9:07 AM
  • I'm wondering, 

    Imagine the client has a 4.0 .net instead of 2.0 requested by my application.

    So the application is working fine because 4.0 contains 2.0.

    Imagine now that because I have rebuilded my solution with VS 2015, the path to get xml 'modificator' is not the same and is more strict than the previous one, Do you think it's possible this create that issue ?

    Thursday, December 07, 2017 9:20 AM
  • Imagine now that because I have rebuilded my solution with VS 2015, the path to get xml 'modificator' is not the same and is more strict than the previous one, Do you think it's possible this create that issue ?

    If you are now suggesting that the problem was that some code module external to your application (the 'modificator') was changed as a result of the upgrade then yes, it is possible, if that code module uses a relative path for its file storage.  But if that was the problem then the user would have noticed that the XML file that was now being accessed was different than the one they had been previously accessing, and your investigation would have found that the XML file was now at a different location.  So it seems unlikely. 

    What is more likely is that everything is at the same location, but that location always was unsuitable (in terms of privileges) but that problem had been fixed previously (perhaps without you knowing) and it therefore re-surfaced when the application was reinstalled because privileges were reset to their default values by the installer.
    • Edited by AcamarMVP Thursday, December 07, 2017 9:02 PM sp
    Thursday, December 07, 2017 9:00 PM