C# Path of dll vs. Application path vs. EntryAssembly path vs. Form path

OK, I have stumbled on this one a few times so I thought I would blog it up so that I had a place to come and find the answer. The problem most recently was an application I wrote that I use as a command line tool, but other times as a class that hits a constructor. Either way a property file is needed, and depending on the way I call it I had trouble finding the path to the config…

The problem is, when you use Microsoft Visual Studio to launch the debugger, the Application.StartupPath can’t be relied upon, as it points to the Studio directory. At run time it might work, but not for the case I had in mind where I needed to know where the DLL itself was.

So you can use this:

System.Windows.Forms.Application.StartupPath

But that is for a windows form startup path – useful, but not for me.

This will give you the directory the app started in (but again, it may be a Visual Studio directory if debugging):

Application.StartupPath

And this will give you the process executable in the default application domain, or the first executable that was executed by AppDomain.ExecuteAssembly – again, not what I needed:

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location)

Finally, the winner is (and look closely – GetExecutingAssembly vs. GetEntryAssembly)

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

This snip allowed me to find the directory where the DLL was currently executing, and thus the config that sits next to it. So many ways to get at run-time information! Hope that helps you!!

TFS Instance Appears Read Only Until Mapped

OK, I’ve run into this one with Microsoft’s TFS server a few times so i thought I would talk about it to help me remember it.  MS has come a long way with their version control software, with TFS light years ahead of some of the old versions of Visual Source Safe, but there are always “duh” moments that a co-worker helped me to remember today.

At my job we use a single TFS server and have instances that are created for various groups in the company.  If you want access to another instance you open a ticket with the IT folks to give you permission to get at it.  There are 2 types of access, read only, and an “Advanced” developer mode that gives you the keys to the candy store.

After my request for total control of the TFS repository was completed, I went into Team Explorer and then into Source Control and saw the new instance ready to go.  I wanted to create a directory and start adding some code to the repository but noticed that by right clicking “New Folder” was grayed out.  All I saw was “Refresh” and “Add items to Folder”.  My security request had surely been mishandled I thought (or less likely I had asked for the wrong access 😉 ).  I opened another ticket and got – “You already have “Advanced” stupid”.

Well, a few minutes scratching my head had me stumped and wondering what to do.  I checked with the owner of the repository and he said I should be good to go as long as I have advanced.  Oh, and have it mapped correctly.  Mapping!!!  This is the key!  Just because the repository is shown in your Source Control Explorer, until you have it mapped you might as well only have read access.  So I right click on the instance, choose “Map to Local Folder” and enter the path that I want to map it to and POW! – we have liftoff!  I now have a correctly mapped folder that I can create folders and add content to my hearts content.  On to the coding!