locked
absolute paths in vsmdi file RRS feed

  • Question

  • Hi,

    We use Visual Studio's test lists functionality to order our unit tests, since there are lots of them, and a hierarchical partitioning is definitely nice. As it seems, the structure of these lists are stored in the .vsmdi file. This is all well, but for the storage tag, which contains the absolute path to the test assembly.

    <storage type="System.String">c:\...\bin\debug\frameworktests.dll</storage>

    The problem is that we have multiple developers working at multiple places in different environments, and not all use the same directory. This results in the source code versioning system to create conflicts every time somebody changes something. Is it somehow possible to store a relative path in that tag?

    cheers, Alex
    Thursday, May 12, 2005 3:45 PM

Answers

  • As Micheal suggested you can hand modify the metadata file to set to relative path for test storages. We are currently investigating best solution that will work accross different scenarios that won't require manual editing metadata file. I tried and verified that following works and hope it will help in your solution:

    1. Create solution with metadata file. When you open solution, the metadata path is resolved based on solution relative path. Solution file and metadata files created in same directory by default.
    2. Manually edit metadata file (.vsmdi) to replace absolute path with relative path. (c:\YourSolutionRoot\ProjectDir\bin\debug\test.dll -> ProjectDir\bin\debug\test.dll). If you want to open only metadata file in IDE, start devenv.exe from VS command prompt c:\YourSolutionRoot directory to set CWD to that path and then open metadata file in the IDE.
    3. Once you made change in step 2 you can also run tests using mstest.exe /testmetadata from c:\YourSolutionRoot directory.

    Thanks,
    Bata

    Thursday, May 12, 2005 5:53 PM

All replies

  • Hi Alex,

    You may manually edit the file to use a relative path. We are tracking this issue internally and hope to address it in the final version.

    Thank you,

    ~ Michael

    Thursday, May 12, 2005 5:00 PM
  • As Micheal suggested you can hand modify the metadata file to set to relative path for test storages. We are currently investigating best solution that will work accross different scenarios that won't require manual editing metadata file. I tried and verified that following works and hope it will help in your solution:

    1. Create solution with metadata file. When you open solution, the metadata path is resolved based on solution relative path. Solution file and metadata files created in same directory by default.
    2. Manually edit metadata file (.vsmdi) to replace absolute path with relative path. (c:\YourSolutionRoot\ProjectDir\bin\debug\test.dll -> ProjectDir\bin\debug\test.dll). If you want to open only metadata file in IDE, start devenv.exe from VS command prompt c:\YourSolutionRoot directory to set CWD to that path and then open metadata file in the IDE.
    3. Once you made change in step 2 you can also run tests using mstest.exe /testmetadata from c:\YourSolutionRoot directory.

    Thanks,
    Bata

    Thursday, May 12, 2005 5:53 PM
  • Hi

    Have discovered the same behaviour (sic! :-).

    Now my question is, shouldn't the debug/release part of the path be virtualized out of the equation too? Just asking...

    Reason I discovered this is that I noticed that my .vsmdi file was automatically (no questions asked) checked out when I changed Solution Configuration.

    Regards

    Martin "Brumlemann" Moe

    Thursday, March 23, 2006 6:04 PM
  • I ended up writing a tool that converted the \debug\ paths to \release\ paths. Sad

     

    Thursday, March 6, 2008 9:39 PM
  • We just got hit by the debug vs release issue as well. If a developer working on (debugging) test cases checks in without first switching back to the Release configuration, our nightly build can't find any tests.

    I'm surprised this isn't fixed yet. I guess I'll have to write a tool as well.
    Tuesday, March 10, 2009 2:22 PM
  • +1 (in VS2008SP1).  Really surprised the vsmdi is hard-coded for debug.  I want to run tests in both configurations.
    Tuesday, September 1, 2009 4:13 AM
  • Also using VS2008 SP1.

    The behaviour of vsmdi is extremely annoying. I have the same problem: the vsmdi file is checked out (or attempts to check out with a prompt if that is enabled!), whenever the configuration is changed from release to debug.

    As mentioned before this appears to be due to the storage tag automatically being changed from, for instance, bin\x86\release to bin\x86\debug. Why isn't a macro such as $(ConfigurationName) used so that the vsmdi does not need to be continuously modified?

    I see that in 2005 this issue was being investigated. Shouldn't there be a solution by now ;-)
    Wednesday, September 30, 2009 12:26 PM