• State Suggested Answer
  • Replies 12 replies
  • Answers 6 answers
  • Subscribers 395 subscribers
  • Views 5353 views
  • Users 0 members are here
Options
Related

How to get programmatically the number of AppData\Roaming\SDL\ProjectApi folder?

Evzen Polenka

I'm checking Studio 2019 SR2 and found that my code for getting the real default project template is failing...
It's failing because Studio 2019 screwed the folders numbering system which worked for years... Disappointed

So far the numbering system was simple and consistent:

    "Studio2"  {$StudioVersionAppData = "10.0.0.0"}
    "Studio3"  {$StudioVersionAppData = "11.0.0.0"}
    "Studio4"  {$StudioVersionAppData = "12.0.0.0"}
    "Studio5"  {$StudioVersionAppData = "14.0.0.0"}
    "Studio15" {$StudioVersionAppData = "15.0.0.0"}

But now I see that Studio 2019 SR1 - and also SR2 - has AppData\Roaming\SDL\ProjectApi\15.1.0.0 folder :-O :-O :-O

That number does not correspond to anything...
All other such numbered folders have 15.0.0.0 number.
SDLTradosStudio.exe product version is 15.0.0.0, file version is 15.2.0.1041.

So, where does this weird number come from and how do I get it programmatically, please?!
Of course I need it to work 100% realiably across ALL Studio versions, SRs and CUs.

