Find the absolute path of dll assemblies

[Anonymous]

Hi,

In my visual studio project folder I have some data that I cannot embed them in the resources of the project. The best way to access the data is to find out the absolute path of the DLL that will be plugged in Revit addin manager and use the relative path. However, Revit addin-manager seems to make a local copy of the DLL which will cause losing the track of the original project folder. I have spent hours to figure it out but I couldn't. Solutions that use System.IO namespace return wrong answers. You can change the project folder and see that the system.io return wrong results. 

I would appreciate feedback! 

[Anonymous]

Let me give you an idea of the problem of wellknown methods. I tried the following solustions 

StringBuilder sb = new StringBuilder();
sb.AppendLine(System.IO.Directory.GetCurrentDirectory());
sb.AppendLine(Environment.CurrentDirectory);
sb.AppendLine(System.Reflection.Assembly.GetAssembly(typeof(LibraryClassName)).Location);
TaskDialog.Show("??", sb.ToString());

LibraryClassName is the name of the class that provides implementation for IExternalCommand interface. 

[samernajjar]

I have the same issue, and I believe its a very legit question and wonder why it hasn't been answered yet?!

[Anonymous]

I see that I posted this question years ago but cannot recall the context for it now. However, generally I recommend designing your algorithms and workflows in such a way that you can avoid  these complexities. I guess that is what I did at the end. The best solutions is to consider a better resource embedding skim to avoid this problem at all.

DotNet assemblies are not only binary instructions and are designed to include meta-data that enables them to identify their locations on the disk. This is also thanks to Microsoft who has designed the windows OS and C# language features together. The problem is the copy, which an assembly has no idea where it was copied from. Tracking copies is a far more complicated problem but many code managing systems such as git do it. You can solve this problem by putting an string in the assembly that points to the address of the original VS project where the assembly was made. This is a work around and can be subject to other errors when the original project is moved or does not exist. 

I hope you have found my answer useful.