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 ! 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;
- the splitoff part contains ‘underscore(s)’ where we expect in a normal sub path ‘backslash(es)’,
- the extension of the file is ‘dll’ not ‘xaml’, and
- 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’.
Anyway, the provisional one-liner
can be implemented during debugging to have an idea ‘where we are’!