Provisional solution on a question several times asked, 'How to fetch current running *.xaml file name'

For several years, several posters have been asking ‘burning’ questions like ‘How to fetch the current running Xaml file name?’, ‘How to retrieve the name of a *.xaml file dynamically?’ or similar ones.

Many ‘knowledged’ posters on this forum have stated; it isn’t possible or only in situations when an exception occurs using a TryCatch structure (these posts can easily be tracked)!

Projects become very easily pretty complex. After several times executing a debug session, it is so easy to lose track on ‘where we are’ ! Me too :sweat_smile: ! Therefore, I suggest a provisional ‘one-liner’ which actually helps me (may be you too!). I know upfront there will be a lot to argue about! Don’t! Better, come up with an upgraded version or a more sophisticated one.

As many of you know and use, implement a MessageBox (or LogMessage) to track ‘Where am I?’ to figure out ‘things’, e.g.! Nothing stupid about that! No, to me at least not! It does matter how find our way from ‘Cologne to Paris’, the other way around or use your own prefered city names whatever you like! Using such a MessageBox (or LogMessage) can be pretty helpfull to learn from in which workflow file ‘a problem/bug/misconception’ reside.

As stated, during a debug session, we are able to fetch the location of the executing assembly. From the executed assembly, we are able to figure out, on which particular spot we are. From the property (typed string) ‘Location’ on method GetExecutingAssembly() in class Assembly in namespace System.Reflection - which presentation is quite analog of a path to the file you currently asked the question ‘Where am I?’ - the workflow file name can be elucidated, the current project name can be determined. Much more interesting within the ‘location’ string is sub string ‘Expressions’. This sub string has been ‘glued in’.

The sub string ‘Expressions’ can be used to split the ‘location’ path. From the second (filtered) part, it is easy to track ‘Where we are !’. As allways, several remarks, comments or be aware off’s, e.g., need to be made;

  1. the splitoff part contains ‘underscore(s)’ where we expect in a normal sub path ‘backslash(es)’,
  2. the extension of the file is ‘dll’ not ‘xaml’, and
  3. having a ‘main.xaml’ file (many of us don’t rename this starter *.xaml file) on the higest level in a project folder, the cutoff (second) part first character is an ‘underscore’ whereas having a ‘main.xaml’ file (as starter) in for example a ‘main’-folder (or whatever starter folder name you prefer) the cutoff (second) part first character is a ‘dot’.

See screens!



Anyway, the provisional one-liner


System.Reflection
.Assembly.GetExecutingAssembly()
.Location
.Split("Expressions",2,StringSplitOptions.RemoveEmptyEntries)(1)
.Replace("dll","xaml")
.Remove(0,1)


can be implemented during debugging to have an idea ‘where we are’!

Hi @van-der-kamp,

Was very refreshing to see you make a good case and providing an alternative solution. This was a nice read.

There is also an inbuilt way to get the name of the executing file (.xaml). I think this was introduced sometime in 2022 or late 2021 version.

Here is an example for process name but the job info object contains many other keys and WorkflowName is one of them.

This approach can be used in any invoked workflow and then can be passed on to the invoking workflow. Or a log message in the invoked workflow is another alternative. This way you always know where you are in a complex automation.

There is also a lot of goodies (code) discussed in this feedback post from @Konrad_Mierzwa and @Jon_Smith

Cheers!