Ultimately, I need to read the AppData\Roaming\ProjectApi\<number>\Sdl.ProjectApi.xml file, so if there is any other way to get its full path, I'm fine with that way too.
Rate translation
×
Suggest better translation
×
  • 0

    PING...

    This is rather question for SDL people as I don't really expect any external people to have any deeper insight...
    Plus, SDL made it, so who else than SDL should be able to explain it.
  • 0

    Hi ,

    Yes, the Studio team are aware of this issue. The folder name convention used with the release of SR1 was correct with respect to the version released, but may change back to the previous convention going forward; making reference only to the major nr. (e.g. 15.0.0.0), as it has been till now.

    If you need to access this physical file, then I recommend you iteratively identify the latest version with respect to the version of Studio you are integrating with.

    Example:
    If you are integrating with Studio 2019 SR2, then identify the latest valid path in sequential order.

    ...\Roaming\SDL\ProjectApi\15.1.0.0
    ...\Roaming\SDL\ProjectApi\15.0.0.0
  • 0 in reply to Patrick Andrew Hartnett
    Patrick Andrew Hartnett said:
    but may change back to the previous convention going forward; making reference only to the major nr. (e.g. 15.0.0.0), as it has been till now.

    Aha... in other words, I smell something like "we screwed up"... i.e. someone thought it would be a good idea, but "forgot" to validate and test it.

    Patrick Andrew Hartnett said:
    I recommend you iteratively identify the latest version with respect to the version of Studio you are integrating with.

    I'm NOT "integrating with" some particular version of Studio. That's an assumption based on very narrow-sighted approach of Studio plugins (that system of building separate plugin for each Studio version is REALLY ridiculous).

    Are you saying that there is no way to programmatically get this number/string?!
    Are you saying that even Studio itself uses such amateurish trial-and-error approach?!
    I can't believe it...
  • 0

    Hello ,

    I did a fix for this problem in one of our application named SdlFreshstart. You can check the below print screen of the code on how I tooked the correct folder version. The code is also avaiable, on our Sdl Community Github repository: https://github.com/sdl/Sdl-Community/tree/master/SdlFreshstart/Sdl.Community.SdlFreshstart

    Screenshot of Visual Studio code editor displaying a method to get the last ProjectApiPath folder version from SdlFreshstart application.

    With kind regards,

    Florentina Caputa


    Generated Image Alt-Text
    [edited by: Trados AI at 1:19 PM (GMT 0) on 5 Mar 2024]
  • 0 in reply to Florentina Caputa

    Hmmm, at the first glance this does not seem to be reliable enough.
    Relying on a directory timestamp is very unsafe. Anything in the system can change the timestamp of directories (even the filesystem itself), so this is not the way to go.

    I'm trying a different approach now...

    In fact my real ultimate goal is to get the path to a project template currently selected as default in Studio.
    So I get the template GUID from the user settings and then I need to get the path to the local projects directory, to read the projects.xml(?) file to find the template with this GUID.
    And so far the way was to get the path from this Sdl.ProjectApi.xml file.

    But I found that there is a way to get the local project directory path programmatically - .NET Reflector is really a good friend - so I'm now experimenting with this way.
    (I don't have more details right now as I'm not at the machine with Studio and the code)

    EDIT:
    Sdl.ProjectApi.dll contains Sdl.ProjectApi.ApplicationFactory class. The CreateApplication() constructor creates application object which has a LocalProjectServers property. It's an array, but since to my best knowledge Studio can have only single local project server, I simply take the first element and get its ProjectTemplates property - this is an array of defined project templates, so I then take the one with the right GUID.
    Ufffff...
  • 0

    Hi,

      We have noticed that the folder name is probably identical to the dll version number of the ProjectApi.dll file in the Studio install directory, so we use the following code to get this value:

    var StudioInstallPath = ... // get this programmatically
    var StudioProjectApiVersion = System.Reflection.AssemblyName.GetAssemblyName(System.IO.Path.Combine(StudioInstallPath, "Sdl.ProjectApi.dll")).Version.ToString();

      So far it has returned the correct path for the ProjectApi subfolder.

    Attila

    EDIT: Previously I used the default installation path for Studio for example's sake, but of course it should be obtained programmatically!
  • 0 in reply to Attila Grozli-Nagy

    That's surely interesting discovery, but now we need 100% sure confirmation from SDL side that it not only IS true right now, but also WILL BE true in the future.

    EDIT:
    And BTW, don't do the same mistake as SDL does for example in the above mentioned SDL FreshStart - hardcoding paths.
    It's NEVER set to stone that Windows will be installed on a C: drive and that the directories will be named as they usually are! Such paths MUST ALWAYS be obtained programmatically!
  • 0 in reply to Evzen Polenka

    Hi ,  I was checking back in today to see your progress and surprised to see the list of brusk comments from you in this thread.

    Evzen Polenka said:

    I'm NOT "integrating with" some particular version of Studio. That's an assumption based on very narrow-sighted approach of Studio plugins (that system of building separate plugin for each Studio version is REALLY ridiculous).

    Are you saying that there is no way to programmatically get this number/string?!
    Are you saying that even Studio itself uses such amateurish trial-and-error approach?!
    I can't believe it...

    Actually, in short, yes, you do need to integrate with a Major release of Studio and in your case this is Studio 2019, which corresponds to “15.x.x.x” In the semantic version convention that we employ with our release strategy.

    I confirmed your suspicion and provided you with a suggestion (a work-around if you like) on to how to go about resolving the folder path in question.  How you go about implementing that in your solution is entirely up to you. As it happens, provided you with very clever and probably the most appropriate solution, in identifying the folder path from the AssemblyVersion of that file.  This folder path in Studio is built from the AssemblyVersion information of the IApplication, which is also reflected by that assembly.

    I can also confirm with you that the versioning strategy for identifying these paths will return to [Major.0.0.0] going forward, irrespective of the SP version number.  however, it will not change for Studio 2019 now (e.g. it will remain as 15.1.0.0 > SP1+)

    Now, with regards your extracurricular remarks and assumptions: these are not productive, and although I see that you are seemingly annoyed by all of this -> please try to refrain from such remarks in future.

    We are here to support you in integrating with the product and identifying possible issues such as the one that you have highlighted in this thread.  Join a boxing gym if you feel like punching a bag!
  • 0 in reply to Patrick Andrew Hartnett
    Patrick Andrew Hartnett said:
    Actually, in short, yes, you do need to integrate with a Major release of Studio and in your case this is Studio 2019, which corresponds to “15.x.x.x” In the semantic version convention that we employ with our release strategy.

    And that is exactly the point - all my universally usable tool needs is the major Studio version. I hope you got familiar with how it works by now, so that we can discuss some real thing, not just theory.

    So your suggestion to use the "latest valid path in sequential order" presumably fails to work e.g. when user installs the SR1 or SR2 for Studio (i.e. the 15.1.0.0 and/or 15.2.0.0 or god knows which folders get created) and then downgrades back to Studio 2019.

    Or maybe you need to elaborate in more details on what exactly do you mean by "latest valid" and how exactly am I supposed to identify that it's the latest and valid path.

    I hope you understand that this explanation is needed from SDL and that it's not "up to me" how do I implement it... simply because the fundamental knowledge "how" is - or at least should be - on SDL side, not mine.

    Patrick Andrew Hartnett said:
    provided you with very clever and probably the most appropriate solution, in identifying the folder path from the AssemblyVersion of that file

    Sure, and I said that it's interesting discovery.
    But without clear confirmation from SDL side it's just an idea, nothing else. That's why I also said we need this confirmation.

    Does it mean that you confirm that this (via the AssemblyVersion of IApplication) is the future-proof way to get the number (or name, to be more precise) of the folder used by an instance of Studio?

    Patrick Andrew Hartnett said:
    We are here to support you in integrating with the product and identifying possible issues such as the one that you have highlighted in this thread

    That's cool for sure.
    And I hope that you can understand how annoying and frustrating it is to find out that something was changed a) without notifying anyone and b) changed in a negative way (people would probably not be upset by positive changes)... and that it feels really alarming (and again also frustrating) that such issues are only discovered by users instead of being catched by internal testing before release.