2 Replies Latest reply on Nov 8, 2009 1:45 PM by ralvy

    Runtime binding: a peculiarity

    ralvy

      Title

      Runtime binding: a peculiarity

      Post

      Today I noticed that if I changed my solution so that the runtime exe sees a different file as the primary file (different than it did in prior version of the runtime solution), I could not just sent the user a new exe file along with the runtime solution files. Eventhough the new exe file was bound with the same binding key, it still attempted to load the file that used to be the primary file.

       

      With patient exploration, I found that one particular Windows file, found in the Extensions\English folder, must be replaced:

       

      FMStrs.dls

       

      If that read-only file isn't updated with the one created when the new runtime is created, the exe file attempts to load the file that used to be the primary file, not the file that's bound as the primary file to the new exe file.

       

      Does this make sense? It makes me think, I might have to send the user the entire complement of Windows runtime support files with the new runtime exe and solution files, just to play it safle, as long has I have changed what the primary file is.

        • 1. Re: Runtime binding: a peculiarity
          Contour
            

          Since no one else has responded, I'll offer my assessment.  I, too, experienced the phenomena you described and isolated FMStrs.dls as containing information specific to the runtime files.  FMStrs.dls is a database of all the text strings for runtime messages, in the selected language.  But, obviously, there's more to it than that.

           

          Regarding updates to a runtime, I replace only the built runtime files and FMStrs.dls.  I've been doing so for over two years with no known problems. I wish, of course, that someone with knowledge of the internals would chime in with a true explanation of the file's contents and function.

           

          I hope this helps.

           

           

           

           

          • 2. Re: Runtime binding: a peculiarity
            ralvy
               I have a feeling this only becomes necessary when the developer changes which file is the primary file for the solution, or perhaps renames it.