How do you get the solution directory in C# (VS 2008) in code?

Question

Got an annoying problem here. I've got an NHibernate/Forms application I'm working through SVN. I made some of my own controls, but when I drag and drop those (or view some form editors where I have already dragged and dropped) onto some of my other controls, Visual studio decides it needs to execute some of the code I wrote, including the part that looks for hibernate.cfg.xml.

I have no idea why this is, but (sometimes!) when it executes the code during my form load or drag and drop it switches the current directory to C:\program files\vs 9.0\common7\ide, and then nhibernate throws an exception that it can't find hibernate.cfg.xml, because I'm searching for that in a relative path.

Now, I don't want to hard code the location of hibernate.cfg.xml, or just copy hibernate.cfg.xml to the ide directory (which will work). I want a solution that gets the solutions directory while the current directory is common7\ide. Something that will let someone view my forms in the designer on a fresh checkout to an arbitrary directory on an arbitrary machine. And no, I'm not about to load the controls in code. I have so many controls within controls that it is a nightmare to line everything up without it.

I tried a pre build event that made a file that has the solution directory in it, but of course how can I find that from common7\ide? All the projects files need to be in the solution directory because of svn.

Thanks for your help guys, I've already spent a few hours fiddling with this in vain.

UPDATE: I set hibernate.cfg as an embedded resource. For each configuration I just simply make a new build configuration, debug, release, XYZ. In most cases I'd recommend embedding any files you depend on to run the program. It makes it much simpler to build an installer.

Answer 1

This is probably coming a little bit late, but I've found a solution at http://www.tek-tips.com/viewthread.cfm?qid=1226891&page=164. Since I am using Visual Studio 2010, I made a few minor changes. You have to reference the EnvDTE and EnvDTE100 (EnvDTE90 for VS2008),

string solutionDirectory = ((EnvDTE.DTE)System.Runtime
                                              .InteropServices
                                              .Marshal
                                              .GetActiveObject("VisualStudio.DTE.10.0"))
                                   .Solution
                                   .FullName;
solutionDirectory = System.IO.Path.GetDirectoryName(solutionDirectory);

Of course I used VisualStudio.DTE.10.0, you should probably use VisualStudio.DTE.9.0.

Good luck!

Answer 2

I've finally figured this one out. This will work for any Visual Studio version, does not rely on EnvDTE, and solves the original problem presented here.

1. In your project settings, under "Build Events", add the following "Pre-build event command line":

   echo $(SolutionDir) > ..\..\solutionpath.txt
   

2. Build the project once. The file will be created in your project root.

3. In solution explorer, click "Show All Files" and "Refresh"

4. Add solutionpath.txt to your solution

5. Right click solutionpath.txt, click properties. Change your build action to "Embedded Resource"

6. Use the following code to get your solution path.

       string assemblyname = System.Reflection.Assembly.GetExecutingAssembly().GetName().Name;
       string path = "";
       using (var stream = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream(assemblyname + ".solutionpath.txt"))
       {
           using (var sr = new StreamReader(stream))
           {
               path = sr.ReadToEnd().Trim();
           }
       }
   

Because this is a pre-build event, the file does not need to exist before the build is started, so it is compatible with source-control and doesn't have any obvious issues.

Answer 3

Update: Unfortunately, i don't know how of a way to get your solution folder at design time. So, technically, I am not answering your question, just offering a potential workaround.

You can check if your control is in DesignMode and if it is, you can use Assembly.GetExecutingAssembly() to get the Assembly for your control and determine the location it was loaded from.

Note that there are some caveats with the DesignTime property value, namely if your designing your control or if you are designing a Form that contains your control, it'll return properly true, but if you are designing a form that contains a control that contains your control, it'll retun false.

You might want to skip the whole DesignTime check because of this and always look for the NHibernate config in the base path of your assembly, if your standard way to find that config file fails.

Answer 4

It sounds like you just need to code a better path to your configuration file.

If you do something like this:

configPath =  Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "\\PathToCFG");

you should not be messed up when Windows changes the current directory on you.

Edit: You may be running into an issue with the Visual Studio hosting process. Can you disable this? There is a check box under project properties \ debug.

Answer 5

I'm way late, and I have no idea if this works in VS2008, but for VS2015, the simplest thing I could think to do was create a t4 template. Here's the contents:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".generated.cs" #>
namespace MyNamespace
{
    public static class BuildVariables
    {
        public static readonly string SolutionDir = <#= QuotedString(Host.ResolveAssemblyReference(@"$(SolutionDir)")) #>;
    }
}
<#+
public string QuotedString(string value)
{
    if (value == null)
    {
        return "null";
    }

    return "@\"" + value.Replace("\"", "\"\"") + "\"";
}
#>

This generates a class that's has exactly what's needed. The two warnings I have for this are to be sure to ignore it from version control, and watch out if you copy your solution somewhere else. Unfortunately, building t4 templates as part of an automated build process is still an complex problem in 2018.

Answer 6

I ended up embedding the config file. Since the program auto updates independently of the config file I could give up exposing it to the users.