2

In an attempt to make my references update based on my configuration, I've tweaked my .csproj file by adding a property and changing all the references to use it as follows:

<PropertyGroup>
    <ReferencePath Condition=" '$(Configuration)' ==  'Release'">foo\release\1.0.0.9\bin\</ReferencePath>
    <ReferencePath Condition=" '$(Configuration)' == 'Debug'">bar\debug\</ReferencePath>
</PropertyGroup>

<Reference Include="BasicControls, Version=5.0.53.0, Culture=neutral, PublicKeyToken=25ad4b03c913ffff, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>$(ReferencePath)\BasicControls.dll</HintPath>
</Reference>

Something is wrong and preventing the changes from propagating. Nothing I do to the .csproj file changes the paths of the references - no matter what I do, right-clicking on the reference and looking at its Path in the properties shows the same path it showed before I started editing the file.

  • I've tried unloading and reloading the project
  • I've tried changing the configuration from Debug to Release
  • I've opened and closed the solution
  • While the solution was closed, I deleted the .suo file.
  • I've clicked reload on the solution explorer.

All of the references in the .csproj use the $(ReferencePath) setup, and neither of my ReferencePaths use the original path.

What am I missing? Is it something in the way I'm using the Property?

Scott Mermelstein
  • 15,174
  • 4
  • 48
  • 76
  • Possibly ReferencePath is a proprty uses somewhere by MsBuild itself so I'd give it a custom name to be sure. Exit VS, add a target to show the path like ` `, start VS, build and check what it prints? I'm not 100% sure that even though the path VS shows is wrong, the build will use it.. – stijn Sep 10 '14 at 10:11
  • Thanks for the ideas. I think part of my problem was that I was closing the solution but not VS. Now, when I close VS, remove the suo, and reopen VS, I see effects from the edits I make. It seems that ReferencePath may be a reserved word, see e.g. http://www.codeproject.com/Articles/184718/Take-advantage-of-Reference-Paths-in-Visual-Studio . But when I used a MyRefPath concept, the path didn't load in properly. I'm still working on figuring out how to get my change to do what I want. I tried using your Target as a means of debug, but didn't ever see any output from it. – Scott Mermelstein Sep 10 '14 at 16:43
  • *but didn't ever see any output from it* that can only be the case if the MyRefPath property is empty (or was there also no line `ShowRefPath:` meaning the target isn't even invoked?) Change the text to `"MyRefPath = $(MyRefPath)"` And add `Importance="high"` so you should at least see the `MyRefPath = ` part. Check on commandline maybe to make sure it gets used. – stijn Sep 10 '14 at 16:52
  • You're right on the fact that I didn't invoke the target. I need to start thinking of this as an Msbuild file instead of "the project file for Visual Studio." I'm not very experienced with MsBuild (though I used to be decent at makefiles a long time ago). If I can't figure out how to invoke the target, I'll ask you to spoonfeed me. – Scott Mermelstein Sep 10 '14 at 16:58
  • If you copy-paste it as-is anywhere into the build file it gets invoked automatically when you build or rebuild since it has `BeforeTargets="Build"`. However I just realised that in VS you will only see it in the Output window if you set Tools->Options->Projects and Solutions->MSBuild project output verbosity to `Normal` (or higher), that might be why you don't see it? Alternatively uncomment the `BeforeBuild` target you see at the end of the build file and copy-paste the `Message=...` piece into it. If that still doesn't clear things up I'll try to come up with a complete answer, comments ... – stijn Sep 10 '14 at 18:36
  • ... on SO are too limited in length for this :P – stijn Sep 10 '14 at 18:36
  • Thanks for everything, @stijn. I think you got me far enough along the right track, simply by setting the project output verbosity to Detailed. I never did find the output message you had me inject, but the output from the build was enough for me to see further into the issue. Sadly, it looks like the underlying issue is that I just don't have the files in the right directory for the hintpath. I knew that, and was expecting that things wouldn't build. I didn't realize that VS determines the path through the same process as the build system. – Scott Mermelstein Sep 10 '14 at 20:02
  • @stijn Since this ended up being a "user was an idiot, and didn't have the files in the right place" issue, I could see a case for deleting this question. But I think you provided a lot of good details on how to debug a .csproj file, and this will likely be useful for others. If you want to paste them into an answer, I'd be happy to accept it. (Otherwise, I'll paste your answers in and make it a community wiki.) – Scott Mermelstein Sep 10 '14 at 20:05
  • 1
    Was going to say wiki is fine, you beat me to it – stijn Sep 11 '14 at 17:41

1 Answers1

3

As I mentioned in the comments, I think stijn has provided a lot of good information on how to debug issues with a .csproj file. Some of his more basic ones helped me resolve my issue. Since stijn hasn't posted all the information in the comments as an answer for me to accept, I'm summarizing it and making it a community wiki.

  • The simplest thing that helped get me on track was exiting VS between edits of the .csproj. I had been closing the solution and reopening it, but somehow there were different results. So, always exit VS if you're worried your changes aren't propagating.

  • I've seen the .suo file cause some strange caching issues, where paths my file no longer refers to are still appearing. To keep things as clean as possible, after you exit VS, delete the .suo. It's just a preferences cache; deleting it doesn't make you lose anything.

  • If you want to debug a variable, you can put the following code inside a .csproj:

    <Target Name="ShowRefPath" BeforeTargets="Build"> <Message Text="$(MyRefPath)"/> </Target>

where MyRefPath is the variable you are interested in looking at. It will then appear in your output log when you build, if you set the output log filter to Normal or higher.

  • I found that setting the output log filter (at Tools->Options->Projects and Solutions->MSBuild project output verbosity) to Detailed gave me more than enough data to debug my underlying issue. It's very verbose, but that's what you're looking for at that point.

Of these, the most useful tips for me were setting the output log verbosity and exiting VS instead of closing the solution.

Scott Mermelstein
  • 15,174
  • 4
  • 48
  • 76